malloryprow
commented
3 years ago @KateFriedman-NOAA I just had an idea for this that would potentially fix things for the metp tasks with leaving gfs_cyc alone. If we set up the setup_workflow.py and setup_workflow_fcstonly.py to add INTERVAL_GFS to the environment variables for the "gfsmetp*" tasks, I can use that to adjust the verification date. I understand though wanting to address the bigger picture with gfs_cyc and user manually adjusting the XML to set INTERVAL_GFS. I know you said you plate is pretty full for the rest of the month, but just wanted to get this idea written down.
JianKuang-Intelsat
WalterKolczynski-NOAA
aerorahul
Issue came up when a user manually change the GFS interval in their XML from to <!ENTITY INTERVAL "24:00:00"> to <!ENTITY INTERVAL "120:00:00">. However the user left their config.metp unchanged and left VRFYBACK_HRS to its default of 24 hours, meaning the verification would run for the cycle date - 24 hours. This caused problems in the gfsmetp tasks as the GFS cycles would not have been ran for these dates. When the user update VRFYBACK_HRS to 120 the verification ran as expected.
The goal with this issue would be to rework how gfs_cyc gets set and used, and creating a variable that script that connect EMC_verif-global and the global workflow can key off of to get the right verification dates so users don't have to make the changes in config.metp.
From Kate: "It could become an hour value rather than a toggle value. It would default to "24" (similar to the current gfs_cyc=1). Then users could provide a different value at setup time (or between setup steps by changing config.base) and could set it to a value divided by the assimilation frequency (6hrs)."
We will need to consider how this could impact and affect other places where gfs_cyc is used.