The meeting took place in CERFACS in Toulouse. The participants were: from NEC-CCRL, Rene Redler; from NEC Deutschland, Thomas Schoenemeyer; from SGI Deutschland, Reiner Vogelsang; from FECIT/Fujitsu, Jean Latour and Arnaud Caubel; from CERFACS, Damien Declat and Sophie Valcke; from MPI/M&D,  Stephanie Legutke; from IPSL: Jan Polcher and Marie-Alice Foujols.

The following points were discussed:

• Some details on the coupled model high level architecture
• XML-F90 interface issue
• WP4a  proposal for the PSMILe interface
• First suggestion for the Transformer and Driver flow charts.

Some details on the coupled model high level architecture

First, the definition of some technical terms were reviewed:

• PMIOD: Potential Model Input and Output Description
• SMIOC: Specific Model Input and Output Configuration
• SCC: Specific Coupling Configuration
• Transient input and output variables: data evolving during the run, received or provided at run-time by the model at an a priori unknown frequency, from or to an external entity (another model -coupling variables, or a disk file -I/O variables).
• Restart variables: data requested initially by the model to (re)start the simulation and provided previously by the model itself (not by an external entity). These data are saved to disk at regular intervals during each run.
• Persistent input parameters: data requested initially by the model to define the physical configuration of the experiment. These parameters may have default values but may be adapted by the user. For coupled models, the "universal parameters" are parameters that require a consistent definition among all the model components.

From the discussions, it now emerges that both WP4a and WP3a agree that there is no reason to treat restart variables differently from transient input and output variables. The restart characteristic could just be indicated as an additional metadata in the PMIOD.

The Transformer will never read/write directly a transient input/output variable in/to a disk file. Pseudo-model performing the I/O will have to be written for transient input or ouput I/O variables requiring transformation(s) to be performed by the Transformer. These I/O variables will therefore become coupling variables exchanged between pseudo-models and "real" models, and will be treated as such. Like a "real" model, each pseudo-model will come with its PMIOD.

The only case for which the Transfomer will perform directly an I/O is to read a field that  will  be combined with a standard coupling field.

All information about coupling variables will be in the SCC; all information about I/O variables  will be in the SMIOC.

For coupling variables, the list of transformations will be listed in the SCC by the user. Non-local transformation will necessarily be performed by the Transformer. Local transformations can be performed in the PSMILe or by the Transformer; for each simulation, the Driver will decide where they will be performed, based on efficiency criteria.

In debug mode (specified by the user in the SCC), it should be possible to dump the coupling variables just before leaving the source model or  the Transformer and just after entering the target model or the Transformer.

The information on the "universal parameters" will in all cases be specified in the SCC. In stand-alone mode, the PSMILe will automatically read the information in the SCC. In non stand-alone mode, the PSMILe will automatically request the information from the Driver. One universal parameter is the initial date of the simulation. Another universal parameter is the initial date of the run, as one simulation may have to be split into many runs to fit the limits of the job queuing system. The PRISM System developed in WP4b will automatically chain the different runs and will automatically, for each run, change the value of the initial date of the run in the SCC.

 XML-F90 interface issue was then discussed. Everyone now tend to agree that the choice of XML for the PMIOD, SMIOC and SCC is a good one as:

• one advantage is that some logic can be applied between the different element of an XML file (for example, if one element is the total number of coupling fields = n, it can be automatically verified that n coupling fields are effectively described -this is not the case today with the namcouple and it is a source of bugs)
• the XML format is still understandable with a standard editor like vi (and even more with emacs as an emacs xml style exists)
• a C library for reading a XML file exists, libxml.c
• cfortran.h is a standard and portable way to interface C and Fortran (even for character strings).

The WP4a/IPSL proposal for the PSMILe interface was then reviewed. The WP3a and WP4a proposals are fundamentally not very different although many aspects are not treated the same way. The most important differences reside in the definition of  the variable grids and masks. Another difference is the amount of metadata passed through the interface: this amount is more important in IPSL proposal as they advocate for more automatic coherence checks. Finally, WP4a/IPSL proposal supposes the use of optional arguments, which is not favored by WP3a approach.

It was decided that WP3a will thoroughly comment WP4a/IPSL proposal and will present this new proposal as soon as possible. The objective is to come to a common WP3a-WP4a PSMILe interface description sometimes in June.

First suggestion for the Transformer and Driver flow charts.

A first suggestion for the flow charts for the Transformer and the Driver (tasks T9 and T10) was then presented by Damien Declat. The revised version of these flow charts is available at http://www.cerfacs.fr/~valcke/PRISM/INTERPOLATION/WP3a_transformer.ppt.

The basic principle is that the Transformer and the Driver are independent entities that establish persistent communication with the models. During the run, the Transformer and the Driver loop over their persistent channels and react to signals sent by the models. Each signal is composed of a control packet (a set of integers) that gives indication to the Driver or Transformer on the next action requested by the model.

Similar flow charts should be produced before July 1st for the different PSMILe routines (tasks T7 and T8).