Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

+(*)Better initialization of non-Boussinesq models #349

Merged
merged 5 commits into from
May 5, 2023

Conversation

Hallberg-NOAA
Copy link
Member

This PR includes a series of commits that improve the accuracy with which MOM6 is initialized in certain non-Boussinesq configurations and which extend the capabilities of the MOM_interface_heights module to include new routines to properly convert the vertical extent of layers (in height units) to thicknesses (even when in non-Boussinesq mode). These changes lead to a notable simplification of the code in some places where the calculations are working in, depth space, and to the elimination of the use of GV%H_to_Z or GV%Z_to_H, especially in a number of user modules. These changes greatly reduce the dependence of non-Boussinesq configurations on the value of the Boussinesq reference density, and they will lead to more accurate initialization of non-Boussinesq models. The changes in this PR include:

  • Eliminate the unused optional argument eta_to_m to the find_eta routines

  • Initialize the thicknesses in height units in 26 modules, and pass thicknesses in height units to temperature and salinity initialization routines in many of these same modules before systematically converting the thicknesses to thickness units after the temperatures and salinities are known and it can be done properly in non-Boussinesq models

  • Refactor MOM_initialize_state() to more clearly group initialization calls into well-defined phases

  • Add a new optional height_units argument to ALE_initThicknessToCoord()

  • Obsolete the runtime parameter CONVERT_THICKNESS_UNITS

  • Add code to handle initialization of thicknesses from a file that is already in mass units, as indicated when THICKNESS_CONFIG = "mass_file"

  • Eliminate unused thickness arguments to soliton_initialize_velocity() and determine_temperature()

  • Add the new overloaded interface dz_to_thickness() and the new public routine dz_to_thickness_simple() to the MOM_interface_heights module

  • Refactor trim_for_ice() to have a separate, simpler form appropriate for use in non-Boussinesq mode

  • Refactor initialize_sponges_file() to work in depth-space variables before using dz_to_thickness() to convert to thicknesses, but also to properly handle the case where the input file has a different number of vertical layers than the model is using, avoiding a possible segmentation fault

  • Reorder code in MOM_temp_salt_initialize_from_Z() to more clearly group it into distinct phases, and also use the new dz_to_thickness() routine to convert input depths into thicknesses

  • Use dz_to_thickness() to convert vertical distances to layer thicknesses in the sponge initialization routines in 4 user modules

There are a number of interface changes associated with these commits, and there are some changes to the MOM_parameter_doc files. However, by design all answers are bitwise identical in all known test cases, with some answer-changing simplifications in non-Boussinesq mode deferred to a subsequent PR.

The commits in this PR include:

  • 9ed06995b (*)Use dz_to_thickness in 4 user modules
  • e7337bf16 (*)Improve non-Boussinesq initialization
  • 6080ea615 +Add the new overloaded interface dz_to_thickness
  • a499f36c9 +Initialize thicknesses in height units
  • 975651ae7 +Remove optional argument eta_to_m from find_eta

@Hallberg-NOAA Hallberg-NOAA added the enhancement New feature or request label Apr 8, 2023
@Hallberg-NOAA Hallberg-NOAA requested a review from adcroft April 8, 2023 12:14
@Hallberg-NOAA Hallberg-NOAA added refactor Code cleanup with no changes in functionality or results Parameter change Input parameter changes (addition, removal, or description) labels Apr 8, 2023
@codecov
Copy link

codecov bot commented Apr 8, 2023

Codecov Report

Merging #349 (6ae0d1c) into dev/gfdl (9177d65) will decrease coverage by 0.01%.
The diff coverage is 18.05%.

❗ Current head 6ae0d1c differs from pull request most recent head 916fbfa. Consider uploading reports for the commit 916fbfa to get more accurate results

@@             Coverage Diff              @@
##           dev/gfdl     #349      +/-   ##
============================================
- Coverage     38.14%   38.13%   -0.01%     
============================================
  Files           269      269              
  Lines         75649    75731      +82     
  Branches      13915    13926      +11     
============================================
+ Hits          28855    28882      +27     
- Misses        41591    41650      +59     
+ Partials       5203     5199       -4     
Impacted Files Coverage Δ
src/ALE/MOM_ALE.F90 44.90% <0.00%> (-0.19%) ⬇️
...nitialization/MOM_tracer_initialization_from_Z.F90 0.00% <0.00%> (ø)
src/tracer/MOM_tracer_Z_init.F90 0.00% <0.00%> (ø)
src/user/DOME2d_initialization.F90 0.00% <0.00%> (ø)
src/user/DOME_initialization.F90 0.00% <0.00%> (ø)
src/user/ISOMIP_initialization.F90 0.00% <0.00%> (ø)
src/user/Neverworld_initialization.F90 0.00% <0.00%> (ø)
src/user/Phillips_initialization.F90 0.00% <0.00%> (ø)
src/user/Rossby_front_2d_initialization.F90 0.00% <0.00%> (ø)
src/user/SCM_CVMix_tests.F90 0.00% <0.00%> (ø)
... and 15 more

... and 1 file with indirect coverage changes

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

@Hallberg-NOAA Hallberg-NOAA force-pushed the dz_to_thickness branch 3 times, most recently from 5348774 to 93fe9ff Compare April 28, 2023 15:48
@Hallberg-NOAA Hallberg-NOAA requested a review from marshallward May 4, 2023 20:26
  Eliminate the unused optional argument eta_to_m from the two find_eta routines
for simplicity and code clarity.  These were used during the transition of the
units of the interface height variables, but they are now using [Z ~> m] units
everywhere, with the unscaling occurring via conversion factors in the
register_diag calls.  All answers are bitwise identical, but there is al
optional argument that is removed from a public interface.
  Pass arguments in height units rather than thickness units to most of the
routines that initialize thickness or temperatures and salinities.  These
routines are already undoing this scaling and working in height units, and it is
not possible to convert thicknesses to thickness units in non-Boussinesq mode
until the temperatures and salinities are also known.  The routines whose
argument units are altered include:

- initialize_thickness_uniform
- initialize_thickness_list
- DOME_initialize_thickness
- ISOMIP_initialize_thickness
- benchmark_initialize_thickness
- Neverworld_initialize_thickness
- circle_obcs_initialize_thickness
- lock_exchange_initialize_thickness
- external_gwave_initialize_thickness
- DOME2d_initialize_thickness
- adjustment_initialize_thickness
- sloshing_initialize_thickness
- seamount_initialize_thickness
- dumbbell_initialize_thickness
- soliton_initialize_thickness
- Phillips_initialize_thickness
- Rossby_front_initialize_thickness
- user_initialize_thickness
- DOME2d_initialize_temperature_salinity
- ISOMIP_initialize_temperature_salinity
- adjustment_initialize_temperature_salinity
- baroclinic_zone_init_temperature_salinity
- sloshing_initialize_temperature_salinity
- seamount_initialize_temperature_salinity
- dumbbell_initialize_temperature_salinity
- Rossby_front_initialize_temperature_salinity
- SCM_CVMix_tests_TS_init
- dense_water_initialize_TS
- adjustEtaToFitBathymetry

Similar changes were made internally to MOM_temp_salt_initialize_from_Z to defer
the transition to working in thickness units, although the appropriate call to
convert_thickness does still occur within MOM_temp_salt_initialize_from_Z and
the units of its arguments are not changed.

  The routine convert thickness was modified to work with a new input depth
space input thickness argument and return a thickness in thickness units, and it
is now being called after all of the routines to initialize thicknesses and
temperatures and salinities, except in the few cases where the thickness are
being specified directly in mass-based thickness units, as might happen when
they are read from an input file.

  The new option "mass_file" is now a recognized option for the THICKNESS_CONFIG
runtime parameter, and this information is passed in the new mass_file argument
to initialize_thickness_from_file.  The description of the runtime parameter
THICKNESS_IC_RESCALE was updated to reflect this change.

  The unused thickness (h) argument to soliton_initialize_velocity was
eliminated.

  The unused thickness (h) argument to determine_temperature was eliminated, as
was the unused optional h_massless argument to the same function.

  This commit also rearranges the calls to do adjustments to the thicknesses to
account for the presence of an ice shelf or to iteratively apply the ALE
remapping to occur before the velocities are initialized, so that there is a
clearer separation of the phases of the initialization.

  Also added optional height_units argument to ALE_initThicknessToCoord to
specify that the coordinate are to be returned in height_units.  If it is
omitted or false, the previous thickness units are returned, but when called
from MOM_initialize_state the new argument is being used.

  The runtime parameter CONVERT_THICKNESS_UNITS is no longer meaningful, so it
has been obsoleted.

  All answers are bitwise identical, but there are multiple changes to the
arguments to publicly visible subroutines or their units, and there are changes
to the contents of the MOM_parameter_doc files.
  Renamed convert_thickness from MOM_state_initialization to dz_to_thickness_tv
in MOM_density_integrals, so that it can be called from other lower-level
modules. This new version also takes the tv%p_surf field into account and it has
an optional halo_size argument, analogous to that in the other routines in the
MOM_density_integrals module.  The dz_to_thickness interface is overloaded so
that it can also be used directly with temperature, salinity, and the equation
of state type if the thermo_var_ptrs is not available.  There is also a new and
separate variant of this routine, dz_to_thickness_simple, that can be used in
pure layered mode when temperature and salinity are not state variables, or
(more dangerously) if it is not clear whether or not there is an equation of
state.  This simpler version is being kept separate from the main overloaded
interface because its use may need to be revisited later in some cases.  All
answers are bitwise identical, but there are two new public interfaces,
dz_to_thickness and dz_to_thickness_simple.
  This commit includes three distinct sets of changes inside of
MOM_state_initialization.F90 to better handle the initialization of
non-Boussinesq models, none of which change any answers in Boussinesq models.
These include:

 - Refactored trim_for_ice to have a separate, simpler form appropriate for use
   in non-Boussinesq mode.  The units of the min_thickness argument to
   cut_off_column top were also changed to thickness units.

 - Initialize_sponges_file was refactored to work in depth-space variables
   before using dz_to_thickness to convert to thicknesses, but also to properly
   handle the case where the input file has a different number of vertical
   layers than the model is using, in which case the previous version could have
   had a segmentation fault.

 - Code in MOM_temp_salt_initialize_from_Z was reordered to more clearly group
   it into distinct phases.  It also uses the new dz_to_thickness routine to
   convert input depths into thicknesses.

  All answers are bitwise identical in all Boussinesq test cases and all test
cases in the MOM6-examples regression suite, but answers could
be changed and improved in some non-Boussinesq cases.
  Use dz_to_thickness to convert vertical distances to layer thicknesses in the
sponge initialization routines in the DOME2d_initialization,
ISOMIP_initialization, dumbbell_initialization and dense_water_initialization
modules, and also in MOM_initialize_tracer_from_Z.  For the user modules,
the presence or absence of an equation of state is known and handled properly,
but MOM_initialize_tracer_from_Z works with the generic tracer code and it
it outside of the scope of MOM6 code to provide any information about the
equation of state or the state variables that would be needed to initialize
a non-Boussinesq model properly from a depth-space input file.  For now we
are doing the best we can, but this should be revisited.  All examples in
existing test cases are bitwise identical, but answers could change (and be
improved) in any non-Boussinesq variants of the relevant test cases.
@marshallward
Copy link
Member

Gaea regression: https://gitlab.gfdl.noaa.gov/ogrp/MOM6/-/pipelines/19022 ✔️ 🟡

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request Parameter change Input parameter changes (addition, removal, or description) refactor Code cleanup with no changes in functionality or results
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants