OCN to GLC thermal forcing coupling

[matthewhoffman]

This pull request introduces coupling from OCN to GLC to pass thermal forcing at a prescribed ocean depth (300 m) from MPAS-Ocean to MALI, where MALI uses it to calculate grounded marine melting through an existing 'facemelting' parameterization. Facemelting as a function of ocean thermal state is a critical OCN/GLC coupling for Greenland, but it is relevant to Antarctica as well. This OCN-GLC thermal forcing coupling is activated whenever OCN is present and GLC is active.

This PR has pieces in MPAS-Ocean, the coupler, and MALI:

• In MPAS-Ocean, a new avgThermalForcingAtCritDepth field is added and calculated. The depth at which to calculate the thermal forcing is namelist configurable. The default is 300 m.
• In MALI, the field passed from the coupler is collected in ismip6_2dThermalForcing and used in the existing facemelting parameterization. Namelist and streams are updated to use facemelting in all simulations and output relevant variables. For compsets where TF is not being coupled, it will have values of 0 and result in no facemelting being applied; it is safe to have this option generally turned on.
• In the coupler, a new remapping object is created that handles the TF mapping independently of any other fields passed from OCN to GLC. New mapping files are added. Any coupling variables related to the existing ice-shelf coupling now include the 'shelf' suffix and all coupling variables related to this new thermal-forcing coupling have the 'tf' suffix.
• A new compset is created that is a standard G-case but with active MALI. New mapping files are added between the relevant grids for the new mapper.
• The new OCN2GLC_TF_SMAPNAME mapping should be a nearest source to destination mapping with the MPAS-Ocean source mesh masked to only include grid cells that are deeper than the critical depth to avoid extrapolating undefined values. A tool to generate that map file is here: https://github.com/MPAS-Dev/MPAS-Tools/pull/578
• Two new model_grids are added that are compatible with this feature and include the special mapping file required: TL319_IcoswISC30E3r5_gis1to10kmR2 and TL319_oQU240wLI_gis20
• The new coupling is controlled by a new namelist option in MPAS-Ocean: config_glc_thermal_forcing_coupling_mode. It defaults to 'off' and there are no compsets that explicitly set it for now, making this a stealth feature.

This PR was initially reviewed at https://github.com/E3SM-Ocean-Discussion/E3SM/pull/94

[matthewhoffman]

Testing

Tested on Chrysalis with:

$ ./create_test --wait --walltime 0:30:00  ERS_Ld5.TL319_oQU240wLI_gis20.MPAS_LISIO_JRA1p5.chrysalis_intel.mpaso-ocn_glc_tf_coupling
Using project from config_machines.xml: e3sm
create_test will do up to 1 tasks simultaneously
create_test will use up to 160 cores simultaneously
Creating test directory /lcrc/group/e3sm/ac.mhoffman/scratch/chrys/ERS_Ld5.TL319_oQU240wLI_gis20.MPAS_LISIO_JRA1p5.chrysalis_intel.mpaso-ocn_glc_tf_coupling.20240920_132421_1imid2
RUNNING TESTS:
  ERS_Ld5.TL319_oQU240wLI_gis20.MPAS_LISIO_JRA1p5.chrysalis_intel.mpaso-ocn_glc_tf_coupling
Starting CREATE_NEWCASE for test ERS_Ld5.TL319_oQU240wLI_gis20.MPAS_LISIO_JRA1p5.chrysalis_intel.mpaso-ocn_glc_tf_coupling with 1 procs
Finished CREATE_NEWCASE for test ERS_Ld5.TL319_oQU240wLI_gis20.MPAS_LISIO_JRA1p5.chrysalis_intel.mpaso-ocn_glc_tf_coupling in 2.631567 seconds (PASS)
Starting XML for test ERS_Ld5.TL319_oQU240wLI_gis20.MPAS_LISIO_JRA1p5.chrysalis_intel.mpaso-ocn_glc_tf_coupling with 1 procs
Finished XML for test ERS_Ld5.TL319_oQU240wLI_gis20.MPAS_LISIO_JRA1p5.chrysalis_intel.mpaso-ocn_glc_tf_coupling in 0.406382 seconds (PASS)
Starting SETUP for test ERS_Ld5.TL319_oQU240wLI_gis20.MPAS_LISIO_JRA1p5.chrysalis_intel.mpaso-ocn_glc_tf_coupling with 1 procs
Finished SETUP for test ERS_Ld5.TL319_oQU240wLI_gis20.MPAS_LISIO_JRA1p5.chrysalis_intel.mpaso-ocn_glc_tf_coupling in 7.180280 seconds (PASS)
Starting SHAREDLIB_BUILD for test ERS_Ld5.TL319_oQU240wLI_gis20.MPAS_LISIO_JRA1p5.chrysalis_intel.mpaso-ocn_glc_tf_coupling with 1 procs
Finished SHAREDLIB_BUILD for test ERS_Ld5.TL319_oQU240wLI_gis20.MPAS_LISIO_JRA1p5.chrysalis_intel.mpaso-ocn_glc_tf_coupling in 192.547771 seconds (PASS)
Starting MODEL_BUILD for test ERS_Ld5.TL319_oQU240wLI_gis20.MPAS_LISIO_JRA1p5.chrysalis_intel.mpaso-ocn_glc_tf_coupling with 6 procs
Finished MODEL_BUILD for test ERS_Ld5.TL319_oQU240wLI_gis20.MPAS_LISIO_JRA1p5.chrysalis_intel.mpaso-ocn_glc_tf_coupling in 961.745927 seconds (PASS)
Starting RUN for test ERS_Ld5.TL319_oQU240wLI_gis20.MPAS_LISIO_JRA1p5.chrysalis_intel.mpaso-ocn_glc_tf_coupling with 1 proc on interactive node and 128 procs on compute nodes
Finished RUN for test ERS_Ld5.TL319_oQU240wLI_gis20.MPAS_LISIO_JRA1p5.chrysalis_intel.mpaso-ocn_glc_tf_coupling in 5.035480 seconds (PEND). [COMPLETED 1 of 1]
Waiting for tests to finish
PASS ERS_Ld5.TL319_oQU240wLI_gis20.MPAS_LISIO_JRA1p5.chrysalis_intel.mpaso-ocn_glc_tf_coupling RUN
    Case dir: /lcrc/group/e3sm/ac.mhoffman/scratch/chrys/ERS_Ld5.TL319_oQU240wLI_gis20.MPAS_LISIO_JRA1p5.chrysalis_intel.mpaso-ocn_glc_tf_coupling.20240920_132421_1imid2
test-scheduler took 1250.1114015579224 seconds

[github-actions[bot]]

PR Preview Action v1.4.8 :---: :rocket: Deployed preview to https://E3SM-Project.github.io/E3SM/pr-preview/pr-6632/ on branch gh-pages at 2024-09-20 19:01 UTC

[jonbob]

Testing shows:

• new test ERS_Ld5.TL319_oQU240wLI_gis20.MPAS_LISIO_JRA1p5.chrysalis_intel.mpaso-ocn_glc_tf_coupling ran successfully
• ERS.ne30_g16_rx1.A.chrysalis_intel showed NML and regular DIFF, as expected
• ERP_Ld3.ne30pg2_r05_IcoswISC30E3r5.WCYCL1850.chrysalis_intel.allactive-pioroot1 showed NML DIFF, as expected

The last test also reported "BASELINE master: FIELDLIST field lists differ (otherwise bit-for-bit)" as a FAIL

@rljacob -- how do we document this kind of PR, if it's BFB but adding a field?

[rljacob]

I thought adding a field makes the X-case diff. A-case is all data models. Why would that diff?

Also I never got an answer for how the JRA025 river grid is different from r025.

[jonbob]

merged to next

[jonbob]

@rljacob -- you're right about it being X-cases. The A-case was non-BFB due to the new field but not a baseline DIFF. I changed that in the PR description just now. As for the JRA025 vs r025, the JRA domain is defined from 0 to 360 longitude while it's -180 to +180 for r025. Otherwise I think they are very close to the same.

[jonbob]

removed from next -- @rljacob force-pushed next to clear. Re-working to minimize impact on the coupler

[rljacob]

Notes: still planning a rework

[matthewhoffman]

@jonbob , the addition of the flds_tf logic makes sense to me, and I don't have any concerns about the details or the naming conventions. If you are happy with this solution as-is, I'm happy to proceed.

[jonbob]

@matthewhoffman -- I'm not sure if this is intentional, but testing shows non-BFB behavior when MALI is active. It's apparently due to the change in the default setting for config_front_mass_bal_grounded.

[matthewhoffman]

@jonbob , yes, activating config_front_mass_bal_grounded was intentional - that is the option that lets MALI use the new ocean coupling to calculate submarine melt rates.

[jonbob]

Testing with e3sm_developer showed expected NML DIFFs but also a run failure for:

• ERS_Ld5.TL319_oQU240wLI_ais8to30.MPAS_LISIO_JRA1p5.chrysalis_intel.mpaso-ocn_glcshelf

[jonbob]

Updated cime_comp_mod.F90 so that ocn_c2_glcshelf and ocn_c2_glctf are set correctly by mpaso. Previously ocn_c2_glcshelf was being overwritten and ocn_c2_glctf was not being retrieved from infodata. Now the test that had a run failure (ERS_Ld5.TL319_oQU240wLI_ais8to30.MPAS_LISIO_JRA1p5.chrysalis_intel.mpaso-ocn_glcshelf) completes and has the appropriate ocn-glc settings:

(seq_mct_drv) : ocn_c2_glcshelf       =      T
(seq_mct_drv) : ocn_c2_glctf          =      F
(seq_mct_drv) : glcshelf_c2_ocn       =      T
(seq_mct_drv) : glcshelf_c2_ice       =      T

The new test ERS_Ld5.TL319_oQU240wLI_gis20.MPAS_LISIO_JRA1p5.chrysalis_intel.mpaso-ocn_glc_tf_coupling now also runs with the correct settings:

(seq_mct_drv) : ocn_c2_glcshelf       =      F
(seq_mct_drv) : ocn_c2_glctf          =      T
(seq_mct_drv) : glcshelf_c2_ocn       =      F
(seq_mct_drv) : glcshelf_c2_ice       =      F

[jonbob]

Re-testing with e3sm_developer on chrysalis after latest commit now shows:

• expected NML DIFFs for all tests
• expected DIFFs for: ERS.f09_g16_g.MALISIA.chrysalis_intel ERS_Ld5.TL319_oQU240wLI_ais8to30.MPAS_LISIO_JRA1p5.chrysalis_intel.mpaso-ocn_glcshelf

[jonbob]

@matthewhoffman -- my last commit changed some settings, but I think to the expected values. However, I would appreciate you making sure before this gets merged

[matthewhoffman]

@jonbob , thanks for sorting out these details and catching those issues. Based on our discussion this morning, I am happy with the changes and this can proceed to be merged.

[rljacob]

note: ready to go but will make NML for every test.

[jonbob]

Passes:

• PET.f19_g16.X.chrysalis_intel.allactive-mach-pet
• SMS_D_Ld1.ne30pg2_r05_IcoswISC30E3r5.WCYCL1850.chrysalis_intel.allactive-wcprod

with expected NML DIFFs. Merged to next

[jonbob]

merged to master and expected DIFFs and NML DIFFs blesses -- except for pm-cpu which has not yet reported

[jonbob]

Also blessed now on pm-cpu