ismip7_forcing

The ismip7_forcing test group (compass.landice.tests.ismip7_forcing.Ismip7Forcing) processes (i.e., remaps and renames) the atmospheric and ocean thermal forcing data of the Ice Sheet Model Intercomparison for CMIP7 (ISMIP7) protocol from its native polar stereographic grid to the MALI unstructured mesh. The test group supports both AIS and GrIS via the ice_sheet config option. It includes three test cases: atmosphere, ocean_thermal, and fracture.

framework

The shared config options for the ismip7_forcing test group are described in ismip7_forcing in the User’s Guide.

Code shared with the other ISMIP7 test groups lives in the landice framework package compass.landice.ismip7, described in Land-ice Framework. This test group uses compass.landice.ismip7.ice_sheet_params.get_params() for invariant ice-sheet-specific parameters (projection, file naming prefix, and ocean dimensionality), compass.landice.ismip7.archive for native archive path, resolution, and version discovery, compass.landice.ismip7.mapping.build_mapping_file() to create the SCRIP and ESMF mapping files from dedicated BuildMappingFile steps, and the remapping helpers in compass.landice.ismip7.remap.

When scenario = OCX, get_params supplies the fixed reanalysis sources (atm_model = RACMO2.3p2-ERA for both ice sheets and ocean_model = EN4 for GrIS). For AIS OCX, ocean_model remains unset and the archive resolver uses per-choice ocean directories (main/cold/warm/vary). The archive resolver discovers native paths, selected resolutions, and versions. The processing steps use atm_model / ocean_model in place of the [ismip7] model option when they are set, so the OCX model option is ignored. This keeps OCX handling centralized and lets a single config file drive both test cases.

configure

The module compass.landice.tests.ismip7_forcing.configure validates that all required config options in the [ismip7] section have been set by the user (i.e., are not NotAvailable).

Repository-local example user configs are available at compass/landice/tests/ismip7_forcing/ismip7_forcing_test.cfg (AIS) and compass/landice/tests/ismip7_forcing/ismip7_forcing_test_gis.cfg (GrIS). The GrIS OCX scenario has a dedicated example ismip7_forcing_ocx_gis.cfg in the same directory. These are intended for development/testing and include environment-specific paths.

Test cases

atmosphere

The compass.landice.tests.ismip7_forcing.atmosphere.Atmosphere test case processes the ISMIP7 atmosphere forcing fields. It contains a mapping step followed by five processing steps for SMB, temperature, their respective gradients, and runoff. The mapping step uses the archive resolver to select the configured source grid and runs with esmf_ntasks. Each processing step consumes those weights and remaps its input files with ncremap. latest is resolved per variable because atmosphere datasets can have different current versions.

Steps:

ocean_thermal

The compass.landice.tests.ismip7_forcing.ocean_thermal.OceanThermal test case processes the ISMIP7 ocean thermal forcing. It contains three steps: a mapping step (BuildMappingFile), the processing step (ProcessThermalForcing, which handles both AIS (3D, decade-spanning files) and GrIS (2D, yearly files) by branching on the ocean_3d parameter from ice_sheet_params), and BuildGreenland3dThermalForcing, which optionally builds a 3D GrIS field from the 2D forcing (see below). The mapping step builds each enabled scenario or climatology mapping with esmf_ntasks.

The run() method dispatches to two sub-methods based on the boolean config options process_ocean_thermal and process_ocean_climatology in the [ismip7] section:

  • _run_scenario(): Processes time-varying ESM scenario data (model + scenario combination). Uses config from [ismip7_ocean_thermal].

  • _run_climatology(): Processes the static observational climatology (Zhou et al., AIS only). Uses config from [ismip7_ocean_climatology].

For AIS scenario data, the step:

  • Remaps thermal forcing preserving 30 vertical ocean layers

  • Produces ismip6shelfMelt_3dThermalForcing (dims: Time × nCells × nISMIP6OceanLayers)

  • Includes depth coordinate variables ismip6shelfMelt_zOcean and ismip6shelfMelt_zBndsOcean

For AIS climatology data, the step:

  • Extrapolates fill values, remaps, and renames to MALI conventions

  • Produces ismip6shelfMelt_3dThermalForcing (dims: nCells × nISMIP6OceanLayers) — no Time dimension

For GrIS, the step:

  • Remaps 2D monthly thermal forcing

  • Produces ismip6_2dThermalForcing (dims: Time × nCells)

build_3d_thermal_forcing (GrIS 3-D)

The BuildGreenland3dThermalForcing step (GrIS only, gated by process_ocean_thermal_3d) converts the GrIS 2D thermal forcing into a configurable-level 3D field for MALI’s nonlocal (Jourdain et al. 2020) melt scheme. Its run() reconstructs the 2D output path that ProcessThermalForcing._run_scenario wrote (mirroring the forcing_group and ocean-source logic), injects the compass-derived mesh / 2D-forcing / output / diagnostics paths into a Config built from the JSON config_file, and calls run(). The ported science lives in compass.landice.tests.ismip7_forcing.ocean_thermal.greenland_3d: seven regional EN4 profiles, seafloor anchoring to the 2D forcing, and per-region deltaT calibration. The output supplements the 2D file with ismip6shelfMelt_3dThermalForcing, ismip6shelfMelt_deltaT, ismip6shelfMelt_gamma0, ismip6shelfMelt_zOcean, and ismip6shelfMelt_basin. The multi-gigabyte field is streamed record by record (dask, netCDF4 engine → nccopy -k nc6 for CDF-2, .partial-then-rename).

fracture

The compass.landice.tests.ismip7_forcing.fracture.Fracture test case processes the ISMIP7 surface-melt-driven ice shelf collapse forcing (AIS only). It contains a mapping step followed by three independent pathway-processing steps. The mapping step uses a lake-properties or shelf-collapse file with native x/y coordinates and builds one file per unique enabled remapping method. Each processing step discovers its source file from the native AIS/{model}/{scenario}/fracture/{version}/ hierarchy, remaps with ncremap, and renames the result to MALI conventions with an accompanying xtime variable. Per-pathway remapping methods are set in the [ismip7_fracture] config section. Setting a pathway’s remapping-method option to None causes that step to return early without processing its file, which is useful when only some pathway source files are available.

Steps:

  • BuildMappingFile — builds and caches the enabled fracture mapping files

  • ProcessExcessMelt (Path A) — excess_melt → ismip7ExcessMelt. The excess melt file lacks x/y coordinate variables and its array is flipped along the y axis relative to the other fracture files (it was produced with CDO). The _prepare_source_grid() method borrows x/y from a sibling fracture file, flips the data to match (raising if the flipped lat does not match the sibling grid), and writes a reconstructed source file. The field is then extrapolated (nearest neighbor, filling NaNs) and remapped conservatively by default (it is a flux).

  • ProcessLakeProperties (Path B) — lake_depth → ismip7LakeDepth and fraction_lake_area → ismip7LakeAreaFraction. Both variables are extrapolated and remapped in a single ncremap call (bilinear by default).

  • ProcessShelfCollapse (Path C) — mask → calvingMask. Remapped with neareststod by default and rounded to 0/1 so the discrete collapse mask is preserved.

The annual source fields use an integer year/time coordinate with units="year" (not CF-compliant), so each step opens the data with decode_times=False and constructs xtime at January 1st of each year.

Shared remapping helpers used by the fracture steps live in compass.landice.ismip7.remap: extrapolate_source (nearest-neighbor fill of NaNs on the source grid), open_rename_and_trim (open a remapped file, rename dimensions/variables to MALI conventions, and restrict to the requested year range), and add_xtime_and_write (add the xtime variable, drop auxiliary remapping variables, and write the output).

The output variable names for Paths A and B (ismip7ExcessMelt, ismip7LakeDepth, ismip7LakeAreaFraction) are descriptive placeholders and may need to be aligned with the MALI Registry once the corresponding model input fields are defined.