What each model can, and cannot, tell you

Eleven models publish through one contract, but their fields differ in measurement, cadence, and availability. A blank can accurately state that a feed omits a quantity. The model catalogue (models.json) declares what each field means and whether each model publishes it.

ECCC and NOAA publish these model products openly and at no cost, and each centre documents its own conventions. The differences are real properties of different modelling systems doing different jobs. The catalogue carries those properties to the display intact.

Generated from models.json; pressure columns share a 1015–500 hPa scale.

Capabilities are read from models.json. Blank cells are declared absences; omega marks only the pressure levels where the provider publishes vertical velocity.Units grid spacing km · cadence and horizon h · pressure hPa

The rest of this page explains those cells. It covers where two identical-looking numbers are different claims and where a blank is the model’s own statement.

A 40 km/h gust is two different claims

Both providers publish a 10 m gust, and the catalogue declares a different meaning for each. An ECCC gust is the strongest gust the model produced at any internal timestep during the hour ending at the valid time, which is the pilot’s “gusting to”. A NOAA gust is the model’s diagnostic gust at the valid time itself, one sample from the hour over which the ECCC number takes a maximum. The hour-maximum reads systematically higher. An ECCC 40 beside a NOAA 32 can be two models in agreement, and two identical numbers can be two different forecasts.

Each centre publishes what its system computes, and both meanings are valid. A display that prints both under one label as if they were comparable would be wrong. The catalogue therefore declares gust semantics (an hour-maximum, an instantaneous sample, or nothing) rather than gust presence, and the readout wording follows the declaration. Only the hour-maximum supports “gusting to”. The forecast model feed reference holds the evidence, including how the hour-window semantics were established when the files’ own interval metadata could not answer.

Smoke is a coupling claim

capabilities.smoke carries three values because whether a model publishes smoke is only half the fact. "radiativelyCoupled" (HRRR, RRFS) means the model’s forecast smoke attenuates its own shortwave. Its published fluxes, and every thermal quantity derived from them, already account for smoke, so applying a smoke correction on top would double-count the plume. "passive" means smoke rides along without touching the model’s radiation, and a correction is legitimate. false means no smoke at all. For those models smoke arrives, if anywhere, as a separate smoke document from another model, and the profile does not carry it. Documents echo the token as semantics.smoke. The renderer’s smoke-adjusted view refuses to run wherever the declaration says the base picture already accounts for smoke. See Smoke and thermals.

One model’s lift is native, another’s is converted

Every omega in the dataset is in pascals per second, with negative values as lift, but not every model computed its own. Most capable models publish their own omega. RRFS publishes geometric vertical velocity (metres per second) instead, and the builder converts it at build time through the hydrostatic relation ω ≈ −ρgw, with dry-air density from the level’s own pressure and temperature. The catalogue therefore declares where vertical velocity comes from rather than only whether it is present. "omega" marks a provider’s own pressure tendency and "fromGeometricW" marks a converted value, so a display can label converted lift differently from native lift instead of blending the two claims. The forecast model feed reference records the conversion and its assumptions.

Surface-based CAPE

NOAA publishes a menu of CAPE variants, several parcel definitions that each answer a different storm question. ECCC publishes exactly one, surface-based. The forecast engine publishes the surface-based variant everywhere. Every capable model shares it, and it also fits the question. On a surface-heated soaring day, the parcel that might overdevelop is the thermal the pilot is climbing in, and at peak heating the surface parcel is typically also the most unstable one on offer.

Surface-based CAPE says how much energy the afternoon’s thermals can tap if they reach free convection. It does not say whether they get there. A morning cap can hold everything down, and CIN describes that. Surface-based CAPE is also blind to elevated instability above a stable surface layer, which matters for night-time storms but rarely for the daytime question this chart asks. A large CAPE value measures fuel and says nothing about timing.

When a model says nothing, believe it

Absence in this dataset comes in two kinds.

The first is within a grid. ECCC encodes “convection not computed at this point” as ordinary-looking numbers inside the CAPE and CIN fields, over large fractions of the grid on any given run. The feed reference records the sentinel values and how much of the field they cover. The builders mask them to absence and do not write zero, because zero CAPE is a strong claim of stability the model did not make. A published gap means the model declined to answer. A frontend that fills it with 0 turns the gap into misinformation.

The second is a model property. Both HRDPS models compute no CIN at all, so the catalogue declares CAPE without CIN. The catalogue declares the two capabilities separately precisely because the quantities are so often mentioned together. On the highest-resolution models the fuel is published without the cap, and a renderer must present that story as incomplete. Showing CIN as 0 there would read as “no inhibition, expect early overdevelopment”, a forecast nobody issued.

A field can exist at one hour and not the next

GDPS runs to ten days on a schedule with regimes, and its convective fields thin out one regime earlier than its other surface fields. Late in the horizon, every other column carries a gust and a boundary-layer height but no CAPE, while its neighbours carry all three. Absence is therefore not even constant for one model, because it varies hour by hour inside a single chart. The document omits the field at hours the feed does not publish it, and the strip has no cell there. Read the gap as “not published for this hour”. It does not mean the risk passed between two columns.

Ensemble spread exists only where members publish

REPS publishes real ensemble soundings (every member’s temperature, moisture, and wind, reduced to percentiles under the accounting rules in Ensemble values), yet none of the gust, CAPE, CIN, or boundary-layer-height families exists per member. Its capabilities for all four are false, so there is no REPS storm-risk spread to draw, and none can be manufactured from percentile temperature blocks after the fact. GEPS, the global ensemble, is where that product lives. Its raw files carry per-member CAPE and CIN, and the catalogue’s geps entry publishes their spread as percentile blocks. It is the one feed here whose members disagree about storm energy on the record. An ensemble panel showing CAPE spread from any other model is showing something other than members.

Cloud shading is two kinds of evidence

GFS is the only model here that publishes cloud fraction on pressure levels, which is model cloud with altitude attached. HRRR, RRFS, and both NAM models publish low, middle, and high layer fractions without a profile. GFS carries those layers as well as its profile. Every ECCC model publishes a single total-column percentage. The cloud shading in the chart body therefore means different things by model. Where the model publishes its own per-level cloud, the renderer shades from it, and the shading is the model asserting cloud. Everywhere else the shading is an inference. It marks levels whose dew-point depression says the air is nearly saturated, where cloud is a reasonable guess. The two routes land in the same visual classes so the chart reads the same way for every model. The model’s own cloud wins wherever it exists, and the catalogue’s cloud-profile flag declares which route a model is on. The layered strip appears only for models that publish layers. On the ECCC models its absence is a statement about the feed rather than a rendering gap.

Render the declaration

The catalogue is the machine-readable version of this page. For each model it lists which pressure levels, which fields, and which semantics. A frontend should render exactly what a model declares and let absence show. It should not invent zeros, borrow semantics, or pad columns for symmetry, and its wording should follow the declared meaning rather than the field name. A reader should distrust any display on which every model appears to say the same things. Models differ, and when the charts do not, someone between the model and the screen has been filling gaps.