search

ufs-community / UFS_UTILS

Utilities for the NCEP models.
Other
21 stars 104 forks source link

chgres_cube: Tracers for non-gfs GRIB2 data are not read properly in FV3 because of "source" string in atmospheric output #179

Closed LarissaReames-NOAA closed 1 year ago

LarissaReames-NOAA commented 3 years ago

FV3 model code is currently set to only read a few tracers if the "source" string is anything but "FV3GFS GAUSSIAN NEMSIO FILE." So, even if the tracers in the chgres_cube output file are populated with data from the input file (e.g., HRRR grib2), the model does not read them in. We have used this "source" setting before, but it got written over when a change was made to develop. This isn't an ideal solution, clearly, but it's the only option currently to have the tracers read properly. Model developers are aware of this issue.

JeffBeck-NOAA commented 3 years ago

Related to issue #97 in ufs-weather-model

LarissaReames-NOAA commented 3 years ago

@GeorgeGayno-NOAA @JeffBeck-NOAA We've now implemented this fix in release/public-v2 (https://github.com/NOAA-EMC/UFS_UTILS/pull/184). However, I'm now curious how regression tests (https://github.com/NOAA-EMC/UFS_UTILS/issues/181) will work since the metadata of the files will deviate between develop and release/public-v2. Should we wait to merge regression tests in to develop until this has been fixed on the model end and no longer requires a chgres_cube fix?

Given only Jeff and I are truly familiar with how some of the grib2 processing works thus opening up those portions of the code to failure based on other modifications, I'd personally prefer one of the two options: two sets of baseline data, or removal of the nccmp metadata check.

JeffBeck-NOAA commented 3 years ago

@GeorgeGayno-NOAA @LarissaReames-NOAA, I would prefer removing the metadata checks for now, until this issue is resolved, and concentrate on confirming the data themselves don't change. It's not appealing, but it would hopefully be limited in time, and would reduce work required to produce two sets of regression tests, and allow us to get those new regression tests merged into develop soon.

GeorgeGayno-NOAA commented 3 years ago

@GeorgeGayno-NOAA @LarissaReames-NOAA, I would prefer removing the metadata checks for now, until this issue is resolved, and concentrate on confirming the data themselves don't change. It's not appealing, but it would hopefully be limited in time, and would reduce work required to produce two sets of regression tests, and allow us to get those new regression tests merged into develop soon.

The tests use the 'nccmp' utility to compare the files. There is probably an option to have it ignore the meta data. You will retain the regression tests under the release branch, correct? You can turn off the check in the branch.

edwardhartnett commented 3 years ago

No we should not turn off the metadata checks. Clearly we should have separate baseline data for develop branch.

JeffBeck-NOAA commented 1 year ago

@LarissaReames-NOAA, @GeorgeGayno-NOAA, to my knowledge, the "source" string still determines what tracers are used and how other pre-processing (e.g., mass adjustment) is conducted for FV3 initialization. However, while it'd be preferable to use a different method than input file type to determine these conditions, I also believe things have been modified appropriately to work when initializing from netCDF and grib2 files. Therefore, are we OK with closing this issue?