1. Options for Framework Connectivity Cecelia DeLuca NOAA Environmental Software Infrastructure and Interoperability http://www.esrl.noaa.gov/nesii/ February 20, 2013 CW2013

2. Why Connect Frameworks?* Because different communities have developed their own frameworks, and modeling efforts often need to span communities Because different frameworks can have different scope, functions, and strengths Because framework combinations can result in greater capability Because people and organizations like to build their own stuff if they can, but they also need to work together * Using the word framework in the loosest possible sense

3. Approaches Functional Split External Specification Cross-Registration Wrapping Co-Development

4. Functional Split Framework A does something (say, matrix multiplication). Framework B does something else (say, generation of interpolation weights). Both can be used in the same model code. Pro: Easy! Everyone’s happy! Con: Not possible or desirable to get this level of modularity for some functions. Con: Multiple dependencies can make code harder to build, harder to port, require more people management.

5. External Specification Set up user code to run in one or more frameworks, without requiring the user to interact with the frameworks. Includes generative approaches (e.g. BFG, Cupid) and required model control functions such as the Basic Model Interface. Pro: Excellent for students, non-techies, and simpler codes (likely other cases too, but these seem most obvious). Con: May not be able to take advantage of all features of an advanced framework, including performance optimizations.

6. Cross-Registration Frameworks that register components and “set services”, such as ESMF and CSDMS, may be able to cross- register at the level of the virtual function table Pro: Can be a direct, high-performance connection. Con: May be tricky to implement; only possible for classic component architectures.

7. Wrapping Wrap one framework’s interface around another, either referencing or copying data arrays. Pro: Usually possible, somehow. Pro: Enables the same component code to support interaction with multiple frameworks and communities. Con: Performance can be affected. Con: The implementation can be bulky or unnatural.

8. Co-Development Combine efforts to build a common tool or framework Pro: Shared investment, good karma Con: Not always easy to find opportunities

9. What to do? As usual, there is no right approach for all cases. However, the following seem like good ideas: Provide coupling capabilities as modular tools to encourage functional splits and co-development Establish standard translators to move between frameworks, rather than ad-hoc approaches Assess the limits of external specification, and utilize it wherever possible From discussion after the talk: identify and recommend code structures (e.g. IRF) likely to make working with any tool easier