Align MALI/MPAS-Ocean constants with E3SM shared values and unify glacier-ice density defaults

[Copilot]

mpas_li_constants.F had hard-coded values that diverged from E3SM shared constants, creating cross-component inconsistency risk for thermodynamic and time-conversion constants. This PR aligns those constants and extends the fix to unify glacier-ice density behavior between MALI and MPAS-Ocean in coupled E3SM runs.

• Shared-constant propagation (MPAS_ESM_SHR_CONST)

  • MALI aligns key constants with shr_const_mod where appropriate, including:
    • iceConductivity => SHR_CONST_CONDICE
    • kelvin_to_celsius => SHR_CONST_TKFRZ
    • seconds_per_day => SHR_CONST_CDAY
    • idealGasConstant aligned via SHR_CONST_RGAS

• Fallback value alignment (#else)

  • Updated local fallback values to match shared E3SM definitions:
    • cp_ice: 2009.0 → 2.11727e3
    • latent_heat_ice: 335.0e3 → 3.337e5
    • cp_seawater: 3.974e3 → 3.996e3
  • Kept scyr outside the conditional block and defined it from seconds_per_day.
  • Reworked fallback formulas so standalone values remain consistent with shared-constant derivations.

• Glacier-ice density consistency across MALI and MPAS-Ocean

  • Removed unused rho_ice from MPAS-Ocean constants and uses a glacier-ice default variable for land-ice flux logic.
  • Added negative-sentinel handling:
    • MALI uses module default glacier-ice density when config_ice_density < 0
    • MPAS-Ocean uses module default glacier-ice density when config_land_ice_flux_rho_ice < 0
  • Updated E3SM namelist defaults to trigger shared defaults:
    • config_ice_density = -1.0 (MALI)
    • config_land_ice_flux_rho_ice = -1 (MPAS-Ocean)
  • Updated corresponding namelist metadata/registry valid-value text to document negative sentinel behavior.

• PCD file handling correction

  • share/util/pcd_const.F90 is treated as auto-generated from share/pcd.yaml and is no longer manually authored.

• Code-level example

  #ifdef MPAS_ESM_SHR_CONST
     use shr_const_mod, only: &
            cp_ice => SHR_CONST_CPICE, &
            latent_heat_ice => SHR_CONST_LATICE, &
            cp_seawater => SHR_CONST_CPSW, &
            iceConductivity => SHR_CONST_CONDICE, &
            kelvin_to_celsius => SHR_CONST_TKFRZ, &
            seconds_per_day => SHR_CONST_CDAY
  #endif

This keeps standalone configurability while ensuring coupled E3SM defaults are aligned and consistent across components.

[trhille]

Leaving this as a draft but tagging @matthewhoffman, @xylar, @stephenprice, @mperego for discussion.
I don't anticipate the discrepancies that co-pilot found in these commits to make major changes to MALI simulations. However, a potentially larger issue is that MALI uses ice and seawater density values set in the namelist, and our defaults are different from the E3SM values (910 km/m3 vs 917 for ice; 1028 km/m3 vs 1026 reference value for seawater). While those differences are not huge, I imagine they could shift the grounding line in some areas and result in slightly different behavior. One option would be to set our defaults to the values used by E3SM, and then users could set different defaults if needed for MALI standalone simulations.

[trhille]

@mperego Are any of these constants going to be inconsistent with values used by Albany?

[mperego]

@trhille We don't use the enthalpy-related constants for coupled (MPAS-Albany) forward runs. For initialization we would need to match them. I don't think we have "defaults" for those constants in Albany.. but most of our input yaml files will have to be changed.

If you change ice and water densities I think we would definitely have to redo the initialization of the Greenland grids.

[trhille]

For initialization we would need to match them. I don't think we have "defaults" for those constants in Albany.. but most of our input yaml files will have to be changed.

@mperego where can I find a list of the Albany parameter names that we'd need to change for the yaml files?

[mperego]

@mperego where can I find a list of the Albany parameter names that we'd need to change for the yaml files?

You can find it here:
https://github.com/sandialabs/Albany/blob/master/tests/landIce/FO_Thermo/input_FO_Thermo_Humboldt_depthInt_fluxDiv.yaml#L70-L80

However, the ones that matter for MALI forward simulations are ice density, water density, gravity acceleration and Clausius Clapeyoron coefficient (iceMeltingPointPressureDependence?), which are imported from MPAS, if not specified in the yaml input file:
https://github.com/MALI-Dev/E3SM/blob/develop/components/mpas-albany-landice/src/mode_forward/mpas_li_velocity_external.F#L64

[matthewhoffman]

@trhille , thanks for tackling this needed but fussy set of changes. I've made some comments about additional constants that could be aligned with shr_const_mod. I think ideally we would end up with no constants that don't come from there when running in E3SM, so I also flagged constants that could be added to shr_const_mod to enable that. (The only exception is scyr which I think is fine to remain outside the ifdef block.)

The issue you ask about related to ice and ocean densities is a tougher one and the main reason I had put off trying to address this set of changes. I will follow up on that item in a separate comment.

[matthewhoffman]

This one can be aligned with SHR_CONST_RGAS

[Copilot]

Completed in 8bc15ed (implemented in 2965b6c and refined in follow-ups): the ideal gas constant path is now aligned with SHR_CONST_RGAS for E3SM builds.

[matthewhoffman]

This could be rewritten in terms of this:
https://github.com/E3SM-Project/E3SM/blob/master/share/util/shr_const_mod.F90#L65-L66

@xylar , what do you think? oceanFreezingTempDepthDependence is used in 3 places in MALI:

• Jourdain ice-shelf melt rate param for adjusting Tf with depth
• vertical TF extrapolation
• calculating basal temperature of ice shelves in thermodynamics calculation

[xylar]

We should instead see if we can add this (or these) to PCD. But it's a pretty ad hoc constant. We do need a citation at least.

[matthewhoffman]

@xylar , should this be added to share/util/shr_const_mod.F90?

[xylar]

This should go to PCD.

[matthewhoffman]

Regarding the density of ice in ice sheets, I've always felt 917 kg/m3 is the wrong value to use, because glacier ice is known to have slightly lower density than that. It's not a big enough difference to overcomplicate things, so I can be convinced to live with 917 if it just makes other things easier. But in looking at where this constant is used in E3SM outside of MALI, it is in the sea ice, land, and ocean components. I think it makes sense for sea ice and land to continue using SHR_CONST_RHOICE=917. Within the ocean, the only use of SHR_CONST_RHOICE is in defining the MPAS-Ocean-specific variable rho_ice = SHR_CONST_RHOICE in components/mpas-ocean/src/shared/mpas_ocn_constants.F. However, rho_ice is never used in MPAS-Ocean that I can find, so I think deleting that variable from components/mpas-ocean/src/shared/mpas_ocn_constants.F should be added to this PR.

Rather than using rho_ice, MPAS-Ocean instead uses a namelist variable config_land_ice_flux_rho_ice (which defaults to a different value, 918).

So the situation is MALI and MPAS-Ocean both only support the density of glacier ice as coming from their respective namelists with no way to ensure consistency. I propose the following solution:

• add a new glacier ice density constant, SHR_CONST_RHOGLACIERICE=910, in shr_const_mod
• Add logic to MALI and MPAS-Ocean to use a default density defined in their respective mpas_*_constants.F module when their respective ice density namelists are set to negative values
• In the MALI and MPAS-Ocean respective mpas_*_constants.F modules, use SHR_CONST_RHOGLACIERICE` when in E3SM and 910 when not.
• Update namelist_defaults.xml for both components to set their respective glacier ice density namelist variables to -1 in E3SM to trigger the use of the shr_const version.

This solution would allow the following:

• Backwards compatibility with existing MALI initial condition files
• Ability to support glacier ice density other than E3SM's current imposition of ice density being 917.
• Guarantee that MPAS-Ocean and MALI are using the same glacier ice density as each other when running in E3SM, but leave them both the ability to use a different value in standalone if desired.

@xylar , @trhille - thoughts?

[xylar]

Oof, we are trying to move shr_const_mod itself to use Physical Constants Dictionary (https://github.com/E3SM-Project/E3SM/blob/master/share/util/pcd_const.F90), original sources: https://github.com/E3SM-Project/E3SM/blob/master/share/pcd.yaml

It would be a bit unfortunate to try to add anything new to shr_const_mod instead of adding it to PCD.

[xylar]

Regarding ice density, I don't have strong feelings. Please do delete the unused rho_ice from MPAS-Ocean. Please do add a shared constant like SHR_CONST_RHOGLACIERICE but let's figure out how to start setting anything new that is added from PCD, not from shr_const_mod.

[matthewhoffman]

@xylar , thanks for the reminder about PCD; I had totally forgotten about that migration!

[matthewhoffman]

@xylar , to elaborate on PCD, it looks like the proper way to introduce changes is through this standalone PCD repo which autoupdates E3SM: https://github.com/e3sm-project/PhysicalConstantsDictionary
And then all of those SHR_CONST variables would need to be replaced with the corresponding PCD variable names (and the use statement). Does that all sound correct?

(Sorry, @trhille , that would mean a substantial refactor of this PR, though, granted, it's not a ton of lines.)

[trhille]

Telling @copilot what to do next based on the above discussion.
In addition to the changes requested in line comments, do the following:

1. delete the unused rho_ice from MPAS-Ocean.
2. Add a shared constant for ice density (something like SHR_CONST_RHOGLACIERICE to the Physical Constants Dictionary (PCD): https://github.com/E3SM-Project/E3SM/blob/master/share/pcd.yaml
3. Add logic to MALI and MPAS-Ocean to use a default density defined in their respective mpas_*_constants.F module when their respective ice density namelists are set to negative values
4. In the MALI and MPAS-Ocean respective mpas_*_constants.F modules, use SHR_CONST_RHOGLACIERICE` when in E3SM and 910 when not.
5. Update namelist_defaults.xml for both components to set their respective glacier ice density namelist variables to -1 in E3SM to trigger the use of the shr_const version.

[trhille]

Add this to https://github.com/E3SM-Project/E3SM/blob/master/share/pcd.yaml and use that definition for MALI.

[Copilot]

Addressed in 2965b6c (with follow-ups through 8bc15ed): this constant is now sourced from shared constants in E3SM builds and aligned fallback behavior is in place for standalone builds.

[trhille]

Align idealGasConstant with SHR_CONST_RGAS.

[Copilot]

Done in 8bc15ed (implemented in 2965b6c, refined in follow-ups): idealGasConstant is now aligned to SHR_CONST_RGAS in E3SM builds and uses the same conversion-based fallback formula in standalone builds.

[trhille]

Add oceanFreezingTempDepthDependence to https://github.com/E3SM-Project/E3SM/blob/master/share/pcd.yaml and use that value for MALI.

[Copilot]

Addressed in 8bc15ed (implemented in 2965b6c): oceanFreezingTempDepthDependence now uses the shared-source path in E3SM builds (SHR_CONST_DTF_DZ) and a formula-based fallback in standalone builds.

[trhille]

@copilot, instead of adding values to this module, please add them to https://github.com/MALI-Dev/E3SM/blob/develop/share/pcd.yaml and have MALI import them from https://github.com/MALI-Dev/E3SM/blob/develop/share/util/pcd_const.F90.

[Copilot]

Done in e95a583 (implemented in d13684c and refined in follow-ups): I moved the newly introduced values into share/pcd.yaml, added share/util/pcd_const.F90, updated MALI to import those constants from pcd_const, and removed the added hard-coded entries from shr_const_mod.

[trhille]

@copilot, this file should not be edited directly, as it is auto-generated from pcd.yaml
See the header in https://github.com/E3SM-Project/E3SM/blob/master/share/util/pcd_const.F90

! WARNING! DO NOT EDIT THIS FILE!
! This file was generated automatically from pcd.yaml
! For more information, visit https://github.com/e3sm-project/PhysicalConstantsDictionary

[Copilot]

Addressed in b1ba1c4: I restored share/util/pcd_const.F90 to the autogenerated form (including the generated-file header) and removed the direct usage of manually-added pcd_const symbols in MALI/MPAS-Ocean code paths.

[xylar]

@xylar , to elaborate on PCD, it looks like the proper way to introduce changes is through this standalone PCD repo which autoupdates E3SM: https://github.com/e3sm-project/PhysicalConstantsDictionary
And then all of those SHR_CONST variables would need to be replaced with the corresponding PCD variable names (and the use statement). Does that all sound correct?

Yes, that's exactly right.

[xylar]

Add a shared constant for ice density (something like SHR_CONST_RHOGLACIERICE to the Physical Constants Dictionary (PCD): https://github.com/E3SM-Project/E3SM/blob/master/share/pcd.yaml

@trhille, we can't edit this file. It needs to be done upstream in the https://github.com/e3sm-project/PhysicalConstantsDictionary repo.

[trhille]

• add a new glacier ice density constant, SHR_CONST_RHOGLACIERICE=910, in shr_const_mod

@matthewhoffman, should this be SHR_CONST_RHOGLACIERICE=917 rather than 910? And of course, PCD rather than shr_const_mod.

[matthewhoffman]

@matthewhoffman, should this be SHR_CONST_RHOGLACIERICE=917 rather than 910?
No, I was thinking we would want it to be 910 to match what MALI has done historically and what was used in the optimizations for our current meshes (to provide backwards compatibility). By introducing the new constant, it lets us decide what ice density to use for ice sheets while still allowing sea ice and land to use the standard pure ice value.