METplus jobs fail for gfs_cyc=2 or 4

[DavidHuber-NOAA]

What is wrong?

When running the C96_atm3DVar_extended test, the gfsmetpg2g1 and gfsmetpg2o1 jobs fail to locate all data. For this test, gfs_cyc=4 and the metp jobs only run on the 00z cycle, so it should be looking for GRIB2 data from the 00Z cycle and the previous 3 cycles. Instead, it is looking for the 00Z cycle and the next 3 cycles. These data are not available until later cycles, so the .stat files are not generated for cycles 06-18.

What should have happened?

The METplus scripts should look backwards instead of forwards and skip over cycles that should not exist.

What machines are impacted?

All or N/A

Steps to reproduce

Run a GFS cycle in either forecast-only or cycled mode with gfs_cyc=4.

Additional information

Found while testing #2749 and #2732.
Sample log file can be found here: /lfs/h2/emc/nems/noscrub/david.huber/GFS_CI_ROOT/PR/2749/RUNTESTS/COMROOT/C96_atm3DVar_extended_5a7dd316/logs/2021122100/gfsmetpg2g1.log

Do you have a proposed solution?

No response

[DavidHuber-NOAA]

FYI @malloryprow.

[DavidHuber-NOAA]

@malloryprow Is the intent to run the METplus jobs once all of the data for a given date is available? e.g. run the gfsmetpg2g1 job on cycle 2024010100 when cycles 2024010100 through 2024010118 are otherwise complete?

If that is the case, then I can just modify the rocoto XML dependencies.

[malloryprow]

Oh yeah, it shouldn't be looking for data for the next 3 cycles.

global-workflow/parm/config/gfs/config.metp

Line 36 in 8486596

export VRFYBACK_HRS="0"

Temporary fix to get your tests working would be to adjust VRFYBACK_HRS to 24.

[DavidHuber-NOAA]

Thanks, @malloryprow. I have a work-in-progress solution in EMC_verif-global. I'll open a draft PR.