Add support for mom (supergrid) grid format

[anton-seaice]

This changes adds grid_format = 'mom_nc' support to directly load the grid from a netcdf file which uses the mom (supergrid) definition, and calculates all fields to follow the method MOM6 uses. i.e.

• all lats & lons are read from the file
• all cell x/y lengths are read from the file
• A grid and B grid areas are read from the file, C grid areas are calculated internally (per Initialising areaC NOAA-GFDL/MOM6#740)
• angles are calculated internally (even though they exist in the mosaic file)

There are a few limitations:

• If the CHANNEL_CONFIG option is used in MOM6, this can change some cell sizes at runtime, however we are loading these from the file.
• MOM6 generates a land-sea mask by making land where the bathymetry<0.5m , however we are still loading from a kmt file which needs to be generated "offline".

I haven't tested every permutation of boundary conditions and grid type, I focussed on on tripolar grids and did best-effots checks on the other boundary conditions.

I found exact matches (to single point precision) between the MOM6 & CICE6 saved grids, see https://github.com/anton-seaice/sandbox/blob/main/new_cice_grid/mom_mosaic_in_cice.ipynb

The NUOPC driver checks for consistency in areas, and lon/lats between the model and the mediator. It applies a correction for differences in area between the model and the mediator. Even if the cell area field is populated in the mediator mesh file, this is not used and the area calculated by ESMF is used instead. Therefore depending on how the mosaic file was created (and how the areas are calculated for that process), the correction between model and mediator areas may not be 1 everywhere.

This change doesn't include any new tests, and I suggest deferring adding tests as it requires new forcing data

I also added kmt_type = 'none' - This is only for testing / idealised configurations, so it's not in the docs. It's not essential for this PR.

PR checklist

• Short (1 sentence) summary of your PR:
  Add support for creating the CICE grid from a MOM mosaic (supergrid) format
• Developer(s):
  @anton-seaice
• Suggest PR reviewers from list in the column to the right.
  @dabail10
• Please copy the PR test results link or provide a summary of testing completed below.
  To-do, if the change & scope looks ok, I will run the cice standalone tests, https://github.com/CICE-Consortium/Test-Results/wiki/cice_by_hash_forks#07bb8a004f0dff968441bf1f5852d79680d3d514
• How much do the PR code changes differ from the unmodified code?
  • bit for bit
  • different at roundoff level
  • more substantial
• Does this PR create or have dependencies on Icepack or any other models?
  • Yes
  • No
• Does this PR update the Icepack submodule? If so, the Icepack submodule must point to a hash on Icepack's main branch.
  • Yes
  • No
• Does this PR add any new test cases?
  • Yes
  • No - blocked on needing new test data, see Add tripolar netcdf grid to input data #977 (comment)
• Is the documentation being updated? ("Documentation" includes information on the wiki or in the .rst files from doc/source/, which are used to create the online technical docs at https://readthedocs.org/projects/cice-consortium-cice/. A test build of the technical docs will be performed as part of the PR testing.)
  • Yes
  • No, does the documentation need to be updated at a later time?
    • Yes
    • No
• Please document the changes in detail, including why the changes are made. This will become part of the PR commit log.
  This changes adds grid_format = 'mom_nc' support to directly load the grid from a netcdf file which uses the mom mosaic (supergrid) definition, and calculates all fields to follow the method MOM6 uses. Contributes to MOM supergrid and other grid types #807

[eclare108213]

@anton-seaice, it looks like 'mosaic' in this context has nothing to do with the field campaign. Is that correct? If so, it could be confusing for other users interested in the MOSAiC data. Let's figure out how to document both to reduce confusion. Certainly explain what they are in the readthedocs, but also perhaps add some comments to the diagnostic output?

[dabail10]

@anton-seaice, it looks like 'mosaic' in this context has nothing to do with the field campaign. Is that correct? If so, it could be confusing for other users interested in the MOSAiC data. Let's figure out how to document both to reduce confusion. Certainly explain what they are in the readthedocs, but also perhaps add some comments to the diagnostic output?

I agree. Maybe mosaic is not the right term to use here. Maybe mom_supergrid or just 'mom'. Also, I would add that grid_type has the following options currently: 'displaced_pole', 'tripole', 'default', 'regional', and 'latlon'. So, perhaps we should do something like 'mom_tripole'?

[eclare108213]

This looks good to me, overall, with some minor suggestions. Please remove Icepack from the PR.

[apcraig]

@anton-seaice, is the PR ready for formal review and testing?

[anton-seaice]

Thanks @apcraig - this is ready for review. The issue I mentioned in the last meeting has been fixed (was using cm instead of m for a few fields).

[eclare108213]

There are still a few comments that I'm not sure have been addressed. Otherwise this looks good. I have one question re namelist -- should we also use pop_nc instead of just nc now?

[apcraig]

Thanks for adding all the memory allocation/deallocation checks. I added a few comments for further review. Then I will run a large test suite on derecho with multiple compilers. I hope we can add a mom grid testcase soon to the standalone model.

[anton-seaice]

Thanks for the feedback @apcraig - I will implement and update this PR soon

[anton-seaice]

I think i've addressed the comments @apcraig & @eclare108213

[apcraig]

I am carrying out a full test suite on derecho. If all looks good, I'll approve and merge tomorrow unless there are any other concerns.

[apcraig]

With the one line fix above at ice_grid.F90, line 355, these changes pass the full test suite on derecho with 6 compilers. Once the one line fix is added to the PR, I will approve and merge the PR. https://github.com/CICE-Consortium/Test-Results/wiki/cice_by_hash_forks#07bb8a004f0dff968441bf1f5852d79680d3d514

[anton-seaice]

Thanks @apcraig - sounds good :)

[apcraig]

I reviewed the latest changes and ran a quick suite on the latest changes with all compilers on derecho and results look good. I will approve and merge in the next day or so unless there are other comments.