MODE 11.1.0 Unevenly Spaced Lat/Lon Error

[tyreekfrazier1]

To preface this, I previously had been running MODE 9.1 with these same files except with 30H data with no issue last fall.

I am using observed precipitation data that was downloaded in grib2 format then converted to netCDF along with forecast files from the HREF that were also converted from grib2 to netCDF format as we've had issues with grib2 and MODE in the past. The error I am getting when trying to run MODE is as follows:

ERROR : get_data_from_lat_lon_vars() -> MET can only process Latitude/Longitude files where the longitudes are evenly spaced (dlon=0.0266666, delta[369]=0.0280006)

ERROR` :

ERROR :

ERROR : get_data_from_lat_lon_vars() -> Please check the input data is the lat/lon projection

ERROR :

I saw a previous post about a similar issue, but I wasn't clear on how it was resolved. It was issue #1940 in the MET GitHub.

[JohnHalleyGotway]

@tyreekfrazier1 sorry for the delay in following up on this discussion. I see that you're getting an error from MODE when reading data from a NetCDF file and are wondering why. You note that this behavior differs from what you saw in MET version 9.1.

I do recall us tightening up the logical checks when reading gridded data from NetCDF files since MET version 9.1 was released in August, 2020, but I can't find a specific commit to link to to show you exactly when it was introduced. I am confident that the change was intentional. MET version 9.1 may not have errored out but if you were using this same input data it was not using the correct grid information.

In general, MET supports a few different flavors of gridded NetCDF file:

• Those following the climate forecast convention.
• Those output from the WRF-interp utility.
• Those following MET's internal NetCDF file format.

The CF-convention provides a method for defining grid and projection information. For data on a lat/lon grid, the projection information can be derive from the arrays of latitude and longitude values. However this is NOT the case for other projections. You mentioned HREF data, which I think is on a 5km CONUS domain, presumably on a lambert conformal projection.

You probably passed a NetCDF file to MODE version 9.1 and it interpreted it as being on a lat/lon projection. If you look at the PostScript output generated by MODE, I suspect you'd see a discrepancy between the features of the data and map outline.

In newer versions, it's erroring out and telling you that it doesn't know how to extract grid information from that NetCDF file you have.

I'd recommend stepping back to revisit the decision to use NetCDF instead of GRIB2. I'd recommend switching back to the GRIB2 inputs. I don't know what problems they encountered in the past but generally I'd say that MET has better GRIB2 support than NetCDF support.

If you'd like me to take a closer look at your data, the GRIB or NetCDF versions of it, please feel free to post it to our anonymous FTP site following these instructions. If you do so, please write back here to let me know that I should go take a look.

[tyreekfrazier1]

Here is a link to a sample file from the same source that I have been using: https://nomads.ncep.noaa.gov/cgi-bin/filter_hrrr_2d.pl?dir=%2Fhrrr.20240516%2Fconus&file=hrrr.t12z.wrfsfcf24.grib2&var_APCP=on&lev_surface=on

I will have to get back to you about that compilation setting as I have to reach out to the person who is in charge of our systems.

[JohnHalleyGotway]

Thanks for sending the link. I pulled a file for yesterday:

wgrib2 hrrr.t12z.wrfsfcf24.grib2
1:0:d=2024051912:APCP:surface:0-1 day acc fcst:
2:994844:d=2024051912:APCP:surface:23-24 hour acc fcst:

And running both the 1-hour and 24-hour APCP through plot_data_plane worked just fine:

met-11.1.0/bin/plot_data_plane hrrr.t12z.wrfsfcf24.grib2 hrrr.t12z.wrfsfcf24.ps 'name="APCP"; level="A24";'
DEBUG 1: Start plot_data_plane by johnhg(6088) at 2024-05-20 16:25:51Z  cmd: /nrit/ral/met-11.1.0/bin/plot_data_plane hrrr.t12z.wrfsfcf24.grib2 hrrr.t12z.wrfsfcf24.ps name="APCP"; level="A24";
DEBUG 1: Opening data file: hrrr.t12z.wrfsfcf24.grib2
DEBUG 1: Creating postscript file: hrrr.t12z.wrfsfcf24.ps
DEBUG 1: Finish plot_data_plane by johnhg(6088) at 2024-05-20 16:25:53Z

I definitely think the memory issue is related to the compilation settings with respect to the -D__64BIT__ flag.

Thanks,
John

[tyreekfrazier1]

Thanks for checking those grib files. The person in charge of our systems said this:

I believe g2clib-1.6.0 was compiled with that flag
CFLAGS= -O3 -g -m64 $(INC) $(DEFS) -D__64BIT___

[JohnHalleyGotway]

OK, please see the following selection from the Installation of Required Libraries section of the user's guide:

For users wishing to compile MET with GRIB2 file support, NCEP’s GRIB2 Library in C (g2clib) must be installed, along with jasperlib, libpng, and zlib. Please note that compiling the GRIB2C library with the -D__64BIT__ option requires that MET also be configured with CFLAGS=”-D__64BIT__”. Compiling MET and the GRIB2C library inconsistently may result in a segmentation fault or an “out of memory” error when reading GRIB2 files.

We generally recommend that you just remove -D__64BIT__ from the compilation of the G2C library since it has caused issues when processing large GRIB2 files (e.g. >2GB in size), as noted in this compile_MET_all.sh installation script.

But if there's some reason you can't recompile g2clib, then just recompile MET with that option as well. You can set these environment variables, prior to rerunning configure and make install:

export CFLAGS="-D__64BIT__"
export CXXFLAGS="-D__64BIT__"

Hope that helps.

[tyreekfrazier1]

Ok, it looks like this solved the issue.

Thanks for the help.