Update SFS test to C192mx025; add debug and restart tests

[DeniseWorthen]

Commit Queue Requirements:

• Fill out all sections of this template.
• All sub component pull requests have been reviewed by their code managers.
• Run the full Intel+GNU RT suite (compared to current baselines) on either Hera/Derecho/Hercules
• Commit 'test_changes.list' from previous step

---

Description:

Replaces current C96mx100 SFS test with a configuration matching the current SFS C192mx025 prototype configuration. Adds a restart and debug test for SFS. The SFS input data is from CORe.

Warmstarts for ICE and OCN are from

/gpfs/f6/sfs-emc/scratch/Neil.Barton/ICs/CPC/C192mx025/sfs.19940430/18/mem000/model

The ATM ICs are from

/gpfs/f6/sfs-emc/scratch/Neil.Barton/ICs/CPC/C192mx025/sfs.19940501/00/mem000/model/atmos/input

The ATM and OCN increment files are from

/gpfs/f6/sfs-emc/scratch/Neil.Barton/ICs/CPC/C192mx025/sfs.19940501/00/mem001/analysis

The fix files are identical to those in

/gpfs/f6/drsa-precip3/world-shared/role.glopara/fix/orog/20240917/C192
/gpfs/f6/drsa-precip3/world-shared/role.glopara/fix/ugwd/20240624/C192

For example, the oro files (e.g. oro_data.tile1.nc) used by the RT are source from

FV3_fix_tiled/C192mx025/oro_C192.mx025.tile1.nc

and these are identical to those in role.glopara/fix/orog/20240917/C192/C192.mx025_oro_data.tile2.nc

However, the C192 grid files (eg C192_grid.tile4.nc) are not identical . In the RTs, these are source from

FV3_input_data192/INPUT/C192_grid.tile1.nc

and these files have small round-off level differences w/ the grid files in role.glopara/fix/orog/20240917/C192/. I don't believe this is an issue unless an attempt is made to repro a G-W run and an RT run.

Note that because the ATM is writing history files every 24 hours for the control test, the restart and debug tests compare only restart files from all components; the surface history files will not be B4B because the accumulated fields in the surface files will not be B4B.

Commit Message:

* UFSWM - Update configuration of SFS test to C192mx025 and add a restart and debug test
* UFSWM - Rename diag table template for SFS to diag_table_sfs.IN
* UFSWM - Add namelist parameter to control use of ECMWF non-stationary gravity wave scheme
  * FV3 - Add 'file_version' global attribute to sfc_data restart files, as defined in input sfc_data files
  * stochastic_physics - Restrict print messages to be on root PE only

Priority:

• Normal

Git Tracking

UFSWM:

• Fixes Create C192mx025 regression test configuration #2764
• Fixes diagnostic messages are written on all PEs and not controlled by flag to turn off NOAA-PSL/stochastic_physics#87
• Fixes Restart outputs are not b4b identical to cold-start run when sfc v2 files are used #2827
• Fixes Add namelist parameter to enable ECMWF non-stationary gravity wave scheme #2840

Sub component Pull Requests:

• FV3: Add 'file_version' global attribute to sfc_data restart files NOAA-EMC/fv3atm#997
• stochastic_physics: print messages on rootpe only NOAA-PSL/stochastic_physics#88

UFSWM Blocking Dependencies:

• None

Documentation:

• No documentation update is required for this PR (please explain). No non-documented features are added.

---

Changes

Regression Test Changes (Please commit test_changes.list):

• PR Updates/Changes Baselines.

Input data Changes:

• New input data.

This PR requires additions to the existing input-data to enable a C192mx025 case.

Library Changes/Upgrades:

• No Updates

---

Testing Log:

• RDHPCS
  • Hera
  • Orion
  • Hercules
  • GaeaC6
  • Derecho
  • Ursa
• WCOSS2
  • Dogwood/Cactus
  • Acorn
• CI
• opnReqTest (complete task if unnecessary)

[DeniseWorthen]

@XiaqiongZhou-NOAA I'm not sure you have access to infra-cpu project space, so I copied my latest RT test directories to

/gpfs/f6/infra-cpu/world-shared/Denise.Worthen/rt_2411934/

Please check the input.nml and other settings. Thanks!

[XiaqiongZhou-NOAA]

For input.nml, "do_ngw_ec=.true. " should be added in gfs_physics_nml. Others are as same as used in SFS

~fix/am/ozprdlos_2015_new_sbuvO3_tclm15_nuchem_shozhvlogp.f77 is a new ozone file should be copied to rundirectory as global_o3prdlos.f77 instead of the old one. I am not sure about stochastic parameters.

[DeniseWorthen]

@XiaqiongZhou-NOAA Thanks for checking.

Does the change adding do_ngw_ec=.true. need an associated Issue? I assume the value would be false by default and only the SFS test would turn it on.

I will update the ozone file in the inputdata I have staged for the tests.

[DeniseWorthen]

@XiaqiongZhou-NOAA I updated the ozone file and ran the debug test against the baseline I had created previously. It is still b4b. I checked that the global_o3prdlos.f77 in the run directory is identical to the file you pointed to from glopara. Is there any nml change associated w/ it? I know there is

  oz_phys      = .false.
  oz_phys_2015 = .true.

[XiaqiongZhou-NOAA]

@XiaqiongZhou-NOAA I updated the ozone file and ran the debug test against the baseline I had created previously. It is still b4b. I checked that the global_o3prdlos.f77 in the run directory is identical to the file you pointed to from glopara. Is there any nml change associated w/ it? I know there is

  oz_phys      = .false.
  oz_phys_2015 = .true.

I checked that the initial time is May1st in RT. The results should be identical. The results only are different in the cases from Aug-Nov.

[XiaqiongZhou-NOAA]

@XiaqiongZhou-NOAA Thanks for checking.

Does the change adding do_ngw_ec=.true. need an associated Issue? I assume the value would be false by default and only the SFS test would turn it on.

I will update the ozone file in the inputdata I have staged for the tests.

Yes, "do_ngw_ec" is false in the model and only SFS turn it on. It is related to this PR update ufs-community/ccpp-physics#273. I think this parameter is not added in the namelist as an option when the code is merged. I can create an issue if it is needed.

[DeniseWorthen]

Thanks, that explains it. I create the issue, now that I know where this parameter came from.

[DeniseWorthen]

@pjpegion Can you explain a bit about the OCN stochastic settings? From Neil's sandbox (19940501), I have in the input.nml the following

export ISEED_SPPT=19940501000103,19940501000104,19940501000105,19940501000106,19940501000107
export SPPT_LOGIT=.true.
export SPPT_SFCLIMIT=.true.
export ISEED_OCNSPPT=19940501000108,19940501000109,19940501000110,19940501000111,19940501000112
export ISEED_EPBL=19940501000113,19940501000114,19940501000115,19940501000116,19940501000117

These sort of look like they're related to the date, going sequentially from "03" to "17", but that also seems very odd.

How are the values for these variables determined?