What `wstar_ms` actually tells you
Pilots see `wstar_ms` and read it as thermal strength in metres per second. That is not what it is. Here is what the number actually represents.
`wstar_ms` is the first field most people look at. It has units of metres per second. Pilots fly thermals measured in metres per second. Everyone assumes, reasonably, that `wstar_ms` is the forecast strength of the thermals you are going to fly. It is not, quite.
`wstar_ms` is the Deardorff convective velocity scale, written w*. It is a scaling parameter from boundary-layer meteorology that characterises how vigorously the convective boundary layer is mixing. The formula is:
`w* = ( g / T0 * H * zi ) ^ (1/3)`
where `g` is gravity, `T0` is a reference surface temperature, `H` is the surface buoyancy flux (how much heat the ground is pumping into the air), and `zi` is the depth of the convective boundary layer. It has units of velocity, and it is roughly the speed that a parcel of air released at the ground will rise at, averaged across the whole boundary layer.
That averaging is the crucial bit. Real thermals are not uniform columns of rising air. They are narrow cores of strong lift (often 3 to 5 m/s in a UK summer thermal) surrounded by broader areas of weak sinking air. Conservation of mass means the core updrafts and the surrounding subsidence roughly cancel. w* is the scale of that whole overturning, not the peak updraft in the core.
So a `wstar_ms` of 2.0 does not mean you will core thermals at 2 m/s. It means the boundary layer is convecting with a scale of 2 m/s, and the actual cores inside that boundary layer will be stronger, often roughly 1.5 to 2 times w* in the good cores. A w* of 2 probably gives you 3 to 4 m/s cores. A w* of 3 gives you 4.5 to 6.
This is useful because w* is a model-native quantity. It falls out of the PBL scheme directly, no extra assumptions, no thermal-scale parameterisation. Values above roughly 1.5 m/s are reliably flyable. Above 2.5 m/s is a good day. Above 3 is rare in the UK and usually means convective over-development is coming.
There are a couple of things w* does not tell you. It does not tell you about thermal spacing (how often you find one). It does not tell you about thermal core diameter (how gentle or tight they are). It does not tell you whether cloudbase is high enough to be useful. Those are separate fields or separate forecasts entirely.
In the API, `wstar_ms` is returned alongside `hglider_agl_m` (the capped thermalling ceiling) and `day_rating`. The three together give you the shape of the day: how hard it is thermalling, how high you can go, and how the model scores the combination. If you are building a pilot-facing display, show all three. Showing `wstar_ms` in isolation invites the metres-per-second misreading.
The glossary entry for w* lives on the glossary page, and the WRF model page has the derivation detail. Next field post looks at trigger temperature, the other number worth checking before you drive to the hill.