@dpsarmie I also hit a problem with DT_ATMOS. For gfsv17 tests for example:

1. export_fv3 sets a default DT_ATMOS
2. export_cpl sets a different default DT_ATMOS that is used in export_{cice,cmeps,...} for DT_CICE, coupling_interval_fast_sec,..
3. Then export_ugwpv1 sets a different DT_ATMOS based on ATMRES
4. But cice, cmeps,... never see changes from step 3

Maybe export_cpl should not touch DT_ATMOS either.

It may also be better in these tests to call export_fv3, then export_ugwpv1, then export_cpl so atmosphere is configured properly before setting other components

Thanks @NickSzapiro-NOAA for bringing that up. I'll have to do some more testing to see what makes sense. I think the simplest solution would be to make the atm only and cpld default DT_ATMOS the same, but I want to make sure that the runtime isn't greatly affected for the atm only cases.
If not, then there needs to be a straightforward way to differentiate between the possible combinations and what needs to be defined.
Although I agree that the ugwpv1 call should come before the cpld call to resolve your issue 4.

I think it is better if DT_ATMOS is thought of as input to export_cpl (and not modified in export_cpl). The issue I'm focusing on is (coupling) timesteps for gfsv17 test, where ufs.configure is the same before and after 2363:

# CMEPS warm run sequence
runSeq::
@3600
   MED med_phases_prep_wav_avg
   MED med_phases_prep_ocn_avg
   MED -> WAV :remapMethod=redist
   MED -> OCN :remapMethod=redist
   WAV
   OCN
   @720
     MED med_phases_prep_atm
     MED med_phases_prep_ice
     MED -> ATM :remapMethod=redist
     MED -> ICE :remapMethod=redist
     ATM
     ICE
     ATM -> MED :remapMethod=redist
     MED med_phases_post_atm
     ICE -> MED :remapMethod=redist
     MED med_phases_post_ice
     MED med_phases_ocnalb_run
     MED med_phases_prep_ocn_accum
     MED med_phases_prep_wav_accum
   @
   OCN -> MED :remapMethod=redist
   WAV -> MED :remapMethod=redist
   MED med_phases_post_ocn
   MED med_phases_post_wav
   MED med_phases_restart_write
@
::

But, dt_atmos in model_configure is 360s in current develop vs 720s before 2363. Was it intended for 2363 to reduce timestep for this test? Either way, now FV3<-->CMEPS no longer couple every ATM timestep, ATM timestep is different than ICE timestep,... I'm not sure this is intentional and may need hot fix if not intended.

Ok I see what you mean.

#2363 was intended to change the timesteps to have the more optimized set of parameter values to allow for more stability at longer timesteps: NOAA-EMC/global-workflow#2574

I'm going to move forward with your idea of having DT_ATMOS set in export_fv3 and changed in export_ugwpv1 (if needed) before calling export_cpl.

That should allow DT_CICE and coupling_interval_fast_sec to be set correctly when the other export calls are run from within export_cpl.

Line 1302 will also be removed in default_vars.sh since DT_INNER will have been set by then.

Let me know if that logic makes sense. That should resolve the issues of not having the timing in sync between the models, correct?

That makes sense to me. Maybe can ask Denise to review solution too

Latest changes do the following:

To fix the timing issue it CMEPS, default_vars.sh has been reworked. If you export DT_ATMOS and/or ATMRES before the export_fv3 (and other export functions), then all dependent variables will be auto-populated. If these variables are not set, then defaults will be set. You can still manually set these parameters after the function calls but you need to make sure that all variables that depend on DT_ATMOS and ATMRES are also set unless you intended to do so otherwise.

Either way, the timing with CMEPS should be functioning as intended.

@dpsarmie In the PR description, can you add how the logic/flow in default_vars works and should be used?

@NickSzapiro-NOAA I added a snippet to the description on how it should be used. I'm actually currently working on a more detailed document for how to use the new features, so let me know if anything is unclear or if anything else should be added to the description for the PR.

@dpsarmie I'm getting confused about where the B4B differences are arising. It seems you're combining what is a bug-fix (the issue w/ dt_atmos), with updates of various namelist settings to match GW. Both of these tasks create non-B4B changes, is that right? Should we really be combining a bug fix w/ what is actually a new feature (consistency w/ G-W)?

@DeniseWorthen Yes, the changes to the namelist and the associated changes to default_vars (just adding variables) were changes that were still B4B comparable.
There was a discussion a few weeks ago with EPIC to roll these other bug fixes into the PR since they are touching related files.

I've opened individual issues for documentation purposes since it is getting a bit complex. I'll add something to the description to try and detail the changes and which issue was addressed by which change in the code. There won't be anything else added to this PR.

@dpsarmie Thanks for adding the information. Did either

Variable values that were hard-coded in global_control.nml.IN were replaced with an @ tag and the values were moved to default_vars.sh.
Another issue will also be merged into this PR. The cpld_control_sfs configuration will be changed to bring it in-line with the GW configuration. cpld_control_sfs settings were changed in the test configuration file.

change baselines?

I'm confused because the next change is described with This will add additional baseline changes. (emphasis added).

If either of the first two items changed baselines, then I believe it is poor CM practice to combine issues which both change a set of tests. Rolling them together makes it much harder to un-roll/debug in the future, if required.

@DeniseWorthen Yes, the cpld_control_sfs test underwent two baseline changes. The GW settings change (second item under Description) and the DT_ATMOS fix (third item) had two distinct changes in that baseline.

I can untangle those easily and create an independent PR so there's only one baseline change per PR.