60 likes | 261 Views
Overview of SPURS and the Archival Role of PODAAC. Vardis Tsontos , Andrew Bingham PODAAC NASA/JPL. PODAAC UWG Meeting Raytheon, Pasadena, CA 3/7/2012. 1 /4. The SPURS Project: “Salinity Processes in Upper Ocean Regiona l Study”. http:// spurs.jpl.nasa.gov. Motivation: Aquarius/SAC-D.
E N D
Overview of SPURS and the Archival Role of PODAAC VardisTsontos, Andrew Bingham PODAAC NASA/JPL PODAAC UWG Meeting Raytheon, Pasadena, CA 3/7/2012 1/4
The SPURS Project: “Salinity Processes in Upper Ocean Regional Study” http://spurs.jpl.nasa.gov Motivation: Aquarius/SAC-D • NASA Funded field campaign • Process study: mechanisms controlling upper ocean salinity • Study Area: North Atlantic, Salinity Max Region (approx. N20) • Timing: Aug. 2012 – Oct. 2013 • Fieldwork: 5 Cruises (Pirata, Knorr, Midas, 2x Endeavor) • Collaborators: - Inter-Agency (NASA, NOAA, WHOI, UW, Columbia, UHi, RSS) - International (Fr/Sp) • 18 Activities: Observing Systems, Analysis/Modeling, Data Management/Outreach • Sampling: - Range (novel) platforms & instruments: “Sensor-Web” - Multi-scale, Adaptive approach... • Products: - Data: In situ (PIs), satellite observations (PO.DAAC), 3D ROMS model outputs (JPL) - Value-added: Web-based mapping application, project website (data catalog, outreach tools) 2/4
Archival of the SPURS Legacy (1/2) Beyond the Project Lifetime • SPURS Archival Goals(our synthesis & understanding) • Insure Long-term archival and access to all (QA/QC’d) SPURS datasets (in situ, model, satellite ) • Insure the coherence of the project data (discoverable & extractable as logical entity) • Preserve project products serving as the memory of the project (value-added data, information & tools) • UWG 2011 Recommendation • “Recommendation 12. PO.DAAC should not absorb the responsibility of archiving and managing SPURS field program in situ data. PO.DAAC should work with experienced in situ data partners to ensure the proper linkages are in place and users clearly understand the shared responsibilities” • Archival Request • PO.DAAC should provide short-term (10yr) archive for SPURS. NODC should be the long-term archive of raw (low-level) data. PO.DAAC should focus on value-added products (Lindstrom, Oct. 2011 - as communicated by Bingham) • Proposed Archival Concept & Roles • Option 1 (initial) • - NODC should be the long-term archive of raw (low-level) data.- PO.DAAC should provide short-term (10yr) archive for SPURS, and focus on value-added project products (eg. improved metadata, readable, packaging of data) • Option 2 (current) • - NODC should be the long-term archive of all in situ datasets.- PO.DAAC should: serve as the long-term archive for SPURS satellite and model datasets provide short-term archival of value-added SPURS products on a best-effort basis 3/4
Archival of the SPURS Legacy (2/2) Beyond the Project Lifetime • Key Considerations/Constraints • No file and metadata standards requirement imposed by SPURS on PIs (only recommendations) • SPURS unsure NODC can deliver coherent access to in situ data -> suggested enhanced role for PO.DAAC • PO.DAAC: • Metadata & data file standardscritical for our discovery/integration/services • Metadata model currently not geared towards in situdata -> may need to extend DMAS • Maintenance of SPURS mapping application developed externally • Resource implications: development effort, personnel, hardware • Current Status & Next Steps • SPURS & NODC: • - complete project dataset description forms/MOU • - evaluate new NODC in situ .nc data file templates • PO.DAAC: • Commit to support SPURS archival efforts on a “Best-effort” basis, working closely with both SPURS & NODC • Develop file-naming convention for SPURS (minimal standards requirement) • Underlying Policy Questions for UWG • Guidance on precise role of PO.DAAC in supporting archival of SPURS data & value-added products • Potential future role for PO.DAAC serving as archive for NASA field campaign data more generally?(opportunity? SPURS as a pilot study?) 4/4
BACKUP SLIDES (1/2)Ancillary Information • SPURS Sampling Platforms & Sensors by Project Activity • - Near surface salinity gradients: Surface Salinity Profiler (towed CTD chain 0.5-2m) • Horizontal surface T/S advection & eddy fluxes: 174 Drifters SSS & current velocity • SPURS Mooring: surface Met/Radiation Package,<5m CDT HR-currents,0-90m CTD/ADCP chain • Multi-scale Upper ocean salinity characterization: AUVs & Wave Gliders • Sustained Observations: XBT transects, profiling floats, TSG, Pirate Mooring, CTD casts & underway, drifters • Aquarius: synergies on intermediate scales • Thalassa Cruise (FR), Jul.2012 & Midas Cruise (SP), Mar.2013: Drifters, CTD, ADCP, underway sensors, SEASOR, ASIP profiler • Profiling floats: CTD, Wind, Rain • 3 Gliders: 2x 6mo deployments, 200x200km2 area, upper 1000m : CTD, U • 2 microstructure gliders: 20 and 50 km areas • Upper ocean profiling & drifts with Floats: CTD, Pressure, Radiation, Ambient Noise • Data assimilation & Multi-scale circulation modeling support: • Situation awareness: OSSE’s & now/forecasts, analysis of upper ocean salinity processes
SPURS Information Management SystemProject Lifetime (+ 6 Months) • Data Management Team: Fred Bingham, UNC (principal) & Yi Chao, RSS • Components: • SPURS Website: http://spurs.jpl.nasa.gov: • Project/meeting information, Collaboration & Outreach tools (calendar, forum, cruise blog) , Data Portal (catalog & visualization tool) • Datasets & Access: • - In situ observations (PI provider links; Argo/AOML system … ) • - 3D ROMS Circulation model outputs (JPL) • - Satellite Observations (PODAAC): Aquarius SSS, … • Visualization Tools & Database: • -Web-based Google Earth Application: dynamic map overlays, point metadata and data summary plots • -MySQL backend Relational Database: subset of observations and pointers to imagery/plots • - Supports “situational awareness” objective (not intended as a comprehensive project data management system) • Data Management & Archival Challenges: In situ datasets • - Diverse, structurally heterogeneous • - Range data formats (NC, ASCII) • - Metadata: dataset level, file level, contextual • - Issue of standards & metadata needs: no requirement imposed on PIs, only recommendations • => Determines extent data discovery, subsetting, integration and Web-service access possible during both the project & archival phases