Why I'm not trying to compete with SkySight
SkySight is the best soaring forecast UI in the world, and I'm a paying user. So why am I building a soaring weather API? Different category. Here is the longer version.
Blog
Notes from the soaring weather pipeline.
Deep-dives on WRF/RASP optimisation, region launches, and the fields the API serves. Written for pilots, developers, and anyone curious about how a regional soaring forecast actually gets made.
Categories
Optimisation
Deep-dives into tuning WRF and RASP for soaring - physics, resolution, and validation.
Coverage
New regions, domain design, and what a given geography means for soaring forecasts.
Field Explainers
What every output field means - wstar, cloudbase, day rating, and more.
Integrations
Case studies of apps, instruments and clubs built on the Convek API.
Dev Log
What shipped recently - monthly summaries of API, pipeline and site changes.
Essays
Longer-form notes on the soaring weather market and building a physics-heavy API.
All posts
Germany coverage is live at 4 km
Wasserkuppe, Hahnweide, Klippeneck, Hochries, Tegelberg - the largest soaring country in Europe at 4 km, four cycles a day, forecast fields as JSON.
What 'Windy has an API' actually means
Windy is the most-recognised weather brand in aviation, and yes it has a developer API. Here is what that API actually returns - and the bit of their pricing page worth knowing about.
Czechia coverage is live at 4 km
Raná, Beskydy, Krkonoše, Kozákov, Doubrava, Javorový - Czech soaring at 4 km, four cycles a day, forecast fields as JSON.
Use Open-Meteo until you can't
Open-Meteo is genuinely great for pilot side projects. Here is the honest version of when you outgrow it and need a soaring-specific API.
When a general weather API isn't quite enough for soaring
meteoblue has a soaring API and it's good. Here is why we still run our own WRF, and when each is the right call.
Austria coverage is live at 4 km
Zell am See, Kössen, Greifenburg, Stubai, Bramberg, Werfenweng, Achensee, Gerlitzen - Austrian soaring at 4 km, four cycles a day, forecast fields as JSON.
Pruning the worker: how four cycles a day stay off a disk-full alert
Each WRF cycle leaves behind a timestamped working directory worth a few gigabytes. Multiplied by four cycles a day, the disk fills in a fortnight. Here is the small retention helper that keeps the live worker tidy without losing benchmark scratch.
Slovenia coverage is live at 4 km
Soča Valley, Tolmin, Lijak, Kobarid, Kobala, Vogel, Stol, Krvavec - the Slovenian soaring map at 4 km, four cycles a day, forecast fields as JSON.
The first piece of validation: a baseline vs candidate diff at named points
Every previous optimisation post says 'we'll measure this when validation lands'. The first piece of that pipeline shipped this month - a head-to-head diff between two cycle runs at named pilot sites. Here is what it does, what it does not, and why it was the right first step.
Switzerland coverage is live at 4 km
High-resolution soaring forecasts across the Swiss Alps. Interlaken, Verbier, Grindelwald, Fiesch, Niederhorn, Mythen, Engelberg - all inside a 4 km domain, four cycles a day, forecast fields as JSON.
Convergence lines: reading `horizontal_convergence_s1`
Convergence lines are the long-distance pilot's quiet superpower - thin streets of forced lift you can fly along without ever circling. Here is what the new convergence and divergence fields actually represent and how to read them.
Why Czechia makes sense for soaring forecasts
The country in the European batch that is least obviously a soaring forecast problem and most actually one. Here is why Czechia is in the first batch.
Why Austria belongs in the first expansion batch
The Tirol valleys are the country where the case for a regional model writes itself. Here is why Austria sits in the first European batch.
Why Slovenia is in the first expansion batch
Tolmin and the Soča Valley pull thousands of pilot-days a summer. Here is why Slovenia is in the first European batch alongside the larger Alpine countries.
Cutting GFS ingest from minutes to two minutes with subset GRIB
The first step of any WRF cycle is downloading the global model fields that drive it. Pulling full GFS files takes a long time. Pulling only the subset we need takes about two minutes. Here is how the live ingest works.
Radiation call frequency: the trade-off behind `radt`
WRF's radiation schemes are expensive, so they run on a longer interval than the dynamics. The shipping interval is 30 minutes. Here is the trade and what we would test before changing it.
Why Switzerland was first in the expansion batch
The first European country in the expansion batch. Why Switzerland made sense as the first country after the UK.
Grid forecasts are live
Convek now serves grid field slices through /v1/grid, so apps, club pages, and hardware teams can build real map layers without spamming point requests.
UK coverage is live at 4 km
The Convek API now serves high-resolution soaring forecasts across England, Wales, and southern Scotland. WRF at 4 km, four runs a day, forecast fields available as JSON.
Why run your own WRF at all?
Global weather models stop being useful for soaring long before you reach the thermal layer. Here's why Convek runs WRF at 4 km instead of serving GFS like everyone else.
Why the live UK forecast runs on a trimmed domain (and is roughly 5x faster as a result)
Comparing a full-UK 4 km box against a tighter trimmed domain on the same cycle, the trimmed run finished WRF in about 13 minutes instead of nearly an hour. Here is the trade and why we made it.
Validation: where the forecast stands
We do not yet have an automated verification pipeline. Here is what we currently rely on to know whether the forecast is working, what we plan to build, and how to spot a bad day in the meantime.
Sounding and XContest validation: the comparison we plan to build
We do not have automated validation against radiosonde soundings or XContest flight activity yet. Here is what we plan to build, and why it is non-trivial.
Day rating is a label, not a magic number
`day_rating` is a composite label: poor, marginal, fair, good, or excellent. Under the hood it comes from an internal score, but the API returns a readable label. Here is how to interpret it without being misled.
MPI tuning on the WRF host: what we have actually measured
WRF performance tuning is a deep rabbit hole. Here is what we know about our MPI setup, what we have measured directly, and what is still educated guessing from sensible defaults.
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.
Reading a forecast sounding without overreading it
The sounding endpoint gives you the full vertical profile at any point in the domain. Here is how to read the things a sounding is good for and ignore the things it is not.
Noah, not Noah-MP: the land surface scheme we ship today
We run the original Noah land surface model in the Convek pipeline, not the more sophisticated Noah-MP. Here is why, what it costs us, and what would push the upgrade onto the roadmap.
Soil moisture from ERA5: the next initial-condition upgrade
Soil moisture in the live pipeline comes from GFS, which can lag reality after fast-moving wet fronts. Switching to ERA5 reanalysis would help. Here is the trade and where it sits in the queue.
Boundary layer height vs soaring height: they are not the same
`boundary_layer_m` and `hglider_agl_m` are two different numbers in the API. They come from the same meteorology but mean different things, and mixing them up gives you the wrong briefing.
How we currently derive cloudbase: T2, Q2, and PSFC
Cloudbase in the API today comes from a surface-parcel LCL using 2 m temperature, 2 m mixing ratio, and surface pressure. Here is what that gets right, what it gets wrong, and where it is going.
Mixed-layer LCL: the cloudbase formulation upgrade we have not shipped
Today's cloudbase comes from a surface-parcel LCL. The standard upgrade is a mixed-layer LCL averaged over the diagnosed PBL depth. Here is what that would change and what is in the way.
`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.
Picking YSU from the literature
We ship the YSU planetary boundary layer scheme. We picked it the way most operational regional setups do - from the published evidence on what works at this resolution. Here is the reasoning.
MYNN-2.5 as the next PBL scheme to test against YSU
We ship YSU. MYNN-2.5 is the most credible alternative for daytime convective forecasting. Here is the comparison we plan to run, and what makes it worth running rather than picking from the published evidence alone.
Trigger temperature: the most useful number before breakfast
`thermal_trigger_temp_c` is the surface temperature that has to be reached before the first thermal of the day breaks the morning inversion. The field is in the API today as a placeholder. Here is what it will do once it lands.
Why we ship WSM3 microphysics (and why we have not moved off it yet)
WSM3 is the cheapest microphysics scheme in WRF. It is also what we ship. Here is why that was the right starting point and what would push us to change it.
Thompson microphysics: what we would want to test before switching
We ship WSM3 today. Thompson is the obvious next-step microphysics for soaring forecasting. Here is what we would want to validate before paying the extra runtime cost.
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.
Vertical levels: why the bottom 3 km gets most of the detail
WRF gives you a vertical stack of eta levels to spend however you like. For soaring, almost all of them should live in the lowest few kilometres.
Designing the UK domain: where the edges go
The first decision in any WRF setup is where the model sees air. Here is how the Convek UK domain is laid out and why the boundaries sit where they do.