Spin-up: how many hours before WRF output is real
The first few hours of any WRF run are contaminated by the model adjusting to its initial conditions. Here is how we think about it for the UK pipeline today, and what we plan to change.
When WRF starts a forecast, it inherits its atmospheric state from GFS. GFS is at roughly 13 km, running a different dynamical core, different physics, different vertical levels. WRF is at 4 km, with its own dynamical core and its own physics. The first few hours of the WRF run are the model reconciling those two realities: fine-scale terrain features have to develop, the PBL has to adjust, the vertical velocity field has to come out of hydrostatic rest. This is spin-up.
During spin-up, the model output is less trustworthy in ways that matter for soaring. Boundary layer heights oscillate as the local PBL scheme settles. Vertical motion fields carry small numerical artefacts. Precipitation can be light early in the run because the microphysical state has not built up yet. None of this is catastrophic at 4 km with our configuration, but the first couple of hours of any cycle are noisier than the rest.
We currently do not trim spin-up hours from the published artifacts. The 06Z cycle becomes available shortly after the run completes and serves the full 48 h window. The thinking, for now, is that with cycles every 6 hours and a publish lag of about 4 hours from cycle time (GFS's ~3.5 hour publication lag plus our ~34 minute pipeline on the live worker), the freshest available run sits between roughly 4 hours old (just after a cycle publishes) and roughly 10 hours old (just before the next one does). A client that wants to step around spin-up can always pull the previous cycle for the same wall-clock hour: by then those forecast hours have been integrating for several hours longer and are well past the noisy window. Doing that automatically is on us, not the client, and it sits in the same bucket as adaptive trimming.
Trimming the first few hours is on the optimisation list, but it is not as obvious as it sounds. Trim too aggressively and the API loses morning lead time on a 06Z run, which matters in summer when pilots are checking forecasts at breakfast. Trim too little and you publish noisier output. The right answer is probably an adaptive window keyed to convective state, but we are not there yet.
What we do today instead: the cycle metadata exposes the initialisation time, so any client that wants to weight forecast hours by their distance from initialisation can do so. The `/v1/status` endpoint shows when the current cycle landed. Anything more sophisticated than that lives downstream of an actual measurement campaign that we have not run yet.
This post will get rewritten with measured numbers when the validation pipeline lands. Until then, the headline is straightforward: cycles are 6-hourly with a ~3.5 hour publish lag from GFS plus ~34 minutes of Convek pipeline time on the live worker, the noisiest spin-up hours sit at the start of each cycle, and the previous cycle covers them at the same wall-clock time. Full status detail on the model page.