Main differences

• OASIS3-MCT is (only) a coupling library

  Much of the underlying implementation of OASIS3 was refactored to leverage the Model Coupling Toolkit (MCT). OASIS3-MCT is a coupling library to be linked to the component models and that carries out the coupling field transformations (e.g. remappings/interpolations) in parallel on either the source or target processes and that performs all communication in parallel directly between the component models; there is no central coupler executable anymore¹³.

• The new OASIS3-MCT_3.0 version supports coupling exchanges between components deployed in much more diverse configurations than before. All details are provided in section 2.1.

• Support to couple multiple fields via a single communication.

  This is supported through colon delimited field lists in the namcouple, for example

  ATMTAUX:ATMTAUY:ATMHFLUX TAUX:TAUY:HEATFLUX 1 3600 3 rstrt.nc EXPORTED

  in a single namcouple entry. All fields will use the namcouple settings for that entry. In the component model codes, these fields are still sent (``put'') or received (``get'') one at a time. Inside OASIS3-MCT, the fields are stored and a single mapping and send or receive instruction is executed for all fields. This is useful in cases where multiple fields have the same coupling transformations and to reduce communication costs by aggregating multiple fields into a single communication. If a LOCTRAN transformation is needed for these multiple fields, it is necessary to define a restart file for these multiple fields.

• Matching one source filed with multiple targets

  A coupling field sent by a source component model can be associated with more than one target field and model (get). In that case, the source model needs to send (``put'') the field only once and the corresponding data will arrive at multiple targets as specified in the namcouple configuration file. Different coupling frequencies and transformations are allowed for different coupling exchanges of the same field. If coupling restart files are required (either if a LAG or if a LOCTRANS transformation is specified), it is mandatory to specify different files for the different fields.

  The inverse feature is not allowed, i.e. a single target (get) field CANNOT be associated with multiple source (put) fields.

• MAPPING transformation to use a pre-defined mapping file

  With MAPPING, OASIS3-MCT has the ability to read a predefined set of weights and addresses (mapping file) specified in the namcouple to perform the interpolation/remapping. The user also has the flexibility to choose the location and the parallelization strategy of the remapping with specific MAPPING options (see section 4.3).

• Mono-process mapping file generation with the SCRIP library

  But as before, OASIS3-MCT can also generate the mapping file using the SCRIP library (Jones 1999). When this is the case, the mapping file generation is done on one process of the model components.

• Support of BICUBIC interpolation, see paragraph BICUBIB in section 4.3. If the source grid is not a gaussian reduced grid (D), the gradient in the first dimension, the gradient in the second dimension, and the cross-gradient of the coupling field must be calculated by the model and given as arguments to oasis_put, as explained in section 2.2.7. If the source grid is a gaussian reduced grid (D), OASIS3-MCT can calculate the interpolated field using only the values of the source field points.

• Support of CONSERV/SECOND regridding, see paragraph CONSERV/SECOND in section 4.3.

• Exact restart for LOCTRANS transformations

  If needed, LOCTRANS transformations write partially transformed fields in the coupling restart file at the end of a run to ensure an exact restart of the next run (see section 4.1). For that reason, coupling restart filenames are now required for all namcouple entries that use LOCTRANS (with non INSTANT values), This is the reason an optional restart file is now provided on the OUTPUT namcouple input line (see section 3.3.2). If the coupling periods of two (or more) coupling fields are different, it is necessary to define two (or more) restart files, one for each field.

• Support of components exchanging data on only a subdomain of the global grid: a new optional argument, ig_size was added to oasis_def_partition, that provides the user with the ability to define the total number of grid cells on the grid (see section 2.2.3).

• A variable TIMER_Debug controlling the amount of time statistics written out is an optional argument read in the namcouple; see the NLOGPRT line in 3.2 and all details about time statistics in section 6.4.2.

• The debug files: The debug mode was greatly improved as compared to OASIS3.3. The level of debug information written out to the OASIS3-MCT debug files for each model process is defined by the $NLOGPRT value in the namcouple. All details are provided in section 3.2.

• If a component model tries to send with oasis_put or to receive with oasis_get a field declared with a oasis_def_var but not defined in the configuration file namcouple, this will now lead to an abort. In this case, the field ID returned by the oasis_def_var is equal to -1 and the corresponding oasis_put or oasis_get should not be called. Conversely, all coupling fields appearing in the namcouple must be defined with a call to oasis_def_var; this constraint is imposed to avoid that a typo in the namcouple would lead to coupling exchanges not corresponding to what the user intends to activate.

• OASIS3-MCT developments are continuously tested and validated on different computers with a test suite under Buildbot, which is a software written in Python to automate compile and test cycles required in software project (see https://inle.cerfacs.fr/projects/oasis3-mct/wiki/Buildbot on the Redmine site).

• MPI2 job launching is NOT supported.

  Only MPI1 start mode is allowed. As before with the MPI1 mode, all component models must be started by the user in the job script in a pseudo-MPMD mode; in this case, they will automatically share the same MPI_COMM_WORLD communicator and an internal communicator created by OASIS3-MCT needs to be used for internal parallelization (see section 2.2.2).

• IGNORED and IGNOUT fields are converted to EXPORTED and EXPOUT respectively.

• The file areas.nc is not needed anymore to calculate some statistics with options CHECKIN and/or CHECKOUT (see section 4.2).

• SEQ index is no longer needed to ensure correct coupling sequencing within the coupler. Use of SEQ allows the coupling layer to detect potential deadlocks before they happen and to exit gracefully (see section 2.3.2).

• The I/O library mpp_io is no longer used to write the restart and output files.

Footnotes

... anymore¹³

As with OASIS3.3, the ``put'' calls are non-blocking but the ``get'' calls are blocking. As before, the user has to take care of implementing a coupling algorithm that will result in matching ``put'' and ``get'' calls to avoid deadlocks (see section 2.2.7). The lag (LAG) index works as before in OASIS3.3 (see section 2.3)