Layer 3 — Meteorological Data

Layer 3 is the foundation: public numerical weather prediction (NWP) model output and observed ground truth. This is the same data available to everyone — the engine's value is in what it does with it, not in exclusive access.

NWP Models

GFS (Global Forecast System)

GFS is the primary ensemble source for probability estimation. The 31-member GEFS ensemble provides the base probability distribution for all five weather variables.

ECMWF (European Centre for Medium-Range Weather Forecasts)

ECMWF is widely regarded as the best global NWP model. The 51-member ensemble provides richer probability information than GFS. The engine uses both GFS and ECMWF with model-specific bias correction and pooled member counting (82 total members).

HRRR (High-Resolution Rapid Refresh)

HRRR provides the highest spatial resolution for US locations. It's deterministic (no ensemble), so it's used as a high-resolution point estimate rather than a probability source.

NWS-LAMP (Localized Aviation MOS Program)

LAMP is the most directly comparable public forecast to what the engine produces. If the engine can't beat LAMP at D+1 station-level temperature forecasting, the bias correction and ensemble weighting aren't adding value.

LAMP access: The engine parses the live LAMP bulletin at lamp.mdl.nws.noaa.gov/lamp/Data/bull/lavlamp.txt — a single ~5 MB text file containing all ~2,000 CONUS stations, updated hourly. The parser extracts the TMP row (hourly temperature in degrees F) for each ICAO station and derives the daily high from the maximum across forecast hours. Implementation: src/data_ingestion/lamp_forecast.py.

Observed Data (Ground Truth)

IEM (Iowa Environmental Mesonet)

The primary source for US station data. Free, clean, station-level ASOS/AWOS data covering all major airport stations with decades of history. Used for all non-irradiance variables.

API: mesonet.agron.iastate.edu/cgi-bin/request/daily.py

Variables downloaded from IEM:

All implemented in src/data_ingestion/iem_observed.py.

ERA5 Reanalysis

IEM has no solar radiation data. The engine uses ERA5 reanalysis as independent ground truth for irradiance.

Implementation: download_era5_irradiance() in src/data_ingestion/open_meteo_reanalysis.py.

NWS Climatological Reports

The official settlement source for ForecastEx contracts. Published the morning after each observation day. Contains verified maximum/minimum temperature for the official reporting period.

Phase 0 — Baseline Accuracy (All Variables)

Temperature — Daily High (GFS)

Period: January 1 – March 31, 2026 (90 days, 10 cities, 900 city-days)

Key findings:

• Consistent cold bias — GFS underforecasts daily highs at 9/10 cities (mean bias -0.74°F)
• City-specific patterns — Phoenix (-1.45°F), Atlanta (-1.42°F), and Miami (-1.22°F) have the largest biases
• NYC has highest RMSE (1.99°F) — the most variable forecast errors, making it the best ForecastEx market for probability-based trading
• Chicago is near-zero bias (+0.01°F) — hardest city to improve upon with correction alone

Rainfall (GFS precipitation_sum vs IEM precip_in)

Period: Jan–Mar 2026, 10 cities.

Low MAE reflects the preponderance of dry days. GFS quantitative precipitation forecasts are essentially unbiased at the daily level, though individual storm events can have large errors.

Wind Speed (GFS wind_speed_10m_max vs IEM max_wind_speed_kts)

Period: Jan–Mar 2026, 10 cities.

GFS 10m grid-average wind systematically overforecasts compared to IEM station-level sustained wind. This is a known scale mismatch: GFS represents the average wind over a ~28km grid cell, while ASOS measures point observations at a single anemometer. The multiplicative correction ratio of ~1.61x addresses this effectively.

Irradiance (GFS shortwave_radiation_sum vs ERA5)

Period: Jan–Mar 2026, 10 cities.

GFS irradiance forecasts have a small negative bias against ERA5 reanalysis. The engine normalises to a clear-sky index (CSI = actual / theoretical clear-sky) before applying the Beta distribution, which handles the bounded [0, 1] domain naturally.

Phase 1 — Bias Correction Results (All Variables)

Temperature — Additive Correction

Per-city, per-month additive bias correction trained on Jan–Feb 2026, tested on March 2026:

Key findings:

• Bias eliminated — overall reduced from -0.74°F to 0.00°F
• MAE improved 16% — from 1.26°F to 1.06°F
• NYC and Chicago slightly worse — training bias overshoots for March. Suggests seasonal or regime-specific correction needed.
• Correction is simple — corrected = raw + bias, per-city, per-month

Rainfall — Multiplicative Correction

ratio = mean(observed_wet) / mean(forecast_wet)   per (station, month)
corrected = raw * ratio

With p_zero_obs and p_zero_fct stored for zero-inflated Gamma probability computation. The multiplicative method preserves the zero bound (additive correction can produce negative rainfall).

Wind — Multiplicative Correction

Same method as rainfall. The large scale mismatch (GFS overforecasts by ~7 mph) is captured by the ratio parameter, which is typically ~0.6 (GFS values need to be scaled down to match station observations).

Irradiance — Multiplicative Correction

Applied to raw MJ/m^2 values before clear-sky index computation. Small correction needed (GFS irradiance bias is only -0.13 MJ/m^2).

Phase 1 — Calibration Scores (All Variables)

All variables comfortably pass the Brier < 0.10 target. Rainfall shows the largest calibration improvement, likely because the zero-inflated distribution introduces systematic raw probability biases that isotonic regression corrects effectively.

Access via Open-Meteo

Rather than pulling raw GRIB2 files from NOMADS, the engine uses the Open-Meteo API — a free service that provides parsed, JSON-formatted NWP data with no API key required.

This simplifies the ingest pipeline significantly: instead of downloading, parsing, and spatially interpolating multi-gigabyte GRIB2 files, the engine makes REST API calls for specific locations and variables.

Three endpoints used:

The download_historical_forecasts() function in src/data_ingestion/open_meteo.py accepts configurable variables, unit_params, and value_columns parameters, allowing it to serve all registered weather variables through a single function. The download_ensemble_forecast() function similarly accepts a value_col parameter for generalized column naming.