Formatting netCDF files correctly for MET to correctly get forecast hour lead information

[malloryprow]

Hello,

As a part of the Global Deterministic Atmospheric verification we are verifying daily averaged Geopotential Height Anomalies. After some discussions about what stats we are looking for it is just some continuous statistics like Bias and RMSE.

Geopotential Height Anomalies are not an output in the GFS grib2 files so I have to calculate these myself. Here is the process I am doing:

1. Run GridStat to produce netCDF output. This output has the forecast values, observation values, and climatology values on the verifying lat-lon grid.
2. I wrote a python script to read the netCDF output from step 1. It will create the forecast and observation anomalies for each forecast hour, and then go through and create the daily average files. The daily average forecast and observation anomalies get written out to the same files. An example file name is init2022013100_valid2022013106to2022020100; this would be a day 1 daily average file name. For the metadata in the files, I'm copying it from the files in step 1 (changing the file name). An ncdump on the file outputs the forecast anomaly metadata has init_time = "20220131_000000" and valid_time = "20220201_000000". The observation anomaly metadata has init_time = "20220201_000000" and valid_time = "20220201_000000".

When I go to run GridStat to output the CNT line type on this file, the STAT file out has the suffix "000000L_20220201_000000V.stat" when I would have expected "240000L_20220201_000000V.stat". If needed I can hand over the example I am talking about!

[CPKalb]

Hi Mallory:

Are you using MET version netcdf files or CF-compliant? Could I see a sample of one of them?

Thanks,
Christina

[malloryprow]

I tested on a MET version netcdf file and got the same result.
GridStatNetCDF.tar.zip
e

[JohnHalleyGotway]

@malloryprow and @CPKalb, yes, Grid-Stat does name its output files based on the timing information of the forecast data:

On this line of grid_stat.cc, the first forecast data plane object read is passed as an argument to setup_first_pass(). And this line of setup_first_pass() sends the valid and lead time of that forecast data to setup_txt_files(), which uses it to create the output file names. So all of that logic is working the way we expect.

What is NOT working the way we expect is MET's parsing the timing information from that forecast field. This can be demonstrated by running plot_data_plane at verbosity level 4:

plot_data_plane grid_stat_fcstgfs_obsgfs_anl_climoERAI_GeoHeightAnom_240000L_20220201_000000V_pairs.nc fcst.ps 'name="FCST_HGT_P500_FULL"; level="(*,*)";' -v 4

And the log messages contain:

DEBUG 4:      valid time: 20220201_000000
DEBUG 4:       lead time: 000000
DEBUG 4:       init time: 20220201_000000

But that doesn't match the timestamps in the file:

		FCST_HGT_P500_FULL:init_time = "20220131_000000" ;
		FCST_HGT_P500_FULL:init_time_ut = "1643587200" ;
		FCST_HGT_P500_FULL:valid_time = "20220201_000000" ;
		FCST_HGT_P500_FULL:valid_time_ut = "1643673600" ;

So I'd say there's a bug in the library code's parsing of these times.
I also ran another NetCDF matched pairs file through plot_data_plane with -v 4 and see the same problem.

I'll write up a bugfix issue and we'll get this fixed in MET-10.1.0.

In the meantime, you could use the set_attr_init and set_attr_lead options as a temporary workaround until this bug is fixed:

> plot_data_plane \
grid_stat_fcstgfs_obsgfs_anl_climoERAI_GeoHeightAnom_240000L_20220201_000000V_pairs.nc \
fcst.ps \
'name="FCST_HGT_P500_FULL"; level="(*,*)"; set_attr_init="20220131_000000"; set_attr_lead="24";' \
-v 4
DEBUG 4:      valid time: 20220201_000000
DEBUG 4:       lead time: 240000
DEBUG 4:       init time: 20220131_000000

[malloryprow]

@JohnHalleyGotway Ah, sort of glad it was a bug. I thought I was missing something obvious, haha! This makes my ego feel better. Thank you for the work around in the meantime!

[JohnHalleyGotway]

Thanks for letting us know about this! I'm surprised this bug has persisted so long. FYI, I just wrote up issue dtcenter/MET#2040 to fix it.

[JohnHalleyGotway]

@malloryprow, just closing the loop on this one. @jprestop and I committed a fix for this issue in Pull Request dtcenter/MET#2048. This will be included and available for your testing in met-10.1.0-beta6.

I'll go ahead and mark this issue as being answered.