Replies: 1 comment
|
@csteele2 thanks for bringing up this issue. I've been looking into ungrib recently, and I believe ungrib is having trouble with the full RRFS domain GRIB2 files because of the file size. I was able to get ungrib to run on full North America RRFS domain files by splitting the GRIB2 file into smaller chunks. For those specific surface / soil fields, I can try to look into what might be going on. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Upon seeing the announcement of RRFSv1 implementation in "early 2026", I looked into testing impacts of workflow. I noticed several with the retirement of NAM/HRW. I also noticed that parallel data is not available on nomads, but did find the s3 bucket seemed to go through a reorg recently, and I much prefer the faster/more efficient transfers from AWS without getting a ban hammer from nomads, so I started poking.
These files seem agreeable with cfgrib, so visualization of them isn't a problem, but they do not seem to agree with other grib utilities - especially ungrib (for use to drive WRF/MPAS). I seemed to get ungrib to accept them by reprojecting to regular lat/lon, but using the raphrrr Vtable in the wps repo doesn't work too well with the pressure-level files, and for nat levels, I find ungrib doesn't decode much of the surface and soil fields (ungrib log shows "-" for RH, PSFC, PSML, SOIL*, LANDSEA, etc.), which is another big problem. With some scouring I found a Vtable.RRFS, but it looks pretty close to raphrrr and doesn't really change the results..
My concern is that RAP/HRRR is unsupported with NCAR repo of MPAS, so I would be left with nothing to drive regional high-res simulations if the NCAR WPS repo does not work with RRFS files and/or RRFS inherits the same soil issue for MPAS (since it looks like it has the same LSM).
All reactions