Enable On-the-Fly Generation of WW3 Binary Files

[ezhilsabareesh8]

Description: The WW3 model's workflow is intricate, involving the generation of binary files through the ww3_grid grid preprocessor. Currently, these binary files are created using predefined namelist parameters in ww3_grid.nml and namelists_Global.nml, alongside specific grid files (OM2_1.Lon, OM2_1.Lat, OM2_1.Dpt, OM2_1.Mask, and OM2_1.Obstr).

To improve user experience and workflow flexibility, we propose implementing a solution where the binary files (specifically mod_def.ww3) are dynamically generated during runtime. This approach would enable users to modify most input namelist parameters without needing to rebuild ww3_grid, thus providing greater control and understanding of the binary file's provenance.

Proposed Solution:

1. Integrate generation of binary files (mod_def.ww3, restart.ww3) within Payu.
2. Allow users to modify input namelist parameters without requiring a rebuild of ww3_grid or ww3_strt (for generating restart), except for major changes that necessitate modifying switches.

PS: The challenge arises when users need to modify critical parameters such as propagation schemes, source schemes, attenuation and scattering models. While most changes can be accommodated within the namelists, certain adjustments necessitate modifying switches and rebuilding ww3_grid other wise modifications in the namelists will be ignored by WW3.

[aekiss]

Should we also look at the approach NorESM are taking to generate mod_def.ww3 at runtime, as mentioned by @mvertens last week?

[aekiss]

certain adjustments necessitate modifying switches and rebuilding ww3_grid other wise modifications in the namelists will be ignored by WW3.

Is there an option to make WW3 abort if it receives an unrecognised namelist parameter, as we do in MOM6?

[ezhilsabareesh8]

Is there an option to make WW3 abort if it receives an unrecognised namelist parameter, as we do in MOM6?

WW3 will only recognize parameters associated with switches it's compiled with. If a parameter in namelists_Global.nml isn't associated with a compiled switch, WW3 won't look for it and will skip processing. For instance, if we're using the ST6 source term, the code checks for it using preprocessor directives like this:

#ifdef W3_ST6
      CALL W3SIN6 ( SPEC, CG1, WN2, U10ABS, USTAR, USTDIR, CD, DAIR, &
           TAUWX, TAUWY, TAUWAX, TAUWAY, VSIN, VDIN )
#endif

If a user defines ST4 input parameters instead of ST6, WW3 will automatically abort. However, if a user adds additional parameters without compiling WW3 with the relevant switches, WW3 will simply ignore those parameters.

[ezhilsabareesh8]

After the meeting with Aidan, we have finalized a plan for generating the input file for WW3 on the fly. Here are the conclusions we arrived at:

• [x] Always generate mod_def.ww3.

• [ ] Use a CMakefile to generate restart.ww3, based on the following conditions:

  • If ww3_strt.inp is modified.
  • If ww3_strt is modified.
  • If OM2_1.Dpt, OM2_1.Lat, OM2_1.Lon, OM2_1.Mask, OM2_1.Obstr, ww3_grid.nml are modified.

• [ ] Rebuild if a new parameter is added to namelist_Global.nml with the & symbol.

I have made modifications to the Payu codebase, enabling us to generate mod_def.ww3 on the go. This process takes just a few seconds for the 1-degree configuration and is nearly the same for quarter-degree as well.

However, after generating the binary file, Payu is failing while writing manifests/restart.yaml. The mod_def.ww3 is generated successfully. The error trace suggests an issue in the Payu codebase related to manifest writing. I will investigate further to determine if any additional code changes are required in Payu, aside from cesm_cmeps.py.