0.25deg MOM6 parameters

[aekiss]

The current 0.25 deg MOM6 parameters have mostly been inherited from the 1 deg config. They will need some more changes for 0.25 deg, particularly in the sub-gridscale parameterisations.

Compare these differences in ACCESS-OM2 with our om3 config differences.

The 1 deg parameters also need updating, with these changes inherited at 0.25 deg as appropriate - see https://github.com/COSIMA/access-om3/issues/83 and https://forum.access-hive.org.au/t/namelist-configuration-discussion-meeting/1917/9

[minghangli-uni]

What is the recommended approach for documenting the 025deg MOM parameters? Can I directly push my configuration as a new branch to https://github.com/COSIMA/MOM6-CICE6?

Will this cause confusion when others review the repo?

Additionally, how should I name the new branch to distinguish it from the existing025deg_jra55do_ryf?

[aekiss]

Hi @minghangli-uni, you should push to a new, uniquely-named branch as described in https://github.com/COSIMA/access-om3/wiki/Git-practices

[anton-seaice]

I think try to make one commit for each parameter and give it a really good commit message about why the choice was made for the change, (unless two parameter are intrinsically related). Ideally the model should run at every commit.

[aekiss]

We now have two examples of the MOM6 parameters currently being used by GFDL for OM5 at 0.25°: https://github.com/COSIMA/access-om3-doc/tree/main/configs/GFDL-OM5

Differences between these are tabulated here: https://github.com/COSIMA/access-om3-doc/blob/main/tables/MOM_input/GFDL-OM5_nml_diff.md

And differences between GFDL OM4 and OM5 parameters are here https://github.com/COSIMA/access-om3-doc/blob/main/tables/MOM_input/GFDL-OM4-OM5_nml_diff.md

[aekiss]

To properly compare OM5 with our configs we'll need to start adding MOM_parameter_doc_* to our config repos, ideally automatically updating them (see https://github.com/COSIMA/access-om3/issues/117) but until then we could make do with adding and updating them manually.

[minghangli-uni]

We now have two examples of the MOM6 parameters currently being used by GFDL for OM5 at 0.25°: https://github.com/COSIMA/access-om3-doc/tree/main/configs/GFDL-OM5

Just had a quick look at. It seems like they may have encountered bad values for their most recent parameters as well.

CHECK_BAD_SURFACE_VALS = True   !   [Boolean] default = False
                                ! If true, check the surface state for ridiculous values.
BAD_VAL_SSH_MAX = 50.0          !   [m] default = 20.0
                                ! The value of SSH above which a bad value message is triggered, if
                                ! CHECK_BAD_SURFACE_VALS is true.
BAD_VAL_SSS_MAX = 75.0          !   [PPT] default = 45.0
                                ! The value of SSS above which a bad value message is triggered, if
                                ! CHECK_BAD_SURFACE_VALS is true.
BAD_VAL_SST_MAX = 55.0          !   [deg C] default = 45.0
                                ! The value of SST above which a bad value message is triggered, if
                                ! CHECK_BAD_SURFACE_VALS is true.
BAD_VAL_SST_MIN = -3.0          !   [deg C] default = -2.1
                                ! The value of SST below which a bad value message is triggered, if
                                ! CHECK_BAD_SURFACE_VALS is true.
BAD_VAL_COLUMN_THICKNESS = 0.0  !   [m] default = 0.0
                                ! The value of column thickness below which a bad value message is triggered, if
                                ! CHECK_BAD_SURFACE_VALS is true.

Also, SINGLE_STEPPING_CALL=True, which was discussed here https://github.com/COSIMA/access-om3/issues/140

SINGLE_STEPPING_CALL = True     !   [Boolean] default = True
                                ! If true, advance the state of MOM with a single step including both dynamics
                                ! and thermodynamics.  If false, the two phases are advanced with separate
                                ! calls.

[minghangli-uni]

A PR, COSIMA/MOM6-CICE6#72, has been created for changes to the 0.25deg MOM6 parameters.

MOM6 is the most time-consuming component of OM3, with the current 0.25 deg MOM6 parameters taking approximately 3-4 times longer than OM2. This increased runtime may be due to the parameters inherited from the 1 deg config, which includes more parameterisations that significantly impact the 0.25-degree configuration. Therefore, it is necessary to modify the MOM6 parameters based on our OM3 config differences and configuration discussion, along with relevant explanations.

For comparison, all the following modifications reference a specific run configuration: 1344 ocean cores (concurrent), 96 ice cores, and 48 atmosphere and runoff cores (sequential), with the existing diagnostic outputs, a timestep of 1350 seconds and a run duration of 10 days (640 timesteps).

[minghangli-uni]

Total runtime $\approx$ Ocean Initialization + Ocean (Ocean dynamics + Ocean thermodynamics and tracers + Ocean Other) Ocean $\approx$ Ocean dynamics + Ocean thermodynamics and tracers + Ocean Other	Changes	Ocean Initialization (s)	Ocean (s)	Ocean dynamics (s)	Ocean thermodynamics and tracers	Ocean Other
\	32.476571	464.129335	155.140331	145.424753	131.055208
SAVE_INITIAL_CONDS = False	8.418149	465.359439	155.773003	146.523099	131.312126

Disable this parameter to prevent writing the initial conditions to the file specified by IC_OUTPUT_FILE.

The runtime for Ocean Initialization can potentially be further reduced by setting WRITE_GEOM=0 for a new simulation. Although the default value is 1, changing it will not affect initialisation for a restart run.

[minghangli-uni]

Changes	Ocean Initialization (s)	Ocean (s)	Ocean dynamics (s)	Ocean thermodynamics and tracers	Ocean Other
\	32.476571	464.129335	155.140331	145.424753	131.055208
SAVE_INITIAL_CONDS = False	8.418149	465.359439	155.773003	146.523099	131.312126
+ remove MEKE (Mesoscale Eddy Kinetic Energy)	8.000587	363.504680	143.213778	71.676143	116.979715

In the 0.25deg configuration (intermediate scale) of OM4 from GFDL, mesoscale eddy features unresolved by the grid were not parameterised. This decision was based on comparison runs that showed the 0.25deg configuration provided better simulations without mesoscale eddy parameterisation. However, in OM5, mesoscale eddy parameters (MEKE) were reintroduced for all three parameter choices, including the configuration (b00_MOM_parameter_doc.all) which was noted to be similar to OM4-025 in most aspects. This has caused some confusion regarding whether mesoscale eddy mixing parameterisation was ultimately included. I suggest that the inclusion of this parameter should be tested for our configuration at a later stage.

b00 is similar to OM4-025 but includes a number of bug fixes and algorithm changes. It is physically consistent with OM4-025 in most regards.

For 0.25deg OM2, mesoscale eddies were parameterised with an established GM and Redi parameterisations with simpler scaling methods.

[minghangli-uni]

Changes	Ocean Initialization (s)	Ocean (s)	Ocean dynamics (s)	Ocean thermodynamics and tracers	Ocean Other
\	32.476571	464.129335	155.140331	145.424753	131.055208
SAVE_INITIAL_CONDS = False	8.418149	465.359439	155.773003	146.523099	131.312126
+ remove MEKE (Mesoscale Eddy Kinetic Energy)	8.000587	363.504680	143.213778	71.676143	116.979715
+ diags-only static output	8.276058	306.608117	130.128613	65.965966	78.136760

I/O optimisation is not part of the current MOM6 parameter tuning process. Therefore, only static grid diagnostics are included in the diag_table.