Add 3d thermal forcing to OCN-GLC coupling #7215
Conversation
matthewhoffman
added
MPAS-ocean
|
Discussion and testing documented at E3SM-Ocean-Discussion#121 |
xylar
left a comment
xylar
left a comment
There was a problem hiding this comment.
Approving based on a careful inspection of the code (with a particular focus on the MPAS-Ocean changes) and my own testing, including adding debug fields that reconstructed the vertical coordinate in addition to the thermal forcing on the z-levels that glc accepts. Also approving based on other testing reported in E3SM-Ocean-Discussion#121
|
Assuming #7195 goes in before this, there are a few things we'll need to fix after rebasing on to that merge:
|
|
@rljacob -- we've asked you to review this as well since it touches the coupler |
|
@rljacob , I'd be happy to meet and walk you through it if that would be easier for you. |
|
FYI, I plan to rebase this to deal with known conflicts with #7195, now that 7195 is on master. I hope to do that tomorrow. |
|
I'm running a I'm looking into this but wanted to give you a heads up that a fix is likely needed. |
|
@matthewhoffman, I think maybe you'd better take this one on. It seems like maybe the |
|
It seems like there will be 30 vertical levels if both MALI and MPAS-Ocean are active: |
|
Thanks, @xylar , that makes sense. I'll address that today. |
matthewhoffman
force-pushed
the
matthewhoffman/ocn-glc/3d-tf-ocn-glc
branch
from
1e3b2e1 to
10d062f
Compare
|
@xylar , I've rebased and made some changes:
I also touched base with Jon about needing some new mapping files for SOwISC12to30E3r4 to use TF coupling, now that that came in as part of the rebase. I confirmed the following tests pass after the changes that could affect these grids:
However, SMS_D_Ld5.TL319_oQU240wLI_ais8to30.GMPAS-JRA1p5-DIB-PISMF-SIS.chrysalis_gnu still fails. The errors Xylar was seeing are now gone and the code gets through init for all components. However, it dies with this error in the e3sm log file: I will need to look into this further, but am stopping here for now. |
| logger.warning("WARNING: The specified compset is requesting ocean ICs spunup from a G-case") | ||
| logger.warning(" But no file available for this grid.") | ||
| if ocn_ismf == 'data': | ||
| if ocn_glc_ismf_coupling == 'data_mpaso': |
There was a problem hiding this comment.
Great, glad you caught this one, too. I needed this change in my test-merge branch.
|
@xylar , I've pushed commits that will handle the situation where both OCN and GLC are active but we don't want TF coupling (e.g. MALI DATA and STATIC modes). With these changes, |
|
...and the compsets that do include TF coupling are now broken. I'll wait to update again until I can get all test cases working again. |
|
I fixed a bug introduced in the previous commit and reran these tests to confirm things are working as intended:
Other than the needed mapping files for |
|
@jonbob , I added a commit that updates the SOwISC12to30E3r4 mapping files. I successfully ran a test with There are no remaining revisions to make that I am aware of. @rljacob , this is at a good point for you to review if you would like to review it. |
| "ERS_Ld5_D.T62_oQU240.GMPAS-IAF.mpaso-conservation_check", | ||
| "ERS_Ld5_PS.ne30pg2_r05_IcoswISC30E3r5.CRYO1850-DISMF.mpaso-scaled_dib_dismf", | ||
| "ERS_Ld5.TL319_oQU240wLI_gis20.MPAS_LISIO_JRA1p5.mpaso-ocn_glc_tf_coupling", | ||
| # OCN/GLC 3d TF coupling GIS test: |
There was a problem hiding this comment.
should we run this e3sm_ocnice_stealth_features suite somewhere on a regular basis?
There was a problem hiding this comment.
Oh I see. Its included in extra coverage.
| <map name="OCN2GLC_SHELF_FMAPNAME">cpl/gridmaps/oQU240wLI/map_oQU240wLI_to_gis20km_esmfaave.20240919.nc</map> | ||
| <map name="OCN2GLC_SHELF_SMAPNAME">cpl/gridmaps/oQU240wLI/map_oQU240wLI_to_gis20km_esmfbilin.20240919.nc</map> | ||
| <map name="OCN2GLC_TF_SMAPNAME">cpl/gridmaps/oQU240wLI/map_oQU240wLI_to_gis20km_deeperThan300m.esmfneareststod.20240919.nc</map> | ||
| <map name="OCN2GLC_TF_SMAPNAME">cpl/gridmaps/oQU240wLI/map_oQU240wLI_to_gis20km_esmfbilin.20240919.nc</map> |
There was a problem hiding this comment.
I still can't get it to work when both grids are non-global like this. I understand that mbtempest can do that, but I haven't really entrained that into my workflow
'none' is set when the compset does not include the ocean
Both Greenland meshes currently have issues that cause problems when using OCN2GLC_TF_SMAPNAME mapping files that don't have extrapolation. For the gis4to40 mesh, there is an "inland sea" region that does not get valid ocean thermal forcing, leading to MALI errors in facemelting. Here, I've switched the map file to one that includes extrapolation to work around this issue. The inland sea problem is being fixed in a different PR, and after that is merged, this map file can be switched back to the version without extrapolation, so that the bathymetry-aware extrapolation inside of MALI can be used instead. The gis1to10kmR2 mesh has a different problem - the ocean "gutter" is too narrow and only overlaps the IcoswISC30E3r5 grid in a few places. Switching to a OCN2GLC_TF_SMAPNAME mapping file that includes extrapolation similarly works around this problem. A more thorough solution will require creating a new high-res GIS mesh with a larger gutter.
We want 3d TF coupling on for all compsets with both MPAS-Ocean and MALI active because we want to use 3d TF for facemelting even if we use ice-shelf basal melt fluxes from the coupler. However, we do not want facemelting when MALI is DATA or STATIC modes, so the TF coupling should be inactive in those cases.
1. OCN_ISMF -> OCN_GLC_ISMF_COUPLING for landice freshwater flux logic 2. OCN_ISMF -> OCN_GLC_ISMF_COUPLING for sowisc12to30e3r4 mesh logic
* mpas.ais8to30km: removed nISMIP6OceanLayers dimension and assoc. vars * mpas.ais4to20km: removed nISMIP6OceanLayers dimension and assoc. vars * mpas.gis4to40km: added missing muFriction field
This distinction is needed for compsets where both OCN and GLC are active but we do not want TF coupling (e.g. MALI STATIC and DATA modes).
matthewhoffman
force-pushed
the
matthewhoffman/ocn-glc/3d-tf-ocn-glc
branch
from
4361fa2 to
b14f9bf
Compare
|
Force-pushed after rebase to deal with known conflicts from #7210 being merged to master. |
|
@jonbob , I've rebased this PR and added the needed commit to introduce the time-averaging for the melt fluxes to the coupler. After those updates, I retested with: and the test passed. This is ready for final review and merge. |
| "ERS_Ld5_PS.ne30pg2_r05_IcoswISC30E3r5.CRYO1850-DISMF.mpaso-scaled_dib_dismf", | ||
| "ERS_Ld5.TL319_oQU240wLI_gis20.MPAS_LISIO_JRA1p5.mpaso-ocn_glc_tf_coupling", | ||
| # OCN/GLC 3d TF coupling GIS test: | ||
| "ERS_Ld5.TL319_oQU240wLI_gis4to40.MPAS_FOLISIO_JRA1p5.mpaso-jra_1958", |
There was a problem hiding this comment.
@matthewhoffman -- it doesn't look like this stealth test is actually turning the feature on?
jonbob
added
non-BFB
Add 3d thermal forcing to OCN-GLC coupling This pull request extends the existing thermal-forcing coupling functionality from a single depth to a predefined set of z-levels. The implementation follows that of multiple elevation classes in the LND-GLC coupling. A new xml variable is added, GLC_NZOC. It has a default value of 0, meaning TF coupling is disabled. The standard value for when the coupling is activated is 30, which follows the TF z-levels used by ISMIP6. Other values are supported, and an additional example with 4 levels is included. A new coupler module, glc_zocnclass_mod.F90, is added which is follows very closely from glc_elevclass_mod.F90. It contains subroutines and functions to initialize the z-level classes and to access the z-level values. It also has subroutines to provide the z-level indices as strings, which the coupling field initialization code and the component import/export routines uses to create GLC_NZOC fields, one for each layer. This 3d TF coupling is used for ice-sheet outlet glacier facemelting (melting at vertical glacier margins terminating in the ocean), and so is used for a process that we do not anticipate resolving explicitly in MPAS-Ocean (or Omega). As such, this coupling should be included anytime both OCN and GLC are active, and logic has been added so that this is the case based on compset definition. There are versions of the GLC_NZOC variable in both the MPAS-Ocean and MALI Registries so that it can be set by namelist settings controlled by CIME/build operations. The MPAS-Ocean mpas_ocn_time_average_coupled.F module has been modified to loop over the z-levels and calculate TF at each one. Then, the time- averaged 3d TF values are passed to the coupler, where they are remapped to the GLC mesh and passed to MALI. MALI assigns the values to its existing 3d TF field, and the uses its bathymetry-aware extrapolation routine to extrapolate the TF values from the edge of the MPAS-Ocean domain to wherever the ice-sheet margin is on the MALI mesh. From there, the TF is used to force the facemelting parameterization. Mapping files have been updated to not include extrapolation in the mapping so as to allow the bathymetry-aware extrapolation in MALI to operate, where appropriate. The facemelting flux in MALI is exported to the previously unused Fogg_rofi flux, which already gets combined in the coupler with ice runoff to be imported in MPAS-Ocean in the Foxx_rofi flux. Long term, we may want to separate these runoff fluxes so that the horizontal and vertical distribution of facemelting can be handled differently than other solid runoff, but this provides a reasonable first approximation. Note that this 3d TF can also be used to force the ISMIP6 ice-shelf basal melt parameterization in MALI, which provides a less sophisticated alternative to using ice-shelf basal melt rates calculated in the coupler (or MPAS-Ocean). This simpler approach will be used for the few, small ice shelves in Greenland, which are not included in the MPAS-Ocean meshes (and would not be resolved even if they were). This approach can also be used for Antarctica as an alternative that avoids grounding line migration issues in MPAS-Ocean by taking advantage of the TF extrapolation in MALI. These different methods for ice-shelf basal melt fluxes are handled through a new XML variable OCN_GLC_ISMF_COUPLING, which specifies how ice-shelf melt fluxes are handled in both MPAS-Ocean and MALI. The previous 2d thermal forcing coupling has been removed. Tests have been updated to test this new 3d TF capability for grids with both GIS and AIS. [NML] [non-BFB] only for configurations with active MALI and ocn
|
Testing shows expected results:
Merged to next |
|
Thanks @jonbob!! And thanks @matthewhoffman for the hard work on this! |
|
merged to master and expected baseline and NML DIFFs blessed |
This pull request extends the existing thermal-forcing coupling functionality from a single depth to a predefined set of z-levels. The implementation follows that of multiple elevation classes in the LND-GLC coupling. A new xml variable is added, GLC_NZOC. It has a default value of 0, meaning TF coupling is disabled. The standard value for when the coupling is activated is 30, which follows the TF z-levels used by ISMIP6. Other values are supported, and an additional example with 4 levels is included. A new coupler module, glc_zocnclass_mod.F90, is added which is follows very closely from glc_elevclass_mod.F90. It contains subroutines and functions to initialize the z-level classes and to access the z-level values. It also has subroutines to provide the z-level indices as strings, which the coupling field initialization code and the component import/export routines uses to create GLC_NZOC fields, one for each layer.
This 3d TF coupling is used for ice-sheet outlet glacier facemelting (melting at vertical glacier margins terminating in the ocean), and so is used for a process that we do not anticipate resolving explicitly in MPAS-Ocean (or Omega). As such, this coupling should be included anytime both OCN and GLC are active, and logic has been added so that this is the case based on compset definition. There are versions of the GLC_NZOC variable in both the MPAS-Ocean and MALI Registries so that it can be set by namelist settings controlled by CIME/build operations.
The MPAS-Ocean mpas_ocn_time_average_coupled.F module has been modified to loop over the z-levels and calculate TF at each one. Then, the time-averaged 3d TF values are passed to the coupler, where they are remapped to the GLC mesh and passed to MALI. MALI assigns the values to its existing 3d TF field, and the uses its bathymetry-aware extrapolation routine to extrapolate the TF values from the edge of the MPAS-Ocean domain to wherever the ice-sheet margin is on the MALI mesh. From there, the TF is used to force the facemelting parameterization. Mapping files have been updated to not include extrapolation in the mapping so as to allow the bathymetry-aware extrapolation in MALI to operate, where appropriate.
The facemelting flux in MALI is exported to the previously unused Fogg_rofi flux, which already gets combined in the coupler with ice runoff to be imported in MPAS-Ocean in the Foxx_rofi flux. Long term, we may want to separate these runoff fluxes so that the horizontal and vertical distribution of facemelting can be handled differently than other solid runoff, but this provides a reasonable first approximation.
Note that this 3d TF can also be used to force the ISMIP6 ice-shelf basal melt parameterization in MALI, which provides a less sophisticated alternative to using ice-shelf basal melt rates calculated in the coupler (or MPAS-Ocean). This simpler approach will be used for the few, small ice shelves in Greenland, which are not included in the MPAS-Ocean meshes (and would not be resolved even if they were). This approach can also be used for Antarctica as an alternative that avoids grounding line migration issues in MPAS-Ocean by taking advantage of the TF extrapolation in MALI. These different methods for ice-shelf basal melt fluxes are handled through a new XML variable OCN_GLC_ISMF_COUPLING, which specifies how ice-shelf melt fluxes are handled in both MPAS-Ocean and MALI.
The previous 2d thermal forcing coupling has been removed. Tests have been updated to test this new 3d TF capability for grids with both GIS and AIS.
[NML]
[non-BFB] only for configurations with active MALI and ocn