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 much we discard and why the four-daily cadence is designed around it.
When WRF starts a forecast, it inherits its atmospheric state from GFS. GFS is at 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 to Noah-MP rather than Noah, the vertical velocity field has to come out of hydrostatic rest. This is spin-up.
During spin-up, the model output is physically implausible in ways that matter for soaring. Boundary layer heights oscillate. Vertical motion fields are full of numerical artefacts. Precipitation is either missing entirely (no microphysical state to support it) or wildly overdone (condensation catching up all at once). You cannot serve these hours to pilots.
How long spin-up takes depends on the configuration. For our UK 4 km setup with Thompson, YSU, Noah-MP, spin-up is roughly 3 to 6 hours. The PBL settles within 2 to 3 hours. The microphysics fields take 4 to 5. The land surface (see the soil moisture post) can take longer again if the initial soil state is far from reality, but that is a separate problem.
We discard the first 6 hours of every run. The forecast we serve starts at t+6h from the initialisation time. That means the 00Z run starts being usable at 06Z, the 06Z run at 12Z, and so on. This is why the four-daily cadence (00/06/12/18Z) is not incidental: the cadence is chosen so that at any point in the day, there is a fresh forecast whose spin-up has completed and whose serving window has begun.
The run length matters here too. We run each cycle out to 48 hours of forecast. The first 6 are discarded, leaving 42 hours of usable forecast. Six hours later the next cycle takes over, so any given forecast hour is covered by at least one complete, spun-up run, and often two. The API selects the freshest completed run whose spin-up has elapsed.
What happens if spin-up is set too short. We tried 3 hours early in development. The 12Z forecast for morning-of-day-one was noticeably bad: cloudbase oscillated, `wstar_ms` had a characteristic first-hour dip followed by an over-correction spike, `day_rating` bounced around. Pilots reported forecasts that 'flickered' as runs changed over, which is the symptom of one run being spun up and the adjacent one not quite being.
What happens if spin-up is too long. You lose forecast lead time: if you only start serving at t+12h, the 00Z run gives you nothing before noon, and you need more runs per day to cover the flying window. For our compute budget, 6 hours is the balance. If we were running at 1 km or with a noisier initialisation, we would extend it.
A subtle point: the spin-up window can depend on the weather regime. Stable, synoptically-quiet days spin up fast (the model has nothing to do). Convective days spin up slower (the model is building a microphysical state from scratch). A fixed 6 h window is a compromise. Adaptive spin-up is an open research problem we have not committed to.
For users of the API, the spin-up is invisible. The `/v1/status` endpoint shows when the current cycle was initialised and when it became servable. If you are building automation that needs to know when a fresh run has landed, that is the endpoint to poll. Full details on the API reference.