Skip to content

Configurations

Jump to bottom
Andrew Kiss edited this page Jul 7, 2023 · 75 revisions

CMEPS-coupled configurations

ACCESS-OM3 configurations are provided via these repositories. They all have prescribed data atmosphere and runoff.

  • MOM6-CICE6-WW3: 3-way coupled ocean, sea ice and waves
  • MOM6-CICE6: 2-way coupled ocean and sea ice (no waves)
  • CICE6-WW3: 2-way coupled sea ice and waves (prescribed data ocean)

These all have an accessom3_exe branch which uses the new access-om3 executables and is recommended.

The main branches are older and use executables built from https://github.com/ACCESS-NRI/CESM - see here. They currently require membership of the tm70 project TODO: check! - apply here if needed.

Overview of the CMEPS configurations

The three CMEPS-coupled configurations have much in common. Here we provide a quick overview of the common features, using examples from MOM6-CICE6.

What the configuration files are for

Where to set parameters

  • model executable
    • exe in config.yaml. Pre-built executables are available in /g/data/ik11/inputs/access-om3/bin/ or you can build your own. Executable names indicate the available model components and the git hash of the source code used. Avoid using the Debug versions for production runs as they are much slower.
  • active model components 
component_list: MED ATM ICE OCN ROF
ALLCOMP_attributes::
     ATM_model = datm  # data atmosphere
     GLC_model = sglc  # no glaciers/land ice (stub)
     ICE_model = cice  # active sea ice (cice)
     LND_model = slnd  # no land model (stub)
     MED_model = cesm  # mediator
     OCN_model = mom   # active ocean model (mom6)
     ROF_model = drof  # data runoff
     WAV_model = swav  # no wave model (stub)
     ...
  • fields to couple
    • Coupling is negotiated between model components during initialization of a model run. See here: "CMEPS advertises all possible fields that can be imported to and exported by the mediator for the target coupled system. Not all of these fields will be connected to the various components. The connections will be determined by what the components advertise in their respective advertise phase."
    • fd.yaml: NUOPC field dictionary defines standard metadata for fields that may be available for import and/or export from model components; standard_names are used for field pairing during initialisation
    • the fields available to be imported/exported for coupling are determined by the NUOPC cap code for MOM6, CICE6, WW3, DATM and DROF and recorded in the mediator log output file: grep "(Advertise Fields)" archive/output000/log/med.log
    • whether those fields are actually coupled is determined by the CMEPS mediator at run time (see here) and recorded in the mediator log output file: grep -A 9 "Active coupling flags" archive/output000/log/med.log
    • also see wavice_coupling in nuopc.runconfig
  • remapping/redistribution method
    • datm.streams.xml and drof.streams.xml specify <mapalgo>bilinear</mapalgo> but there are better options - see here and here
    • rof2ocn_ice_rmapname and rof2ocn_liq_rmapname in MED_attributes in nuopc.runconfig
    • *map* in MED_attributes in nuopc.runconfig
    • remapMethod in nuopc.runseq; options are redist, bilinear (the default), patch, nearest_stod, nearest_dtos, conserve. For strict bit-for-bit reproducibility srcTermProcessing=1 and termOrder=srcseq are also required. See details here and here and this detailed explanation.
    • The remapping method used for each field is recorded in the mediator log output file: grep '^ mapping' archive/output000/log/med.log; see here for how to decode this
  • time interpolation of coupled fields
  • Processor layout - see here
    • entries in PELAYOUT_attributes section in nuopc.runconfig
    • may need to adjust max_blocks in ice_in
    • may need a mem: 192GB entry in config.yaml if you are using less than a full node
  • IO layout
    • entries in *_modelio sections in nuopc.runconfig
  • case name
    • case_name in ALLCOMP_attributes in nuopc.runconfig
  • grids
  • coupling diagnostics
  • verbosity in NUOPC log files (archive/output*/log/*.log)
    • Verbosity in attributes for model components in nuopc.runconfig; can be off, low, high, max - see here - but doesn't seems to make any difference, perhaps due to this issue.
  • calendar
  • start date
    • start_ymd in CLOCK_attributes in nuopc.runconfig;
  • run length
    • stop_n and stop_option in CLOCK_attributes in nuopc.runconfig; available units for stop_option are listed here
  • restart frequency
  • timesteps - see here
  • walltime limit
  • number of ensemble members
    • ninst in PELAYOUT_attributes in nuopc.runconfig
  • forcing data

See also

Clone this wiki locally