-
Notifications
You must be signed in to change notification settings - Fork 65
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
+(*)Better initialization of non-Boussinesq models #349
Conversation
Codecov Report
@@ 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
... and 1 file with indirect coverage changes 📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
5348774
to
93fe9ff
Compare
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.
1aed266
to
916fbfa
Compare
Gaea regression: https://gitlab.gfdl.noaa.gov/ogrp/MOM6/-/pipelines/19022 ✔️ 🟡 |
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 phasesAdd 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()
anddetermine_temperature()
Add the new overloaded interface
dz_to_thickness()
and the new public routinedz_to_thickness_simple()
to the MOM_interface_heights moduleRefactor
trim_for_ice()
to have a separate, simpler form appropriate for use in non-Boussinesq modeRefactor
initialize_sponges_file()
to work in depth-space variables before usingdz_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 faultReorder code in
MOM_temp_salt_initialize_from_Z()
to more clearly group it into distinct phases, and also use the newdz_to_thickness()
routine to convert input depths into thicknessesUse
dz_to_thickness()
to convert vertical distances to layer thicknesses in the sponge initialization routines in 4 user modulesThere 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: