Can we remove wgrib2 from the dependencies? #591
Comments
|
UFS_UTILS definitely depends on the wgrib2 library. That hasn't changed recently. The alternative is to port UFS_UTILS to use g2 as its grib2 library. |
|
chgres_cube uses wgrib2. It could be modified to use the 'g2' library. I don't think that would be difficult. But it would take some work and testing. And it could be done is smaller chunks. |
|
@GeorgeGayno-NOAA for future work, can you communicate to the other chgres_cube programmers that wgrib2 should be avoided? |
Absolutely. Maybe I can add a warning to our wiki page? https://github.com/NOAA-EMC/UFS_UTILS/wiki |
|
If we can remove the dependency on wgrib2, we should. |
|
I added a warning page to the wiki: |
'define_input_grid_grib2' Fixes ufs-community#591.
|
@GeorgeGayno-NOAA Based on the warning page "Pull requests that use WGRIB2 will be rejected.", do it also apply to the GEFS WCOSS2 Transition? Because GEFS uses chgres_cube. |
Add diagnostic print to compare lat/lon computed by gdswzd to those from wgrib2. Use gdswzd computed lat/lon for use by rest of program. Fixes ufs-community#591.
Are you adding new code to chgres_cube that uses wgrib2? |
|
No. I didn't change code except changing "grb2_UNDEFINED" to "9.999e20" to use wgrib2/2.0.7. My changes are XianwuXue-NOAA/UFS_UTILS@1b44601...a825b29 |
to determine the number of soil layers. Fixes ufs-community#591.
wgrib2 to g2. Fixes ufs-community#591
data to use g2 lib. Fixes ufs-community#591
soil moisture. Fixes ufs-community#591.
max and min veg greenness. Fixes ufs-community#591.
to facilitate testing. Fixes ufs-community#591.
|
Count number of soil layers using g2 instead of wgrib2 - d327b7a. All consistency tests passed on Dell. |
|
Some further analysis of #591 (comment) and #591 (comment) My branch at 474401f and 'develop' at 26cd024 were modified to output the grid cell center and corner lat/lons in netcdf format. The files were placed on Hera in The The files are in these sub-directories:
More analysis will follow. |
|
Here are the differences between my branch and 'develop' for the 13km RAP grid. The mean differences are very small - much smaller than the resolution of the grid. Viewing the files in Since we know the |
|
Here are the differences between the branch 474401f and 'develop' for the 13km NAM grid (lambert conformal) The grid cell centers are very close. The differences are much smaller than the resolution of the grid. The grid cell corners are off - especially the longitudes. The branch computes the centers using wgrib2 and the corners using routine A similar result is seen with the 3km HRRR grid. The corner longitude difference is similar to the resolution of the grid: |
of the RAP grid coordinate file. Part of ufs-community#591.
…ines. Update routines "read_input_atm_grib2_file", "read_input_sfc_grib2_file", "read_winds" and "read_grib_soil" to read input GRIB2 files using G2LIB instead of WGRIB2. Update routine "define_input_grid_gfs_grib2" to flip the pole of GFS GRIB2 data. WGRIB2 and G2LIB use different conventions for defining global gaussian grids. Update to G2LIB v3.4.3 or higher, which eliminated occasional segmentation faults and slow wall clock times. Add new units test for GRIB2 read routines "read_input_atm_grib2_file" and "read_input_sfc_grib2_file". Part of #591.
|
The second - and hopefully - final PR was created for this issue - #641. This PR replaces the wgrib2 computation of input grid latitude/longitude with a computation from IPLIB routine gdswzd. So, our first check should compare the differences between the two computation methods. Both the branch and a local copy of develop were modified to dump the lat/lons to a netcdf file. |
|
Check lat/lon differences between develop at 31271f7 and the branch at 9f66174. Test 1 - Check the lat/lon differences for 13km RAP data. This data is on a rotated lat/lon 'B' grid (grid definition template number - 32769). The wgrib2 library can't compute the lat/lons for this grid, so they are read into chgres_cube from a file - latlon_grid3.32769.nc. The differences between the file and gdswzd computations are: The mean are very small compared to the grid resolution of 13 km. Some large differences in longitude are near the dateline, where the sign of longitude switches. |
|
Test 2 - Check the lat/lon differences for the 3km HRRR data. This data is on a lambert conformal grid: The differences between the wgrib2 and gdswzd computations are: The mean differences at the center of the grid cell are very small compared to the grid resolution of 3 km. And the corner point latitude differences are small. However, the mean corner point longitude differences are comparable to the grid resolution. Something is not correct. |
|
Test 3 - Check the lat/lon differences for 12km NAM data. This data is on a lambert conformal grid: The differences between the wgrib2 and gdswzd computations are: The mean differences at the center of the grid cell are very small compared to the grid resolution of 12 km. And the corner point latitude differences are small. However, as with the 3 km HRRR data, the mean corner point longitude differences are comparable to the grid resolution. Something is not correct. |
Attaching some plots of corner point longitude minus center point longitude. The wgrib2 plot shows this difference is of the wrong sign (It is positive everywhere. For this N Amer. grid, it should be negative). The gdswzd plots show the expected magnitude (about 0.015 deg or 1.5 km) and sign.
|
Some plots. As in the previous comment (#591 (comment)), note how the gdswzd computation make more sense:
|
|
All files containing the input gridpoint latitude/longitudes and their differences (from the above tests) are on Hera here: /scratch1/NCEPDEV/da/George.Gayno/ufs_utils.git/chgres_cube_nowgrib2/PR641/latlon_check Under each sub-directory, there are these netcdf files:
|
|
Graphics from all failed consistency tests are on Hera here: /scratch1/NCEPDEV/da/George.Gayno/ufs_utils.git/chgres_cube_nowgrib2/PR641 Under each test sub-directory, the graphics are here:
For this latest PR (#641) all differences are due solely to the difference between how the branch and develop compute the input grid latitude/longitudes. |
file containing grid point lat/lons. Fixes ufs-community#591.
* Begin update of model_grid.F90 to use g2 library. Fixes #591 * Start new routine to set the esmf grid object for grib2 data. Fixes #591. * Begin updates to add non-latlon grids. Fixes #591 * Call gdswzd twice. Once for the grid point centers and once for the corner points. Fixes #591. * Output lat/lons to a netcdf file. * Adjust longitude convention of rotated lat/lon grids in output netcdf file. * Remove unused routines from model_grid.F90 Part of #591. * Some cleanup to model_grid.F90 * Remove unused variable used to store the path and name of the RAP grid coordinate file. Part of #591. * Remove all dependencies on wgrib2 from the build. Fixes #591. * Remove wgrib2 from workflow 'yml' files. Fixes #591. * Fix pole flip bug in gdt_to_gds for GFS GRIB2 data. Fixes #591. * Add diagnostic print of lat/lon corner/center differences. Fixes #591. * Remove some unused variables and the write of the diagnostic file containing grid point lat/lons. Fixes #591.
Somehow wgrib2 crept into our dependencies.
We are trying to eliminate use of wgrib2 in NCEPLIBS. The wgrib2 library is not well-maintained, distributed, or tested, and there is no interest on the wgrib2 team in meeting our needs in these areas. So we need to not build more tools on top of wgrib2.
The text was updated successfully, but these errors were encountered: