Coupling protocols – software strategy Question 1. Is it useful to create a coupling standard? YES, but … Question 2. Is the best approach to make a single coupler/coupling standard available for community collaboration? YES, but…

Q#2: A coupling standard is a good idea but it is a fast evolving standard in time (e.g. CPL7 vice ESMF)

Q#1: Key Points on / Requirements of a coupling standard: 1. Identify the split between technical and physical requirements. 2. We can standardize the technical part of the coupler, but leave the physical requirements loose, with the restriction that the physical requirements will have to meet certain requirements such as conservation. Standard will evolve over time. 3. Need a wide range of supported platforms. 4. Coupling Tools need to have a low overhead. 5. Design needs to be modular to simplify the development of the System Model. 6. Regridding support - CCSM uses LANL SCRIP to generate the weights with a sparse matrix multiply to compute the interpolation. Oasis generates weights on the fly and computes the interpolation internally. ESMF can both generate weights on the fly or use pre- computed weights and conducts the interpolation by sparse matrix multiply. 7. It is worth considering what tools are used by external groups that have models we'd want to use couple to in the future such as biology, watershed, etc. 8. Make the coupler as general, stable and solid as possible, so that its usefulness outlasts the life of the model components. The coupler is the nexus of the community.

Detailed Comments Hill: Have a hierarchy of standards - some technical and others conceptual/physical. I.e. Physical: what does the atmosphere need from the ocean. Where as the software engineering of coupling. Experience with ECCO - has both in house (MAPLE) and ESMF. Need a vision when working on a long time line. Define interfaces, but allow people to decide on everything beyond that. Don't want to lock into a standard that can't evolve as model develops. Standard shouldn't restrict the process. Maslowski: Ocean/sea ice is good example - sea ice and upper ocean can be viewed as a single layer. A standard coupling approach would get in the way of this sort of integration. Doescher: They defined an interface in terms of standard variables - an agreement of what physical variables to share. This proved too restrictive to the science groups. Instead he feels that each group should be allowed to define shared states and let the coupler reconcile the two states. Their model sends each field individually using oasis. No packing. Run concurrent. Does time stepping create bottle necks. No just add more processors. Timing information handled through meta data. Maslowski: Would Oasis meet the needs of the project. Both the technical and physical standards don't have to be meet at the same time.

Detailed Comments Coupler must not add significant over head. : Software must be portable to a wide variety of machines. Doescher: Need to create a list of technical requirements. What about remapping? CCSM uses scrip to generate the weights, Oasis can generate weights on the fly, ESMF can both generate weights on the fly or use pre-computed weights. Maslowski: Additional points in ESMF not already discussed. Cecelia: ESMF has the ability to recursively call components - used in applications such as ensemble runs. It is useful to think about the specific coupling tools adopted by external groups that may be of future interest - such as fisheries, biology, watershed, etc. : it is important to be inclusive - let the coupling standard be used to create a "community coupler model" that so that others can bring in their model. Hill: we agree that there should be a standard, exactly what is currently undefined. Requires a working group. Cecelia: put out the requirements and compare the options. Stark: make the coupler as general, stable and solid as possible, so that its usefulness outlasts the model components.

Detailed Comments : We're actually creating an Arctic System Model Framework. Maslowski: Layered way of thinking - coupler joined separate models - end goal is to create an Arctic System Model, but an ice or ocean, or atmospheric model. Difference between CCSM and ESMF design is that CCSM is hub and spoke, while ESMF allows the addition of a layered approach with a hierarchy of couplers. Maslowski: Extension needed to CPL 7 for the System model. - lateral boundary condition support - way to handle non overlapping domains Stark: coupler tools would be used to build support for these issues, rather than solve them directly. : Does ESMF handle Meta data Cecelia: Yes. A system is being built into ESG to automate code generation, as a step toward that meta data class was created.