130 likes | 139 Views
Learn about the emergence and adoption of a standardized architecture for Earth System Science models, enhancing collaboration and efficiency among different groups and institutions. Follow the development phases and standard component interfaces to create an interoperable community of models.
E N D
Emergence of a Common Modeling Architecture for Earth System ScienceAmerican Geophysical UnionDecember 13, 2010Cecelia DeLucaNOAA/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 software infrastructure capability best available community capability best available institutional/proprietary capability time 2010 2000
Community Modeling Infrastructure Projects • 2002 - Earth System Modeling Framework – climate and weather model coupling (http:///www.earthsystemmodeling.org) • 2000 - OASIS Coupler/Programme for Integrated Earth System Modeling (PRISM) – climate model coupling (http://www.cerfacs.fr) • 2000 - Earth System Grid – distribution of climate model output (http://wwwearthsystemgrid.org) • 1995 - Climate and Forecast Conventions – metadata conventions for data (http://cf-pcmdi.llnl.gov/) • 2005 - METAFOR Common Information Model for climate models – metadata conventions for climate model metadata (http://metaforclimate.eu) • 2005 - Earth System Curator – climate model workflows (http://earthsystemcurator.org) Note: 1) not exhaustive and 2) major advances since 2000!
Evolution of ESMF • Phase 1: 2002-2005 • 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: 2005-2010 • 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: 2010-2015 • 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 • 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 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
GFS GFS Atm Phys GFS Atm Dynamics GFS I/O NEMS NMM-B Atm Dynamics NMM-B Atm Phys NMM History GEOS-5 Radiation GEOS-5 LW Rad GEOS-5 Solar Rad GEOS-5 Land GEOS-5 Veg Dyn GEOS-5 Catchment GEOS-5 OGCM Poseidon GEOS-5 Data Ocean GEOS-5 Salt Water GEOS-5 Ocean Biogeo ESMF Model Components 2010 Legend Ovals show ESMF components and models that are at the working prototype level orbeyond. A Common Model Architecture NOAA Department of Defense University NASA Department of Energy National Science Foundation ESMF coupling complete Component (thin lines) Model (thick lines) CCSM4/CESM POP Ocean CICE Ice CLM Land CAM Atm FIM • 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) HYCOM NOGAPS Strat Chem Param Chem GEOS-5 WRF GEOS-5 Atm Dynamics GOCART GEOS-5 GWD GEOS-5 FV Dycore FV Cub Sph Dycore Tracer Advection Land Info System GSI GEOS-5 Atm Physics GEOS-5 Hiistory GEOS-5 Atm Chem GEOS-5 Aeros Chem GEOS-5 Surface 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) GEOS-5 Topology GEOS-5 Moist Proc GEOS-5 Lake GEOS-5 Turbulence GEOS-5 Land Ice HAF GAIM MOM4 WWIII COAMPS SWAN pWASH123 ADCIRC NCOM
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 inClimate Metadata CMIP5 metadata display in Earth System Grid, developed by theEarth 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.
Building an Information andInteroperability Layer • 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) Applications of information layer Structured model information stored in ESMF wrappers Attributes: CF conventions, ISO standards, METAFOR Common Information Model Standard metadata ESMF data structures Standard data structures Component Field Grid Clock User data is referenced or copied into ESMF structures Native model data structures modules grids timekeeping fields
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