hrrr

NOAA HRRR — 3-km CONUS model via anon S3 (``noaa-hrrr-bdp-pds``). Key pattern: ``hrrr.YYYYMMDD/conus/hrrr.tCCz.wrfsfcfFF.grib2``. For every top-of-hour valid time in the window (at most :py:attr:`max_steps`; a longer window reads the newest and records the rest in ``refused_windows``) it uses the analysis (``f00``) of the cycle at that hour when published, otherwise the shortest lead from the newest earlier cycle that has it — so a window reaching past "now" gets the latest forecast. Listings use the dated per-cycle prefix; the bucket-root listing used to return July 2014. Downloads are byte ranges, not files: the ``.idx`` sidecar gives each message's offsets, and only 2 m temperature, 10 m wind components and surface downward shortwave are fetched (~7 MB per valid hour instead of a ~90 MB file), each capped at :py:attr:`max_message_bytes`, the whole fetch at :py:attr:`max_bytes` (valid hours are read newest first, so a spent budget leaves out the OLDEST hours, again recorded in ``refused_windows``). Units: ``hrrr_t2m`` °C, ``hrrr_u10``/``hrrr_v10`` m/s, ``hrrr_ssrd`` W/m² (instantaneous DSWRF, *not* an accumulation). For analysis hours, ``hrrr_ssrd`` comes from the previous cycle's ``f01`` when published: the ``f00`` DSWRF is an analysis-time diagnostic that runs far low after dawn (34 vs 144 W/m² in a live check), while forecast-lead values match Open-Meteo's HRRR feed to within 1 W/m². **Vintages are model runs, as published.** Every row's ``vintage_ts`` is the cycle it was read from plus :data:`HRRR_PUBLICATION_LAG` (never later than the fetch): the time the run could first have been read. It used to be the bare initialisation time, an hour before ``f00`` exists on the bucket - a backtest "as of" a cycle's init time saw a forecast nobody had yet. An analysis hour's ``f00`` → the hour + 1 h; its ``hrrr_ssrd`` from the previous cycle's ``f01`` → the hour itself. Refetching rewrites the same vintage. Besides that analysis series, the synoptic runs (00/06/12/18Z) initialised in the window are stored whole, ``f00``-``f{run_horizon_h}`` (newest :py:attr:`max_runs`, i.e. the last day's four), each step under its run's vintage; ``f00`` DSWRF is left out of a run for the reason above. The latest view is unchanged by this: a valid hour's analysis (vintage = the hour + lag) is newer than any forecast of it. A synoptic run not yet complete is skipped while younger than :py:attr:`run_posting_grace`, raises when older; a listed step that cannot be read raises — a run is stored whole or not at all. Cost per run: 1 listing + 19 idx + 75 ranges, ~8.5 MB per step (probed 2026-10-03), ~160 MB. The point must lie in the CONUS domain (default: Denver); a point outside it raises :class:`ConnectorError` rather than sampling the domain edge.