How to Properly Handle NETCDF Files

[Victorrani]

Hello everyone! I am learning to use the MODE tool and running some tests with NETCDF precipitation files. I can get MODE to work perfectly when I use .nc files with accumulated data, but something tells me this might not be the correct way to use it.
Is there a way to use the complete dataset instead of just the accumulated data?

In this example, the init_time should be 20240214_000000, while the valid_time should be 20240219_000000 (but it is not showing any errors this way). The model integration is 3 hours, with a forecast range of 5 days.

Thanks agan!

[JohnHalleyGotway]

@Victorrani I see you have a question about configuring the MODE tool in MET. I see some details to clarify in the configure file you sent.

First, specifying file_type = NETCDF_NCCF; really does work. It tells MET to process the input file as being a CF-complaint NetCDF file. I'll note though that CF-compliant NetCDF files typically include a global attribute for Conventions = "CF-X.Y";. You only need to explicitly specify the file_type if that global Conventions attribute is missing.

Second, MET reads data from the input NetCDF files and extracts metadata from it, including the initialization, valid, and lead times. Specifying the init_time, valid_time, and lead_time in the config file has no effect for NetCDF input files. Those time settings are used when reading data from GRIB files that contain multiple timesteps. They are not used by MET's NetCDF library code.

Third, the set_attr_name, set_attr_units, and set_attr_accum config options work fine here. And they'll impact the variable name/units/accumulation interval written to the MET output files.

Please try running MODE using the -v 4 level of verbosity. That'll print this type of log output to tell you the timing information and range of values for the gridded data being read:

DEBUG 4: Data plane information:
DEBUG 4:    plane min: 0
DEBUG 4:    plane max: 38.884
DEBUG 4:    valid time: 20050807_120000
DEBUG 4:    lead time: 120000
DEBUG 4:    init time: 20050807_000000
DEBUG 4:    accum time: 120000

That's a good way of double-checking that MET is extracting metadata from that NetCDF file as it should. If there is some issue with the time values, you can always use the set_attr_init, set_attr_valid, and set_attr_lead config options to OVERRIDE the metadata that's being read from the file. And those changes to the timestamps will be reflected in the log messages and output files.

When reading gridded data from NetCDF files, the level string defines what gridded 2D data slice should be extracted. You put * characters in the 2 slots that define the dimensions of the grid. For example, for a NetCDF variable name data(time,lat,lon) you'd set level = "(0,*,*)"; to extract the first (0-based) time slice of data from the file. Instead of using integers to index into the other dimensions, you can also specify the value of the corresponding coordinate variable to be used. So level= "(@20240214_000000,*,*)"; would give you the slice of data for 20240214_000000, assuming there's a time(time) coordinate variable that includes that time.

Similarly, for data(time,pressure,lat,lon), level=(@20240214_000000,@500,*,*) would give get data for that time step and the 500mb pressure level, assuming there's a pressure(pressure) coordinate variable that includes the value of 500.

Hope that helps clarify.

[Victorrani]

Thank you, @JohnHalleyGotway !

The -v 4 option helped provide more details about what I'm seeing. I really appreciate it!

However, I still haven't been able to resolve the issue. I believe it might be related to the NETCDF data convention I'm using. I'll investigate this further.

Victor Ranieri