prop/docs/plans/2026-04-29-hrdps-canadian-prop-grid.md

HRDPS Canadian Propagation Grid Implementation Plan

For Claude: REQUIRED SUB-SKILL: Use superpowers:executing-plans to implement this plan task-by-task.

Supersedes: docs/plans/2026-04-13-hrdps-canadian-prop-grid.md — that plan was written before the probe wedge surfaced two architectural realities that change Stage 1's design: ECCC moved the datamart URL structure (the old /model_hrdps/ root 404s now), and HRDPS publishes one variable per GRIB2 file rather than HRRR's bundled wrfsfcf/wrfprsf format. Major filenames, fetch shape, and idx assumptions are different.

Goal: Extend the propagation scoring grid into Canada at 0.125° (matching the existing CONUS sample density) sourced from HRDPS, so /map shows scores across all of North America. Hourly Canadian scores via the cycle's f00..f18 forecast hours; HRRR wins where it has coverage and HRDPS fills the rest.

Architecture: Build a parallel NWP ingestion pipeline (HrdpsClient → HrdpsGridWorker → hrdps_profiles table) that mirrors the HRRR shape. The single-variable-per-file difference is hidden inside HrdpsClient: it fetches the ~14 needed variable files concurrently, then runs wgrib2 -merge to produce a single multi-variable GRIB2 that downstream code can consume identically to a wrfsfcf/wrfprsf blob. HRDPS runs at 00/06/12/18Z and seeds f00..f18 (hourly) into the score chain, so Canadian scores refresh once per cycle but provide hourly forecast steps until the next cycle lands. Border stitching: a static Grid.hrdps_only_points/0 mask carves Canada-only cells so HRRR and HRDPS never both write the same (lat, lon).

Tech Stack: Elixir 1.15, Req, Postgres + Ecto, Oban, wgrib2 (already in image), Rust (for prop-grid-rs and hrrr-point-rs HRDPS branches)

Prerequisite: Stage 0 already done — the probe at lib/mix/tasks/hrdps_probe.ex retired the URL/projection/decode risks against the live datamart on 2026-04-29.

---

Status snapshot (2026-04-29)

Shipped — Elixir foundation complete:

• ✅ Stage 0: Probe wedge (mix hrdps.probe)
• ✅ Stage 1: HrdpsClient with URL/variable catalog, concurrent fetch + byte-concat, fetch_grid/3, cycle_available?/1 — lib/microwaveprop/weather/hrdps_client.ex
• ✅ Stage 2: hrdps_profiles partitioned table + HrdpsProfile schema
• ✅ Stage 3 (Elixir-side): Grid.hrdps_only_points/0, Grid.point_source/1, grid_tasks.source column, GridTaskEnqueuer source-aware seeding, HrdpsGridWorker seeder
• ✅ Stage 8: SRTM scope decision recorded — Option 1 (cap Canadian coverage at 60°N for v1; defer Arctic CDEM to a follow-up plan)

Deferred — needs the Rust counterpart before it can ship:

• ⏸ Stage 4: prop-grid-rs Rust HRDPS branch (~4 days). Until this ships, HrdpsGridWorker stays out of the cron — its module doc explicitly notes it is dormant scaffolding.
• ⏸ Stage 5: hrrr-point-rs Rust HRDPS branch (~1.5 days)
• ⏸ Stage 6: cycle scheduling cron entry — depends on Stage 4
• ⏸ Stage 7: map overlay bounds widening — depends on real data in /data/scores
• ⏸ Stage 9: FreshnessMonitor HRDPS staleness tracking — depends on real cycle data flowing

Activation path once Rust ships:

1. Land the Rust HRDPS branch + redeploy prop-grid-rs and hrrr-point-rs.
2. Add to config/runtime.exs cron: {"35 5,11,17,23 * * *", Microwaveprop.Workers.HrdpsGridWorker}.
3. Widen MapLive.@initial_bounds to (23.5, 60.0, -141.0, -52.0).
4. Extend FreshnessMonitor with hrdps_last_run_at.

The hardest decisions (cycle cadence, border stitching, variable mapping, projection) are settled and encoded in code. The remaining work is mechanical port-and-wire-up.

---

Stage 0: Probe wedge (DONE)

mix hrdps.probe proves the GRIB2 fetch + wgrib2 reprojection works end-to-end against the real ECCC datamart. Output verifies plausible Canadian temperatures at 5 cities. Throwaway code; will be deleted in Stage 10 once HrdpsClient covers the same surface area.

Findings that drive the rest of the plan:

• URL: https://dd.weather.gc.ca/{YYYYMMDD}/WXO-DD/model_hrdps/continental/2.5km/{HH}/{FFF}/{YYYYMMDD}T{HH}Z_MSC_HRDPS_{VAR}_{LEVEL}_RLatLon0.0225_PT{FFF}H.grib2
• Variable naming: MSC's {VAR}_{LEVEL_TYPE}-{LEVEL_VALUE} (e.g. TMP_AGL-2m, TMP_ISBL_0850) — different from NCEP's HRRR short-name format
• One variable per file (~3.5 MB each); no idx file / no byte-range partials
• wgrib2 reprojects rotated lat/lon natively via -lon LON LAT — no manual rotation math
• Publish latency: ~3-4h after each cycle (verified by cycle availability at probe time)

---

Stage 1: HrdpsClient — per-variable fetch + wgrib2 -merge

Decision recorded: Fetch each variable's GRIB2 file concurrently, then run wgrib2 -merge to combine into a single multi-variable file before downstream decode. Keeps the existing hrrr_profiles-shaped derive pipeline intact downstream of the client. The disk-staging cost (~14 files × 3.5 MB into a tmp dir per cycle/forecast hour) is small compared to the fetch time.

Files:

• Create: lib/microwaveprop/weather/hrdps_client.ex
• Create: test/microwaveprop/weather/hrdps_client_test.exs
• Create: test/support/fixtures/hrdps_sample_*.grib2 (small fixtures captured from a real cycle)

Task 1.1: URL builder (TDD)

Write a failing test for HrdpsClient.grib_url(:tmp_2m, run_time, forecast_hour) returning the date-prefixed datamart URL with the MSC filename format. Verify against a known-good URL from the probe (20260429T12Z_MSC_HRDPS_TMP_AGL-2m_RLatLon0.0225_PT000H.grib2). Implement; commit.

Task 1.2: Variable catalog

Define a @variables map mapping internal atoms (:tmp_2m, :dpt_2m, :pres_sfc, :wind_u_10m, :wind_v_10m, :apcp_1h, :tcdc, :pwat, :tmp_850mb, :tmp_700mb, :tmp_500mb, :dpt_850mb, :dpt_700mb, :hgt_850mb) to MSC variable + level slugs ({VAR_AGL-2m}, {VAR_ISBL_0850}, etc.).

This is the variable-mapping table the old plan called out as a Stage-1 risk; build it explicitly. TDD: a variable_slug/1 test for each atom. Commit.

Task 1.3: Concurrent fetch + tmp staging (TDD)

Write a failing test for fetch_cycle_files(run_time, forecast_hour, opts) that returns {:ok, [paths]} of the per-variable GRIB2 files staged in a tmp dir. Use Task.async_stream with max_concurrency: 4 (datamart isn't aggressively rate-limited but we don't need >4 in flight). Mock with Req.Test.stub per project conventions.

Critical: every {:exit, _} and {:error, _} clause from the async_stream must Logger.error with variable name + URL — per CLAUDE.md "always log anything that would normally be swallowed" and the path-calculator outage memory. A silently-dropped fetch in production is a Canadian dead-zone we won't notice for hours.

Implement; commit.

Task 1.4: wgrib2 -merge into multi-variable file (TDD)

Write a failing test for merge_to_multivar(paths, output_path). Implement via System.cmd("wgrib2", ["-merge", path1, path2, ..., "-grib", output_path]). Verify the merged output's wgrib2 file -V lists all expected variables.

Commit.

Task 1.5: fetch_grid/3 — public API matching HrrrClient.fetch_grid/3

Same signature as HRRR so Stage 3's worker can call either polymorphically:

@spec fetch_grid([{float(), float()}], DateTime.t(), keyword()) ::
        {:ok, %{{float(), float()} => map()}} | {:error, term()}
def fetch_grid(points, run_time, opts \\ [])

Internally: fetch_cycle_files → merge_to_multivar → reuse Microwaveprop.Weather.GribDecoder (the existing HRRR decoder, projection-agnostic since wgrib2 handles rotation).

TDD; commit.

Task 1.6: Projection sanity check (TDD)

Pick CYYR (Goose Bay, 53.32°N, -60.42°W) and a recent cycle for which we have a UWYO Canadian sounding (those exist via CanadianSoundingFetchWorker). Test that the HRDPS surface temp at CYYR is within ±3°C of the radiosonde surface temp for the same valid_time. If they don't match, the projection is wrong and wgrib2 -lon is being called incorrectly.

This is the most important test in the stage — burn whatever time is needed to make it pass. A 10 km projection offset is invisible on the map but destroys terrain analysis at Stage 5+.

Commit.

---

Stage 2: hrdps_profiles schema

Files:

• Create: priv/repo/migrations/{timestamp}_create_hrdps_profiles.exs
• Create: lib/microwaveprop/weather/hrdps_profile.ex
• Create: test/microwaveprop/weather/hrdps_profile_test.exs

Task 2.1: Migration mirrors hrrr_profiles

Same columns, same indexes, daily partitioning on valid_time. Separate table (not a unified nwp_profiles) so HRDPS can be dropped/reprocessed without disturbing the 4500+ HRRR profiles already in prod.

@primary_key {:id, :binary_id, autogenerate: true} per project convention.

Run migration in dev; verify table + indexes; commit.

Task 2.2: HrdpsProfile schema + changeset (TDD)

Identical to HrrrProfile. Same derived fields (surface_refractivity, min_refractivity_gradient, ducting_detected, duct_characteristics, pwat_mm, hpbl_m).

Commit.

Task 2.3: Partition pruning cron

Add an Oban.Plugins.Cron entry mirroring whatever HRRR uses (or add one if HRRR doesn't have one yet — the prod DB will fill up either way).

Commit.

---

Stage 3: HrdpsGridWorker — score Canadian grid per forecast hour

Files:

• Create: lib/microwaveprop/workers/hrdps_grid_worker.ex
• Create: test/microwaveprop/workers/hrdps_grid_worker_test.exs
• Modify: lib/microwaveprop/propagation/grid.ex — add hrdps_only_points/0

Task 3.1: Define the Canadian-only grid (TDD)

hrdps_only_points/0 returns the subset of a 0.125°-spaced grid that is INSIDE the Canadian land mask AND OUTSIDE the existing CONUS HRRR footprint. Implement as a precomputed list (compile-time @external_resource) — the cells don't change.

Approximate bounds: 42°N to 60°N (north-of-60°N deferred to Stage 8), -141°W to -52°W. Filter to land using a coarse polygon — Natural Earth's ne_50m_admin_0_countries clipped to Canada is fine; even a rectangular bounding-box pass-through is acceptable for a first pass since over-water cells just get scored and ignored.

The mask must NEVER overlap HRRR cells. Test: MapSet.disjoint?(MapSet.new(Grid.conus_points()), MapSet.new(Grid.hrdps_only_points())).

Commit.

Task 3.2: Worker perform/1 (TDD)

Mirror PropagationGridWorker.process_forecast_hour/4. Args: {run_time, forecast_hour}. Calls HrdpsClient.fetch_grid(hrdps_only_points(), run_time, opts), derives profiles via the existing Microwaveprop.Weather.SoundingParams-style derivation, persists to hrdps_profiles, then scores via Microwaveprop.Propagation.Scorer.score/3.

start_async/Task.async_stream failure paths must Logger.error with point + reason (per CLAUDE.md and the swallowed-async-errors memory).

Commit.

Task 3.3: Score upserts into existing propagation_scores

Single shared scores table — HRDPS rows look identical to HRRR rows, distinguished only by (lat, lon) falling in the HRDPS-only mask. Use the same on_conflict: {:replace_all_except, [...]} upsert pattern.

Confirm via SQL: a sample run produces no (lat, lon, valid_time, band_mhz) collisions with HRRR rows.

Commit.

Task 3.4: Score-file .prop writer

The .prop file at /data/scores/... is what MicrowavepropWeb.ScoresController.cells/2 reads (and what ScoreCache mirrors in ETS). Either:

(a) extend the .prop writer to handle the larger union grid (CONUS + Canada), or (b) emit a separate _canada.prop file that the controller stitches at read time.

Decision: (a) — single file, simpler downstream. The Rust scorer (Stage 4) writes the same file; both must agree on the cell layout. Update Microwaveprop.Propagation.ScoresFile to support a wider grid extent. The cell-pack format already handles arbitrary lat/lon arrays per the PSCR magic spec.

TDD: write a fixture .prop file at the expanded extent, read it back, verify all cells round-trip. Commit.

---

Stage 4: prop-grid-rs Rust worker — HRDPS branch

The Rust worker at rust/prop_grid_rs/ claims tasks from grid_tasks via FOR UPDATE SKIP LOCKED and writes .prop files to /data/scores. It needs an HRDPS branch since it owns the hot path for f01..f18.

Files:

• Modify: rust/prop_grid_rs/src/sources/ (likely add hrdps.rs next to hrrr.rs)
• Modify: rust/prop_grid_rs/src/main.rs — task source dispatch
• Migration: priv/repo/migrations/{timestamp}_add_source_to_grid_tasks.exs

Task 4.1: Add source column to grid_tasks

source TEXT NOT NULL DEFAULT 'hrrr'. Backfill is a no-op since existing rows are all HRRR. Index on (source, run_time) for the worker's claim query.

Commit.

Task 4.2: Rust HRDPS fetcher

Mirror the existing hrrr.rs shape. Differences:

• URL builder using the date-prefixed pattern + per-variable filenames
• Concurrent fetch of ~14 variable files (use tokio::join_all with a semaphore at 4)
• Shell out to wgrib2 -merge (same binary the Elixir client uses; no Rust GRIB2 reimplementation)
• Reuse the existing point-extraction code that wraps wgrib2 -lon

Keep the Rust HRDPS code as close to the Rust HRRR code as possible — copy-then-modify is fine; resist refactoring for shared abstraction until both branches are working.

Commit.

Task 4.3: Task dispatch on source column

Worker's main loop branches on task.source: "hrrr" → existing path, "hrdps" → new path. The task seeder (Microwaveprop.Workers.GridTaskEnqueuer) populates source based on which worker enqueued the task.

Commit.

Task 4.4: Build + push image

Existing CI pipeline (.forgejo/workflows/build-grid-rs.yaml) produces the prop-grid-rs:main-* image consumed by both prop-grid-rs and hrrr-point-rs deployments. New code rolls out automatically once merged. Verify in Argo / pod logs.

---

Stage 5: hrrr-point-rs — HRDPS branch for per-QSO Canadian QSOs

Files:

• Modify: rust/prop_grid_rs/src/bin/hrrr_point_worker.rs
• Migration: priv/repo/migrations/{timestamp}_add_source_to_hrrr_fetch_tasks.exs
• Modify: lib/microwaveprop/workers/hrrr_fetch_enqueue_worker.ex (or wherever per-QSO fetches are enqueued)

Task 5.1: Routing decision

When a QSO's lat/lon falls outside the HRRR CONUS footprint, enqueue an HRDPS-source task instead of an HRRR task. Grid.point_source({lat, lon}) returns :hrrr | :hrdps | :neither (e.g. for a southern-hemisphere QSO). For :neither, fall back to the existing IEMRE/RAOB enrichment path.

TDD: cells at (45.0, -90.0) → :hrrr, (53.0, -113.0) → :hrdps, (-30.0, 150.0) → :neither.

Commit.

Task 5.2: hrrr_fetch_tasks.source column + Rust branch

Same shape as Stage 4.1/4.3: add source column, branch the Rust worker, reuse Stage 1's URL/variable patterns ported to Rust.

Commit.

Task 5.3: Per-QSO upserts into hrdps_profiles

QSO enrichment status column: add hrdps_status to contacts (similar to existing hrrr_status). LiveView/admin UI reads either, depending on which model covered the QSO.

Commit.

---

Stage 6: Cycle scheduling + border stitching

Files:

• Modify: config/runtime.exs — Oban cron + queue
• Modify: lib/microwaveprop/workers/grid_task_enqueuer.ex (or equivalent)

Task 6.1: Add hrdps queue

Production runtime config adds hrdps: 1 (single concurrent fetch — wgrib2 working set during merge can hit ~500 MB and we don't want it competing with propagation).

Task 6.2: Cycle cron at HH:35 of cycle hours

{"35 5,11,17,23 * * *", Microwaveprop.Workers.HrdpsCycleSeedWorker}

Why these times: HRDPS runs at 00/06/12/18Z and publishes ~3-4h later, so 5h after cycle (at 05:35Z, 11:35Z, 17:35Z, 23:35Z) the f00 file is reliably available. Offset by 30 minutes from HRRR's */15 schedule to avoid wgrib2 contention.

HrdpsCycleSeedWorker enqueues f00..f18 grid tasks with source: "hrdps". The existing chain worker (Rust + Elixir) drains them.

Task 6.3: Border stitching rule

Already enforced at Stage 3.1: HRDPS-only mask cells are disjoint from HRRR's CONUS points. No runtime conflict. The seam at 49°N is implicit: HRRR cells exist down to ~25°N, HRDPS cells exist 49°N+. The boundary is a one-cell band of HRRR coverage abutting HRDPS — no overlap, no double-write.

Document the rule in Grid.point_source/1's @moduledoc so future readers understand why the masks are exclusive.

Commit.

---

Stage 7: Map overlay extension

Files:

• Modify: lib/microwaveprop_web/live/map_live.ex — @initial_bounds
• Modify: assets/js/propagation_map_hook.ts — heatmap rendering bounds

Task 7.1: Widen @initial_bounds

CONUS-only (23.5, 49.5, -124.5, -66.9) → (23.5, 60.0, -141.0, -52.0) (excluding Arctic until Stage 8 decides). Default zoom adjusted so all of North America is visible.

Task 7.2: Smoke test (manual + LiveView test)

mix phx.server, open /map, confirm colored cells render north of 49°N after HrdpsCycleSeedWorker fires. The cell-pack endpoint at /scores/cells already serves whatever lat/lon points exist in the .prop file — no controller changes needed since Stage 3.4 expanded the file.

LiveView test: assert that an /scores/cells?band=10000&south=50&north=55&west=-115&east=-105 request returns >0 cells after HRDPS data exists in fixtures.

Task 7.3: ScoreCache chunk layout still correct

The ScoreCache layout (just shipped in commit 6a90d153 follow-up) uses 5°×5° chunks. Extending the grid into Canada adds ~30 new chunks but the same lookup logic applies. No code change; one regression test that fetches a Canadian-bounds viewport and asserts hit/miss telemetry works correctly.

Commit.

---

Stage 8: SRTM gap above 60°N — scope decision

Decision gate. SRTM1 stops at 60°N. Yellowknife (62.45°N), Whitehorse (60.72°N), Inuvik (68.36°N), and Resolute (74.70°N) have NO SRTM coverage — terrain diffraction analysis would silently return wrong losses for paths involving those stations.

Three options:

1. Cap Canadian coverage at 60°N for v1. Document explicitly in algo.md. Most VE QSOs are below 60°N anyway. Defer Arctic to a follow-up plan.
2. Use CDEM (Canadian Digital Elevation Model) above 60°N. ~1 week of additional work — different format (TIFF tiles), different mounting strategy on the production NFS share. Touches terrain_analysis.ex and elevation_client.ex.
3. Use ASTER GDEM v3. Global, free, 30 m resolution, but registration-walled. Not great.

Recommendation: Option 1 for v1. Ship the 42-60°N coverage. If users report Arctic gaps, do CDEM as a separate plan.

Decision recorded in this stage; file a follow-up issue if Option 2 is pursued.

---

Stage 9: Freshness monitoring + observability

Files:

• Modify: lib/microwaveprop/propagation/freshness_monitor.ex
• Modify: wherever /status exposes data freshness (LiveView or controller)

Task 9.1: Track HRDPS run-time staleness

Add hrdps_last_run_at to the monitor state. Surface on the status page next to HRRR's freshness.

Task 9.2: Alert at >5h stale

HRDPS publishes ~4h after each cycle, so a healthy pipeline never exceeds ~5h between runs. >5h = something broken (datamart outage, our worker failed silently, k8s scheduling glitch).

Logger.warning (not error — datamart outages are common and recoverable). Telemetry event for the existing dashboard scrape.

Commit.

---

Stage 10: Precommit, docs, ship

Task 10.1: mix precommit

Must show 0 failures, 0 credo issues, all dialyzer warnings resolved. Full project gate.

Task 10.2: Update CLAUDE.md

• Add HRDPS to Key Data Sources
• Add HrdpsCycleSeedWorker + HrdpsGridWorker + HrdpsFetchWorker to the Background Job Queues table
• Note the 60°N coverage cap and the cycle cadence (4×/day vs HRRR's hourly)

Task 10.3: Update memory/reference_hrdps_canada.md

Mark plan as executed. Capture any projection gotchas, the final cycle latency observed in prod, and the actual border-stitching seam location.

Task 10.4: Delete the probe wedge

lib/mix/tasks/hrdps_probe.ex is throwaway scaffolding — its risks were retired in Stage 0; the production code in HrdpsClient covers the same surface. Delete in this stage's commit, not earlier (keeping it around during stages 1-3 is useful for cross-checking the real client's output).

Task 10.5: Push to github AND origin

Per the push-both-remotes feedback memory. Do NOT push to dokku. Argo/Flux handles the rollout from the kustomize manifest pulled from git.mcintire.me.

---

Known risks + gotchas

• Projection — HRDPS rotated lat/lon is the single biggest bug source. Stage 1.6's CYYR validation against UWYO is the safety net; do not skip.
• Per-variable file fan-out — ~14 fetches per cycle/forecast hour × 4 cycles × 19 forecast hours = 1064 files/day. Each is small (~3.5 MB) but datamart's 200 OK latency is variable. Concurrency-cap at 4 to avoid hammering ECCC; build retry-with-backoff into HrdpsClient.
• Memory pressure — wgrib2 -merge working set during the multi-variable combine peaks at ~500 MB per cycle. The HRRR worker already runs at :system_memory_high_watermark headroom; running HRDPS on the same pod risks OOM. Either pin HRDPS to a dedicated prop-backfill-style pod (probably overkill) OR keep it on the hot pods but cap hrdps: 1 so it never overlaps with propagation: 1.
• Cycle publish latency — datamart can lag 90 min on good days, 4+h under load. The HrdpsCycleSeedWorker cron at HH:35 has a 1.5h margin which is comfortable but not infinite. If a cycle hasn't published by HH:35, the worker should fall back to seeding the previous cycle (still gives current+forecast scores, just one cycle stale).
• Border seam visibility — at the 49°N seam, HRRR's 0.125° cells abut HRDPS's 0.125° cells with no overlap. If the two models disagree by 5-10% on a given factor at the seam, users will see a faint horizontal stripe. Probably acceptable; document in algo.md.
• Scope creep — keep RDPS pressure-level coverage out of this plan even though they're related (RDPS plan is 2026-04-13-rdps-vertical-profiles.md). Ship CONUS+Canada-via-HRDPS first; revisit RDPS for wider/coarser coverage afterward.

Rough effort estimate

Stage	Estimate
0: Probe wedge	DONE (~3h, 2026-04-29)
1: HrdpsClient	4 days (Task 1.6 projection debug dominates)
2: hrdps_profiles schema	0.5 day
3: HrdpsGridWorker + .prop writer	3 days
4: Rust prop-grid-rs HRDPS branch	4 days
5: Rust hrrr-point-rs HRDPS branch	1.5 days
6: Cycle scheduling + border stitching	1 day
7: Map overlay extension	0.5 day
8: SRTM scope decision	0.5 day (decision + documentation, no code if Option 1)
9: Freshness monitoring	0.5 day
10: Precommit + docs + ship	0.5 day
Total	~16 days (3 weeks calendar)

The Rust worker stages (4 + 5) are the majority of the schedule risk. If schedule is tight, an alternative is to ship Elixir-only first (Stages 1-3 + 6-10) and follow up with the Rust port — at the cost of slower Canadian forecast-chain processing during the gap.

---

Open questions for confirmation before Stage 1

1. Variable set: Does the catalog at Task 1.2 cover everything the scorer needs for Canadian cells? Worth a 30-min look at Microwaveprop.Propagation.Scorer.factors/2 to confirm the surface + pressure-level set is complete (especially native-level duct analysis — HRDPS's hybrid sigma-pressure levels may be available under a *_HY_* or native/ directory that the probe didn't explore).
2. 60°N cap: Confirm Option 1 from Stage 8 (defer Arctic CDEM) before kickoff so we don't end up with the Stage 1.1 grid mask covering territory we won't actually serve.
3. Forecast horizon: Default plan uses HRDPS f00..f18 to match HRRR's window. HRDPS goes out to f48 — would f00..f24 or even f00..f48 (full Day-2 forecast, only on the Canadian side) be useful? Storage/compute roughly doubles per extra 12h of horizon.