Trigger temperature: the most useful number before breakfast
`thermal_trigger_temp_c` is the surface temperature that has to be reached before the first thermal of the day breaks the morning inversion. The field is in the API today as a placeholder. Here is what it will do once it lands.
On a summer morning, the atmosphere near the ground is capped by an inversion left over from the overnight cooling. Warm air from the sun-heated ground tries to rise, but the inversion blocks it until the surface gets hot enough that a parcel has enough buoyancy to punch through. That temperature, where the first thermal breaks out, is the trigger temperature.
`thermal_trigger_temp_c` is the API field that will eventually expose that value at every grid cell and forecast hour, in degrees Celsius. The intended use is straightforward: check the forecast trigger against the actual screen temperature and you know whether thermals have started.
Honest status: the field is in the API response schema today, but it returns `null`. Cloudbase is a single thermodynamic operation on the surface temperature, dewpoint, and pressure (the LCL) and we ship that already. Trigger temperature requires scanning the model's vertical profile, finding the inversion, lifting a surface parcel through it, and identifying the surface temperature at which the parcel would punch the cap. That is robust capping-inversion detection logic and we have not shipped a version we trust yet.
Once it lands, the field will account for the depth and strength of the overnight inversion, which is what actually decides when thermals start. Two days with the same forecast high temperature can have trigger temperatures 3 to 5 C apart if one has a strong inversion and the other has a weak one. Pilots feel this as days that 'fire up late' even though they were forecast warm.
It is also independent of site altitude in a useful way. The field is the surface temperature at that grid cell, so a 400 m hill will have a lower absolute trigger than a valley, reflecting the thinner layer of air that needs to be heated. If you only looked at flatland trigger temperatures and assumed they held for the ridges, you would get the timing wrong.
Limits. On days with strong overnight convection (showers, a front clearing through) the concept starts to break down. The 'inversion' is gone, the boundary layer is already mixed, and thermals start as soon as the sun starts heating the ground. On those days `thermal_trigger_temp_c` should often come out close to the dawn temperature and stops being a useful gate.
It is also a forecast of the trigger, not a guarantee that thermals will actually be strong once they trigger. On cold frontal days the trigger might break at 11 am but the thermals that follow are weak and blown out by gusty wind. Trigger tells you the timing, `wstar_ms` tells you the strength, and `day_rating` tries to combine both.
A practical pattern for a pilot-facing display: show the forecast trigger, the current observed temperature at the site's nearest METAR, and the gap. Live gap shrinking towards zero is the go signal. If the gap has been growing for two hours, the day is not going to happen and you can go back to bed.
Trigger temperature, when it lands, will be one of the three fields that should not be shown in isolation. It lives with `wstar_ms` and `cloudbase_agl_ft` in any useful pre-flight summary. Until then, the API returns `null` for the field and integrators can build their UI around its eventual arrival. Full field documentation on the API reference.