Add flexibility for ocean/ice output time-steps

[JessicaMeixner-NOAA]

Description
Currently it's hard-coded in the diag_table that ocean output is 6 hourly: https://github.com/NOAA-EMC/global-workflow/blob/develop/parm/parm_fv3diag/diag_table#L3

However, @jiandewang found that there are currently constraints in that the ocean/ice (which must be consistent because of the currently combined grib output), must also be the same as the forecast model due to these lines in the scripts:
ush/forecast_postdet.sh:

   fhrlst=$OUTPUT_FH

    for fhr in $fhrlst; do
      if [ $fhr = 'anl' ]; then  # Looking at OUTPUT_FH, this is never true. TODO: remove this block
        continue
      fi
      VDATE=$($NDATE $fhr $IDATE)
      YYYY=$(echo $VDATE | cut -c1-4)
      MM=$(echo $VDATE | cut -c5-6)
      DD=$(echo $VDATE | cut -c7-8)
      HH=$(echo $VDATE | cut -c9-10)
      SS=$((10#$HH*3600))

Requirements
Ideally we can run without hard-coding the 6-> (atm time step) and have the ocean/ice model have different time steps.

Acceptance Criteria (Definition of Done)
Be able to run with 3 hourly atm time-steps and 6 hourly ocean or 3 hourly atm and ocn/ice and not have to change anything other than a config file.

[aerorahul]

@JessicaMeixner-NOAA
The lines referred to in the description are pointing to an aerosol section. Can you please update the issue? Thanks!

[jiandewang]

see https://github.com/NOAA-EMC/global-workflow/blob/develop/ush/forecast_postdet.sh#L773-L787
here Vdate relies on Idate, but Idate is defined on fv3 side

[aerorahul]

actually, IDATE=CDATE on

global-workflow/ush/forecast_postdet.sh

Line 758 in ae56219

export IDATE=${CDATE}

.
CDATE is defined at the top as the current cycle and does not change.

[aerorahul]

@jiandewang
I don't understand the issue here.
The output frequency is controlled via the diag_table. It is currently set to 6 hourly. In addition, it seems like these are 6 hour averages, not instantaneous.
For this reason, the model outputs the data in a file with the datetime that is the midpoint.

This file with midpoint date is then linked to COM with a valid datetime and midpoint datetime. I don't see why that is necessary and we will simplify this section in coming PRs.

If the issue is to have a different averaging time for ocean, I think we can update the diag_table and ensure that it is consistent with the script through a configuration variable. Note however, this will not be accomplished in time for v17.

[JessicaMeixner-NOAA]

The frequency of the ocean output in GFSv17 is currently undecided, my understanding of the issue was found when we were trying to use 3 hourly atm output and 6 hourly ocean output, however, since
https://github.com/NOAA-EMC/global-workflow/blob/develop/ush/forecast_postdet.sh#L760: fhrlst=${OUTPUT_FH}
we get a list of forecast hours based on a variable set by the atm forecast hour, not the ocean forecast output time which as you mentioned is set/hard-coded to 6 hourly in the diag_table.

[jiandewang]

also see https://github.com/NOAA-EMC/global-workflow/blob/develop/ush/forecast_postdet.sh#L771-L772

[aerorahul]

@JessicaMeixner-NOAA
These are structural changes and we would like to know what we are working with as soon as possible. There is a lot of hard-wired information that was put in place for prototype experiments. We won't be doing that for the GFS. Please plan accordingly.

[JessicaMeixner-NOAA]

From @NeilBarton-NOAA -- we control the ice output frequency by the FHOUT variable here:
https://github.com/NOAA-EMC/global-workflow/blob/develop/ush/parsing_namelists_CICE.sh#L84-L85 :

 histfreq       = 'm','d','h','x','x'
   histfreq_n     =  0 , 0 , ${FHOUT} , 1 , 1

Note that the first lines "h" for hour corresponds to the "FHOUT" variable.

[JessicaMeixner-NOAA]

@aerorahul I wanted to check in on this issue. @jiandewang ran some scout runs with what is now the develop branch with the unstructured grid in prep for HR3. We like to have 3 hourly output for atm model and that meant we manually made updates to run with 6 hours in the diag table with the updates in #2286 our previous work around no longer works. There's likely another simple work around that we can use to move forward, but before investigating that I thought I'd talk to you first about the longer term fix.

[JessicaMeixner-NOAA]

So it looks like we could hard code FHOUT to 6 here: https://github.com/NOAA-EMC/global-workflow/blob/develop/ush/forecast_predet.sh#L250 but then the post jobs are still thinking it's 3 hours if we change FHOUT. So I'm looking for where that's set to see if that could also be temporarily hard coded to 6 for us to run HR3. -- I looked for your branches @aerorahul that you had pointed me to before but they no longer exist.

[JessicaMeixner-NOAA]

I did not say that PR @2327 closed this issue because of GEFS, but in hindsight with @WalterKolczynski-NOAA updates I think we might be able to close this issue. @aerorahul thoughts?

[aerorahul]

@JessicaMeixner-NOAA
I am fine with closing this issue if the solution in #2327 meets the requirements.
We can re-open or open another one if further enhancements are required.

[JessicaMeixner-NOAA]

We meet the acceptance criteria. Closing!

[EricSinsky-NOAA]

This issue has come up for GEFS in PR #2561. In the GEFS reforecast, FHOUT_OCNICE_GFS needs to be 24 and FHOUT_GFS needs to be 6 (the goal is to set this to 3 for first 240 lead hours). After some modifications to gefs_tasks.py and tasks.py, this issue has mostly been resolved for GEFS.