All posts
Field Explainers·5 min read

`hglider_agl_m`: the glider-capped thermalling ceiling

`hglider_agl_m` is the height a glider can actually work up to, capped by cloudbase and the top of the useable thermal layer. It is not the raw boundary layer height.

`hglider_agl_m` is the forecast ceiling of useable thermalling, in metres above ground level. It is one of the fields pilots check first, because it tells you the top of your working altitude band on a given day. On a 1600 m `hglider_agl_m` day at the Long Mynd, you have about 1600 m of working height above launch before the lift stops.

The name contains the key detail. It is AGL (above ground level), not MSL (above sea level). That means the number is already corrected for terrain: the 1600 m at the Mynd and the 1600 m above a Kent hill are both 1600 m of climbable air above the ground immediately below. No altimeter mental arithmetic required.

How it is derived. Start with the raw boundary layer height from the PBL scheme, which we call `boundary_layer_m` and which has its own post next month. That is the physical top of the convective layer, where the potential temperature stops being well-mixed. Then compare it to cloudbase (the LCL from the post-processed moisture profile). `hglider_agl_m` is the minimum of the two, minus a small safety margin at cloudbase to account for cloud suck.

The minimum matters because either can be the limiter. On a blue day with a capping inversion at 1400 m and no moisture to form cloud, the boundary layer height is the cap. On a humid day with cloudbase at 1100 m over a boundary layer that wants to grow to 2000 m, cloudbase is the cap. Both are normal. Pilots need one number that tells them the working ceiling, and this is it.

A common question: why not just use boundary layer height directly? Because boundary layer height is a thermodynamic concept, not a pilot-usable altitude. In the upper 10 to 15 percent of the boundary layer, the convective signal weakens: mixing is still happening but the buoyancy drops off, and thermals top out below the formal PBL top. `hglider_agl_m` has that top-of-layer weakness accounted for, so the number you get is the altitude a glider actually reaches when it stops finding lift, not the altitude the boundary layer nominally extends to.

The safety margin at cloudbase deserves a note. Cumulus clouds grow by sucking air up through their base, so the last 100 to 200 ft under a cloud is often stronger than the thermal that fed it. Pilots who misjudge this end up inside the cloud, which is illegal for most soaring operations and unpleasant for all of them. `hglider_agl_m` sits about 100 m below forecast cloudbase when cloudbase is the cap, which is a sensible planning ceiling without being over-cautious.

What `hglider_agl_m` does not do: it does not tell you about overdevelopment, spreadout, or convergence. A day can have a healthy `hglider_agl_m` and be flyable for two hours before the sky closes out. It also does not tell you about wave above the inversion, which is a separate forecast problem not yet exposed in the API.

Pair it with `wstar_ms` for strength and `cloudbase_agl_ft` for the reason for the cap, and you have the three fields a briefing screen needs. Full docs on the API reference.