External Observatory Integration:

1. External Observatory Integration: • Christopher Mueller • Life Cycle Objectives Review • La Jolla, CA

2. Agenda • Background/History • Subsystem Purpose • Release 1 Product Description Use Case Overview • Architectural Overview • Status of Progress • Use Cases Address, Use Cases Demonstrated • Technology Challenges and Achievements • Plan for Elaboration • Significant Risks

3. NOAA Port GTS Background / History Navy/NASA/Other Model output OOI-CI & IOOS-DMAC Intersection Development Project-FY2010 *Improve the process by which researchers get data to drive models Unidata Or NDBC 1A OOI-CI Process Apply CF conventions 2A THREDDS Catalog CDM 5 DAP & CF IDD LDM PULL 1 2 PULL 3 NDBC: Observing System Monitoring Center (OSMC) 4 Researcher’s Process NetCDF Java Library NCO & User Scripts Matlab (test CDM) Model Analysis CI-DMAC_project_20100128.doc

4. External Observatory Integration Subsystem: Purpose The External Observatory Integration (EOI) subsystem: • integrates external observatories (i.e. IOOS) with the OOI Integrated Observatory • facilitates inclusion of external data • delivers data in community specific forms • allows immediate full scale testing of the OOI-CI System • introduces OOI to a community of early adopters

5. Release 1 Product Description Use Case Overview EOI provides support for a number of the R1 Use Cases: • Hello Data Source – Data source is registered and connected • Ingest and Describe Data – Externally provided data read and distributed • Merge Data – Provide data unified from many sources • Present as Catalog – present organized set of resources externally • Put to External Repository – Send data to repository outside the system • Version A Resource – Resource is supplanted by changed version

6. Architectural Overview • EOI exists under the auspices of an Instrument within the OOI-CI System • It is responsible for translating data between external forms and the internal OOI-CI canonical form OOI Marine Observatory External Observatory Realized Operational Specification IOOS WMO Neptune CA Platform Instrument http://www.oceanobservatories.org/spaces/display/syseng/CIAD+OV+04+External+Interfaces

7. Status of Progress • Established the Rutgers modeling team as the initial scientific “client” • Started developing interaction patterns between OOI-CI, IOOS, & Scientists • Compiled lists of data sources, outputs and workflows required by the Rutgers modeling team

8. Status of Progress (cont.) Current Status of Rutgers Data Sources • Data Types: • SSH, Forcing, Salinity, Temperature, Rivers • Providers: • PFEG, Rutgers, NAVY, USGS, RADS, NCEP, AOML • Acquisition Forms: • NetCDF, ASCII • Acquisition Protocols: • OPeNDAP, curl, wget, urlread • Prospective CDM Types: • Grid, Station, Trajectory, Profile

9. Technology Challenges and Achievements • Achievements: • functional prototypes of NetCDF  DAP translation in both JAVA & Python • Challenges: • compatibility of DAP libraries in Java and Python

10. Plan for Elaboration • Continue to work with selected scientific modeling groups • Register each data source as a Provider in the OOI-CI System • Translation/transformation to achieve CDM/CF compliance • Leverage IOOS data sources wherever possible • Work with scientists to utilize the OOI-CI System for acquiring data • Provide client with a tool for OOI-CI syndication notifications

11. Significant Risks • IOOS Interoperability • Establish liaisons with IOOS integrator • Initiate collaborations with IOOS • Start IOOS integration activity as an EOI • Model Integration Strategy • Early and ongoing involvement of modeling community in design process • Early prototyping of data sharing between models and control of ensembles of models

12. Thanks ! Questions ?