Thompson microphysics, and the WSM6 detour we wasted a month on
We spent October on the wrong microphysics scheme. WSM6 looked cheaper, and it was, but the cloudbase output was unusable. Here is what went wrong and how Thompson fixed it.
Microphysics is the WRF scheme that decides how water vapour becomes cloud and what happens to the cloud after. Cloud droplets, rain, snow, graupel, ice. How they form, how they fall, how they evaporate. For soaring you mostly care about one output: at what altitude does the model decide air has saturated and a cumulus has formed. That altitude, post-processed, becomes `cloudbase_agl_ft`.
When we started, we ran WSM6. WSM6 is a five-class scheme (cloud water, cloud ice, rain, snow, graupel), computationally cheap, and a default in a lot of operational regional setups. The reasoning at the time was: we are a shoestring operation on commodity hardware, microphysics is one of the more expensive parts of the timestep, pick the cheap one and see if it works.
It did not work. On clear-air days with thin cumulus, cloudbase came out within 200 ft of pilot reports, which was encouraging. On days with any real moisture, the forecast cloudbase drifted high by 500 to 1500 ft and was occasionally absent entirely on days that obviously had cloud. Pilots reported flying under a tidy 4200 ft cloudbase while the forecast said 5800 ft or blue.
The first week of debugging went into the post-processing. Maybe we were taking the wrong level, maybe the LCL calculation was off, maybe the AGL conversion was broken. None of that was the problem. The raw WRF fields themselves had the cloud in the wrong place.
The second week went into the PBL coupling. WSM6 does not know about subgrid turbulent moisture fluxes from the PBL scheme, and at 4 km resolution some of the cumulus formation is still sub-gridscale. We tried a shallow-cumulus parameterisation alongside. It helped some, but introduced new problems: now the cloudbase was roughly right on weak days and too low on strong days.
The third week we switched to Thompson, which was meant to be the eventual choice anyway once the pipeline was stable. Thompson is a six-class double-moment scheme (it tracks both the mass and the number concentration of cloud and ice particles). It is more expensive, roughly 15 to 20 percent extra runtime in our configuration, and at our compute budget that is noticeable.
Thompson fixed cloudbase almost immediately. The critical difference is how it handles cloud droplet number concentration. WSM6 assumes a fixed droplet concentration, which over-predicts saturation in clean maritime air (most UK days) and gets cloudbase too high. Thompson computes the concentration from the environment, so cloudbase responds properly to airmass history. On the same set of validation days where WSM6 was 500 to 1500 ft high, Thompson was 100 to 300 ft high, within the noise of pilot altimeter settings.
What we should have known earlier. The WRF user guide is pretty explicit that Thompson is the recommended scheme for forecasting applications where cloud microphysical detail matters, and cloudbase very much does. WSM6 is tuned for operational large-scale work where cost dominates. We picked cost when the application demanded detail, and paid a month of validation debt for it.
There is a lesson in here about validating the whole pipeline end to end before optimising any piece of it. We were trying to make a cheap pipeline work before we had proof the physics were right. Always get one correct run first. Optimise the second run.
Thompson stays. It is the scheme documented on the WRF model page, and every `cloudbase_agl_ft` value the API has ever served has come from a Thompson run. The compute cost is absorbed elsewhere in the pipeline, which is its own post later in the series.