Minutes of the GASTON/PRISM meeting (Paris, 04/05/2001) =================================== Here is a summary of preliminary discussions we (Météo-France, IPSL, Cerfacs, UCL) had about PRISM, in the framework of our informal meetings on coupled climate modelling we have about every 6 months. Of course, these are just ideas and preliminary considerations that we would like to share and discuss with the whole PRISM community. Rendez-vous at les Diablerets! Introduction ------------ One major objective of the PRISM project in the next three years is to develop a standard interface for each possible pair of components constituting the global climate system. In PRISM, these components are defined as 1-atmosphere physics and dynamics (WP3b), 2-atmosphere chemistry (WP3c), 3-land-surface processes (WP3d), 4-ocean physics and dynamics (WP3e), 5-sea-ice dynamics and thermodynamics (WP3f), 6-ocean bio-geochemistry (WP3g) and 7-regional models (WP3h). We understod that a standard interface is: A) a standard physical interface, i.e. the nature of the information to be exchanged between two components - to be defined in WP3b-c-d-e-f-g-h for the corresponding components; B) a standard technical interface, i.e. a practical way of exchanging the information between two components - WP3a is concerned with this development. Remarks concerning the standard physical interfaces --------------------------------------------------- -In the first 6 months of the project, the standard physical interfaces could be first defined as the "ideal" and most exhaustive ones. For example, an ideal land-surface/ocean bio-geochemistry interface could include the discharge of organic matter; an ideal atmosphere/ocean interface could include the temperature of the precipitation. Intermediate interfaces corresponding to a progressive realisation of this ideal interface could then be defined, with a corresponding calendar, given the constraints of the present models. The PRISM structure would therefore allow the coupling of models answering at one point the requirements of a particular intermediate interface. -For each component (WP3b to h), the corresponding workpackage should lead to the definition and inclusion of a standard physical interface (see above) and not to the choice of one "best-suited" model. This last option would go against the multi-model approach which is fundamental in PRISM. -To be included in the PRISM structure, a model will have to include at least the PRISM technical interface to exchange its information with the other components (see below). Given this, a model should be allowed to remain a PRISM model even if the model does not conform at one point with the pre-defined standard physical interface. Of course, this would result in the impossibility of coupling this model with the other PRISM-compatible models. However, under the pressure of being able to integrate the PRISM modelling structure, the models will probably evolve "naturally" to conform with the PRISM pre-defined standard physical interfaces. -A standard physical interface should be defined at least between each possible pair of components as defined presently in PRISM. It will remain the responsability of each component workpackage (WP3b to h) to possibly define "internal" interfaces and according sub-components; for example, in the ocean component (WP3e) an internal interface could be defined between an ocean physics sub-component and an ocean dynamics sub-component. Remarks concerning the standard technical interfaces --------------------------------------------------- -The PRISM technical standard interface - or PRISM coupler- will be developed in WP3a. This technical interface will be composed of a coupling library to be included in the component models and, possibly, of additional separate coupling processes performing particular coupling tasks (interpolation, etc.). -The word "coupler" should be avoided as it is associated in the present Oasis community with a separate coupling process. Instead the words "driver", "communicator" and "interpolator" should be used when referring to each of the 3 main coupler functions: 1- The driver manages the whole coupling application (model launching, model monitoring, etc.); the driver functions can be fulfilled by one model process linked with the model coupling library or by a separate coupling process. 2- The communicator performs the coupling field send/receive operations to/from the other model components; the communication library is necessarily included in the model coupling library and in the code of separate coupling processes to exchange the coupling fields. 3- The interpolator performs the interpolation operations when required between two models having a different grid; the interpolation library could be included in the model coupling library or in in the code of separate coupling processes. -When two components are on a separate grid, the interpolator will have to perform the interpolation required to go from the source model grid to the target model grid. This could take place in the model coupling library (on the sending side or on the receiving side), or in different coupling processes (possibly parallel). -A user should be able to use the PRISM structure and the PRISM technical interface to assemble a climate model even if some of his component models used have a non-standard (but coherent) physical interface between them. -A user should be able to use the PRISM structure to assemble coupled climate model gathering only a subset of the PRISM defined components. For the missing components, the technical interface should be able to get the required information in predefined files (forcing conditions). -It seems that global climate systems likely to be assembled in PRISM will have on one hand the atmosphere, atmosphere chemistry, and land process models running on one grid, and, on the other hand, the ocean, ocean bio-geochemistry and sea-ice models on another grid. Between the models of these two groups both the communicator and the interpolator parts of the standard technical interface (and therefore most likely additional coupling processes) will be required. -If two components are on the same grid with same data decomposition and if their execution is by nature sequential, the PRISM structure could allow these two components to be two routines in one same program (one executable), and the communicator included in the model coupling library would exchange the coupling information through the memory. Other remarks ------------- -Future users of the PRISM system should be warned of the following: the PRISM structure will facilitate the technical assembling of global climate system coupled models but these coupled models will NOT be automatically validated scientifically. The scientific assessment of global coupled models assembled using the PRISM structure will remain an important user's task.