The `input' element

If the coupling/IO field is imported through a prism_get in the component code, the user will have to describe one source for that field in the SMIOC. A more detailed description of element `input', its attributes and sub-elements is given here.

1. element `exchange_date' (mandatory) : The dates at which the coupling or I/O will effectively be performed (see `exchange_date' in `output' in section 6.5.4).

2. element `origin' (mandatory): In the current OASIS4 version, an input coupling/IO field may come only from one origin being described by an element `origin' which contains the following attributes and sub-elements:
   • attribute `transi_in_name' (mandatory) : a symbolic name defined for that specific `origin' element.

   • element `corresp_transi_out_name' (mandatory) : The symbolic name of the corresponding output coupling/IO field (attribute `transi_out_name' of element `output') in the source component or source file. This defines an exchange between a source and a target component or file. Coherence has to be ensured, i.e. the value of the current input `transi_in_name' attribute has to be specified in the `corres_transi_in_name' element of the corresponding output coupling field (see also section 6.5.4). Note that this coherence is automatically ensured when using the graphical user interface oasis-gui.tcl (available in oasis4/util/gui) for creating the SMIOC files.

   • element `file' or `component_name' (one or the other mandatory) : The source file description (I/O) or the source component `local_name' attribute (coupling). The `file' element is described in more detail in section 6.5.7.

   • element `middle_transformation' (optional): The transformations which link the source and the target.
     • element `interpolation' (mandatory): The interpolation to be performed on the output coupling field to express it on the target model grid. This element is described in more detail in section 6.5.6.

3. element `target_transformation' (optional) : The transformations performed on the input coupling/IO field in the target component PSMILe .
   • element `target_local_transformation' (optional) : The local transformations performed on the input coupling/IO field.
     • element `gathering' (optional) : The `gathering' should specified by the developer in the PMIOD and should be kept as is in the SMIOC. If `gathering' is true, it is performed on an input coupling/IO field below the prism_get by the target PSMILe . It is required when the grid information transfered to the PSMILe covers the whole grid (masked points included), and when the array transfered through prism_get API is a vector gathering only the non-masked points.

     • element `mult_scalar' (optional) : Each grid point coupling/IO field value is multiplied by the scalar specified in this element.

     • element `add_scalar' (optional) : The scalar specified in this element is added to each grid point coupling/IO field value.

       When both operations are chosen, the multiplication is performed before the addition.

   • element `target_time_operation' (optional) : Target time interpolation is supported below the prism_get only for IO data<sup>15</sup>. The types of time interpolation are the nearest neighbour `time_nneighbour' and linear time interpolation between the two closest timestamps `time_linear' in the input file.

   • element `statistics' (optional) : see section 6.5.4.

4. element `debug_mode' (optional) : either true or false; when it is true, the input coupling/IO field is automatically written to a file below the prism_get . Note that if there is a lag, the field read from the restart file is written to the prism_get debug file (but not to the prism_put debug file).

Footnotes

... data¹⁵

This feature is not essential for coupling data as each prism_put has a date and date_bounds as arguments. Therefore, a prism_put and a prism_get will be matched if the prism_get date falls into the date_bounds of the prism_put . Allowing for time interpolation, e.g. allowing a prism_get to match with an averaged value of the two prism_put nearest neighbour in time, could lead to deadlocks as the model performing the prism_get would be blocked until the two prism_put nearest neighbour in time are performed. We rely only the date_bounds to match prism_put and prism_get having non matching dates.