specify OBS_VAR1_LEVELS in metplus gridstat

[perthsb]

Hi,
I am trying to validate model forecast against another model forecast which is in netcdf but all forecast files are stacked inside that file. So in GridStat configure file how to explicitly specify OBS_VAR1_LEVELS so that model forecast validates against correct forecast hour of the other model. Or is it done some other way ? Attached is conf file.
Any help is appreciated. Thanks
grid_stat_Test.conf.txt

[JohnHalleyGotway]

@perthsb I see you have a question about configuring Grid-Stat to select a single timestep from a NetCDF file that contains many.

I see this in the METplus config file you sent:

OBS_VAR1_NAME = total_aod_mean
OBS_VAR1_LEVELS =  (0,*,*)

And I'm guessing here that the "total_aod_mean" NetCDF variable has 3 dimensions for time, lat, lon (or something simliar).

float total_aod_mean(time, lat, lon)

Settings the level to (0,*,*) will always use data for the first time step. Instead, you want to select data for the actual valid time being evaluated. You can try doing so like this:

OBS_VAR1_LEVELS = ({valid?fmt=%Y%m%d_%H%M%S},*,*)

The would tell Grid-Stat to find and use the time dimension corresponding exactly to the current valid time being evaluated.

[perthsb]

Thanks John. I tried the way you suggested, but it did not work as expected. It seems to be while running metplus, obs file valid time YYYYMMDD_HHMMSS not changing with forecast file, so when forecast file reads 24hr forecast, obs is still at 12hr. I have attached both output and log file and conf file as attachment. Any help is appreciated.

grid_stat_icap_Taod.conf.txt
metplus.log.20220517023819.txt
test.txt

[JohnHalleyGotway]

@perthsb, we talked briefly about this discussion topic during a METplus development meeting today. And we suspect the issue is related to how you've defined the time looping options and file name templates.

First, let me clarify that there are 3 important variables related to time in METplus... the forecast initialization time (init), the forecast lead time (lead), and the valid time (valid). From any 2 of these, you can define the 3rd because init + lead = valid.

You've defined your METplus configuration to loop over valid times:

LOOP_BY = VALID
VALID_BEG = 2022051100
VALID_END = 2022051600
VALID_INCREMENT = 6H

And for each valid time you loop over, you're evaluating multiple lead times:

LEAD_SEQ = begin_end_incr(0,120,6)

And all of that is fine. However, we suspect there's a problem in how you've defined the forecast and obs filename templates:

FCST_GRID_STAT_INPUT_TEMPLATE = gefs.{valid?fmt=%Y%m%d}/00/chem/pgrb2ap25/gefs.chem.t00z.a2d_0p25.f{lead?fmt=%3H}.grib2
OBS_GRID_STAT_INPUT_TEMPLATE = icap_{valid?fmt=%Y%m%d}00_MME_modeaod550.nc

We suspect your use of "{valid}" in these templates should be replace by "{init}". Usually the model INITIALIZATION time is included in the forecast file names rather that the valid time.

Please double-check that, adjust as needed, and re-test.

[perthsb]

Thanks John. I tried by changing both input templates from valid to init, but that still giving errors. So, I changed the "loop by" from valid to init time and it worked without error. I am wondering how to make it to work for "valid" time loop.

grid_stat_icap_Taod2.conf.txt
test2.txt

[JohnHalleyGotway]

I'm glad to hear you were able to set a successful run when you loop by init time. I see that that's the config/log file you sent, the successful run with init time.

You said that when you change back to LOOP_BY = VALID, you get error messages.

Can you please send me a log file with the error messages you describe?

[perthsb]

Hi John,
Thanks. I have attached conf and output error messages for valid time loop here. I chose a very narrow valid time range (between 16th and 17th of May) ,but as you see in logfile, MET actually looks for 120 hr forecast on 9th or 10th May, which should fall outside valid time range. I am not sure why it is happening here.
grid_stat_icap_Taod.conf.txt
test.txt

[georgemccabe]

Hi @perthsb, @JohnHalleyGotway is out of the office today and asked me to take a look at this discussion.

I think you may be misunderstanding how the METplus timing variables work with respect to forecast leads. Please see the Timing Control section from the System Configuration chapter of the METplus User's Guide, specifically the LEAD_SEQ sub-section for a detailed description with examples.

The METplus [VALID/INIT]_[BEG/END] variables are not actually a range of valid or init times to allow. The wrappers loop over the valid/init times from _BEG to _END by _INCREMENT. For each valid/init time, the list of forecast leads specified with LEAD_SEQ are processed. For each forecast lead, the other time is computed, i.e. for LOOP_BY = VALID, each LEAD_SEQ value is subtracted from the valid time to compute the init time, and for LOOP_BY = INIT, each LEAD_SEQ value is added to the init time to compute the valid time.

The MET config files for some tools support valid_beg, valid_end, init_beg, and init_end variables that do specify a range of valid/init times to allow and times outside of those ranges are not processed, so I see how this would be confusing. Those values are set through the METplus config with variables that also include the name of the tool, i.e. PB2NC_VALID_BEG.

In the configuration file you sent, VALID_BEG = 2022051200, so the first value time processed is 0Z on May 12. Forecast leads from 0-120 by 6 specified with LEAD_SEQ, so GridStat will run for the following times:

• valid 0Z on May 12, init 00Z on May 12
• valid 0Z on May 12, init 18Z on May 11
• valid 0Z on May 12, init 12Z on May 11
• valid 0Z on May 12, init 06Z on May 11
• valid 0Z on May 12, init 00Z on May 11
  ...
• valid 0Z on May 12, init 00Z on May 7

The VALID_INCREMENT value is set to 6 hours, so it will then increment to 6Z on May 12 and process every forecast lead, computing the init time relative to that valid time, and so on.

I hope that clears up the confusion. Let me know if you have any other questions or issues. There is a lot of useful information in the METplus User's Guide System Configuration chapter so I recommend reading through it.

[perthsb]

Thanks @georgemccabe . It helped me to clear the confusion.
However, I would like to discuss one further issue related to read a particular obs data that needs to be read in and I am trying to figure out what is the best way to use that data in OBS template. I have uploaded conf file and output (where the data list is provided) here. From the data list, you can see the HHMM of the obs and if any help on how to use that in configure template.
Thanks.
grid_stat_GEOS5_Taod2.conf.txt
test6.txt

[georgemccabe]

Hi @perthsb, it looks like the obs template you set correctly matches the timestamps in the GEOS files, however there are no files that correspond to the valid times that you are processing. It is difficult to tell how this should be configured without knowing what data is found in each file. It looks like the timestamps in the filenames are off by 90 minutes from the times you are trying to process. If, for example, the data in the 0730 file contains data valid from 0600-0730, then you could configure the obs template using the shift keyword to shift the time from the current run time.

OBS_GRID_STAT_INPUT_TEMPLATE = GEOS.fp.asm.tavg3_2d_aer_Nx.{valid?fmt=%Y%m%d_%H%M?shift=90M}.V01.nc4

See this section of the METplus User's Guide for more information on time shifting in filename templates.

If you'd like to send me one of the GEOS files, I could take a look at the contents to help you determine how to set this up.

[perthsb]

Thanks @georgemccabe . I am not sure if big file can be send over here. If you have WCOSS Venus access you can find the file :
/gpfs/dell2/emc/verification/noscrub/Partha.Bhattacharjee/Aerosol/GSD_Chem/GEOS5/Analysis/Test
or you can wget https://portal.nccs.nasa.gov/datashare/gmao/geos-fp/das/Y2022/M05/D11/GEOS.fp.asm.tavg3_2d_aer_Nx.20220511_0130.V01.nc4

Let me know if you can access them

[georgemccabe]

Thanks @perthsb, I was able to download that file. It looks like the file contains a single time that lines up with the time in the filename. The global attributes mention that the data covers a range of 00:00 to 03:00, so I think you would want to use this file for the 0Z run. If that is the case, then I think applying a 90 minute shift to the filename template is appropriate here. However, the valid time in the time dimension will not line up with the valid time for your run, so you do not want to specify the valid time in the OBS_VAR1_LEVELS value. Since there is only 1 time in these files, I would change:
OBS_VAR1_LEVELS = ({valid?fmt=%Y%m%d_%H%M},*,*)

to

OBS_VAR1_LEVELS = (0,*,*)

[perthsb]

Thanks @georgemccabe . I made the changes and able to run without any issue. I have put runtime output and conf as well
grid_stat_GEOS5_Taod.conf.txt
test2.txt

[georgemccabe]

Hi @perthsb, I'm glad you were able to run without any issue.

I'd like to mark this discussion as being answered and "lock it" to prevent future posts. That's how we encourage users to create new discussions for new questions. But I wanted to give you an opportunity to comment on it before doing so. Please feel free to select one of the responses as being the best answer to your original question. That'll help future users with similar questions find answers.