graham/prop
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Add meteorologist feedback on model choice to RRFS doc

Browse source
This commit is contained in:
Graham McIntire 2026-03-31 09:27:23 -05:00
parent 0ed10e695c
commit d97de91978
No known key found for this signature in database
GPG key ID: F4ABF488E6029E59
1 changed files with 21 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

21
docs/RRFS.md
View file

@ -78,6 +78,27 @@ When RRFS full output becomes available, key advantages would be:
- Potentially improved boundary layer and moisture forecasts from the FV3 dynamic core
- Longer forecast horizon for propagation prediction
## Meteorologist Feedback (March 2026)
From a meteorologist familiar with Gulf region propagation:
**Model choice validation:**
- HRRR is confirmed as the best short-term (0-48h) choice for low-level inversions and water vapor content. Higher vertical resolution in the boundary layer and tighter grid spacing give it the best handle on moisture — critical since humidity is our highest-weighted scoring factor (20%).
- **NAM should be avoided** — substantially over-estimates low-level water content, especially in the western Gulf region. Over-does fog and water vapor discontinuities. Would produce false-positive ducting predictions in exactly the areas where ducting matters most.
- **GFS is better for days 2-5** forecasts, with a more pessimistic (and more correct) stance on moisture. Worth considering if we add a multi-day propagation forecast view.
**RRFS transition notes:**
- HRRR will be operationally replaced by RRFS in the next few years
- The meteorologist expects RRFS files may use netCDF format (current experimental output on S3 is GRIB2 — the full operational output format may differ)
- The transition should be "fairly straightforward" — the scoring algorithm itself won't change, only the data ingestion layer
- RRFS is already available experimentally but (as documented above) the public output lacks the fields we need
**Implications for our architecture:**
- Keep HRRR as primary source — validated by domain expert
- Don't use NAM for anything moisture-related
- The `Propagation.Scorer` module is data-source-agnostic by design — when RRFS becomes available, only the fetch/extraction layer needs to change
- If we add forecast beyond 48h, consider GFS as a supplementary source for days 2-5
## References
- AWS S3: `s3://noaa-rrfs-pds/`
- NOAA RRFS: https://gsl.noaa.gov/focus-areas/unified_forecast_system/rrfs