Emergence of a Common Modeling Architecture for Earth System Science American Geophysical Union December 13, 2010 Cecelia DeLuca NOAA/CIRES

Outline Motivation Evolution Component Interfaces Common Model Architecture National Unified Operational Prediction Capability Creating and Using a Structured Information Layer Summary

Motivation Climate and other Earth system models include significant non- scientific and utility infrastructure Shared standards-based infrastructure development enables: – Ability of multiple groups to contribute to coupled systems – Reuse of software to promote efficient use of resources – A technical culture that can emphasize best practices and can be less isolating than the “scientist’s programmer” – Software with features, testing, and documentation that exceeds in scope and quality what a single institution can produce time software infrastructure capability best available institutional/proprietary capability best available community capability

Community Modeling Infrastructure Projects Earth System Modeling Framework – climate and weather model coupling ( OASIS Coupler/Programme for Integrated Earth System Modeling (PRISM) – climate model coupling ( Earth System Grid – distribution of climate model output ( Climate and Forecast Conventions – metadata conventions for data ( METAFOR Common Information Model for climate models – metadata conventions for climate model metadata ( Earth System Curator – climate model workflows ( Note: 1) not exhaustive and 2) major advances since 2000!

Evolution of ESMF Phase 1: NASA’s Earth Science Technology Office ran a solicitation to develop an Earth System Modeling Framework (ESMF). A multi-agency collaboration won the award. The team included developers of major institutional tools and frameworks (from GFDL, Goddard, NCAR, Los Alamos, MIT, …) The core development team was located at NCAR. A prototype ESMF software package (version 2r) demonstrated feasibility. Phase 2: New sponsors included Department of Defense and NOAA. Many new applications and requirements were brought into the project, motivating a complete redesign of framework data structures (version 3r). Phase 3: The core development team moved to NOAA for closer alignment with federal models. Basic framework development will be complete with version 5r (ports, bugs, feature requests, user support etc. still require resources). The focus is on increasing adoption and creating a community of interoperable codes.

Standard Component Interfaces All ESMF components have the same three standard methods: – Initialize – Run – Finalize Each standard method has the same simple interface: These interfaces are wrappers, and can often be set up in a non-intrusive way call ESMF_GridCompRun (myComp, importState, exportState, clock, …) Where: myComp points to the component importState is a structure containing input fields exportState is a structure containing output fields clock contains timestepping information Steps to adopting ESMF Divide the application into components (without ESMF) Copy or reference component input and output data into ESMF data structures Register components with ESMF Set up ESMF couplers for data exchange

A Common Model Architecture Increasingly, models in the U.S. follow a common architecture Atmosphere, ocean, sea ice, land, and/or wave models are components called by a top- level driver/coupler Components use ESMF or ESMF-like interfaces (see left) Many major U.S. weather and climate models either follow this architecture (CCSM/CESM, COAMPS, NEMS), want to follow this architecture for future coupled systems (NOGAPS), or have a different style of driver but could provide components to this architecture (GEOS-5, FMS) Even non-ESMF codes now look like ESMF … ESMF: ESMF_GridCompRun(gridcomp, importState, exportState, clock, phase, blockingFlag, rc) CESM (non-ESMF version): atm_run_mct(clock, gridcomp, importState, exportState) (argument names changed to show equivalence) WRF HYCOM CICE Ice POP Ocean CCSM4/CESM NMM-B Atm PhysNMM-B Atm Dynamics NEMS NMM History GFS Atm PhysGFS Atm Dynamics GFS GFS I/O FV Cub Sph Dycore GEOS-5 GWDGEOS-5 FV Dycore GEOS-5 Atm Dynamics GEOS-5 GSI GEOS-5 Moist Proc GEOS-5 Turbulence GEOS-5 LW RadGEOS-5 Solar Rad GEOS-5 Radiation GEOS-5 Aeros Chem GOCART Strat Chem Param Chem GEOS-5 Atm Chem GEOS-5 Ocean Biogeo GEOS-5 Salt Water Poseidon GEOS-5 Data Ocean GEOS-5 OGCM GEOS-5 Topology GEOS-5 Land Ice GEOS-5 Lake GEOS-5 Veg Dyn GEOS-5 Catchment GEOS-5 Land GEOS-5 Surface GEOS-5 Atm Physics GEOS-5 Hiistory ESMF Model Components 2010 NOAA Department of Defense University NASA Department of Energy National Science Foundation ESMF coupling complete Component (thin lines) Model (thick lines) Legend Ovals show ESMF components and models that are at the working prototype level or beyond. Tracer Advection CLM LandCAM Atm FIM Land Info System HAF GAIM MOM4 SWAN ADCIRCpWASH123 COAMPS WWIII NCOM NOGAPS

A Common Model Architecture The U.S. Earth system modeling community is converging on a common modeling architecture Atmosphere, ocean, sea ice, land, wave, and other models are ESMF or ESMF- like components called by a top-level driver or coupler Some models are modularizing further with nested components A Common Model Architecture

Common Model Architecture in Climate Metadata CMIP5 metadata display in Earth System Grid, developed by the Earth System Curator project in collaboration with E.U. METAFOR

From Common Model Architecture to Interoperability ESMF component interfaces alone do not guarantee technical interoperability – ESMF can be implemented in multiple ways Also need: – A common physical architecture – the scope and relationships of physical components (e.g. land surface as subroutine or component?) – Metadata conventions and usage conventions (e.g. who can modify component data?) – The next steps for modeling infrastructure involve encoding these conventions in software tools and templates

National Unified Operational Prediction Capability National Unified Operational Prediction Capability (NUOPC) is a consortium of operation weather prediction centers Developing a standard implementation of ESMF across NASA, NOAA, Navy, Air Force and other modeling applications Defining a target level of interoperability involving multiple aspects of code – EXAMPLES: Component interface. Components have a standard calling interface to facilitate generic drivers and communication protocols. Standardization does not include specification of what specific fields are actually in the import and export state. Timekeeping. Metadata and conventions for timekeeping enable modelers to understand without code inspection whether components can be coupled together. From: Final Report from the National Unified Operational Prediction Capability (NUOPC) Interim Committee on Common Model Architecture (CMA), June 18, 2009.

Applications of information layer Building an Information and Interoperability Layer Native model data structures Standard data structures Standard metadata Parallel generation and application of interpolation weights Run-time compliance checking of metadata and time behavior Fast parallel I/O Redistribution and other parallel communications Automated documentation of models and simulations (new) Ability to run components in workflows and as web services (new) Field Grid Clock Component Attributes: CF conventions, ISO standards, METAFOR Common Information Model Structured model information stored in ESMF wrappers User data is referenced or copied into ESMF structures modules fields grids timekeeping ESMF data structures

Summary U.S. models are converging on a common model architecture It is built on standardized component interfaces wrapped around user code This architecture creates a layer of structured information in Earth system codes This structured information can be accessed for many functions – To support interoperability, through efforts like NUOPC – As a building block for self-documentation of models, automated compliance checking, and other advanced capabilities – To learn more … the ESMF town hall meeting is Wednesday from 12:30-1:30 in Moscone West Room 2007