390 likes | 562 Views
GOES-R AWG Ocean Dynamics Team Critical Design Review: Surface Ocean Currents March 25, 2009. Presented By: Walter Wolf 1 , Tim Mavor 1,2 , and Qingzhao Guo 3 1 NOAA/NESDIS/STAR 2 IM Systems Groups 3 Perot System Government Services. Outline. Introduction ADR Report and Actions
E N D
GOES-R AWG Ocean Dynamics Team Critical Design Review: Surface Ocean CurrentsMarch 25, 2009 Presented By: Walter Wolf1, Tim Mavor1,2, and Qingzhao Guo3 1 NOAA/NESDIS/STAR 2 IM Systems Groups 3 Perot System Government Services
Outline • Introduction • ADR Report and Actions • Requirements • Implementation Concept • Algorithm Theoretical Basis • Software Architecture and Interfaces • Design Overview and System Description • Algorithm Package • Quality Assurance • Requirements Allocation • Risks • Actions • Summary and Conclusions
Introduction Presented byWalter Wolf AWG Integration Team Lead NOAA/NESDIS/STAR
The AWG Ocean Dynamics Team Members AWG Ocean Dynamics Team Chair: Tim Mavor • Tim Mavor • Ocean Dynamics Team (NESDIS/STAR) • Ocean Surface Fronts • Ocean Surface Currents • Validation Support – OSTIA & other SST Analyses • Programming • Documentation • Bob Daniels • Invested Stakeholder(NCEP/OPC) • Ocean Surface Fronts • Ocean Surface Currents • Validation Support – RTOFS and Navy Gulf Stream Product • Other Contributors/Stakeholders • Ken Casey – NODC • Jaime Daniels – GOES-R Winds AWG • Qingzhao Guo – AIT • Sasha Ignatov – GOES-R SST AWG • Bill Pichel – GhostNet • John Sapper – OSDPD • Dave Foley • Invested Stakeholder(CoastWatch) • Ocean Surface Fronts • Heritage GOES Front Distribution • User Interface
Project Stakeholders NOAA/CoastWatch (Kent Hughes) NOAA/NOS (Doug Pirhalla) NOAA/NODC (Ken Casey) NCEP/OMB (Real Time Ocean Forecasting System) NOAA/GhostNet (Bill Pichel) Physical Oceanographic Community Academia 5
Project Plan • Tasks • Resource Identification • Schedule (Milestones)
Project Plan – Tasks • Tasks are defined via the agreement between the AWG and the GSP • AWG kickoff meeting was held on December 28, 2006 • Personnel were identified for the Ocean Dynamics Team tasks • Materials required for development were identified • Budget was determined by proposal from members of the Ocean Dynamics Team to the AWG Management Team.
Project Plan – Resource Identification • Once the proposal was accepted by AWG, resources were identified • SOW was developed • WBS was implemented • Task were assigned to the stakeholders • Proposals are submitted to the AWG by the Ocean Dynamics Team members on a yearly basis. • The status of each product development task is presented at the AWG yearly meeting • Each task is evaluated and assessed on a yearly basis.
Project Plan – Schedule Milestones for both Products • Schedule (Milestones) • OD Kickoff Meeting – 12/28/06 • Proposal for OD Product Team – ??/??/?? • Algorithm Design Review - 09/10/08 • Critical Design Review – 03/25/09 • Test Readiness Review - 04/24/09 • Covers the software for the 80% delivery • Code Unit Test Review - 03/17/10 • System Readiness Review - 08/27/10 • Covers the software for the 100% delivery
Implementation of Ocean Dynamics Product Schedule • Version 1 delivery to the GSP (07/03/06– 09/30/09) • Algorithm Development (07/03/06 – 05/12/09) • Draft ATBD Delivery (09/30/08) • Algorithm Demonstration (11/17/08 – 01/12/09) • Algorithm Documentation (02/01/08 – 05/29/09) • Collaboration with AIT (05/29/09 – 09/30/09) • 80% ATBD Algorithm Package Delivery (09/30/09) • Version 2 delivery to the GSP (10/01/09 – 09/24/10) • Algorithm Development, Testing and Demonstration (10/01/09 – 08/30/10) • Algorithm Documentation (11/02/09 – 07/01/10) • Collaboration with AIT (08/30/10 – 09/30/10) • 100% ATBD Algorithm Package Delivery (09/30/10)
Algorithm Design Review Reports and Actions Presented by: Tim Mavor
Requirements Flowdown Level 1 Requirements Document Mission Requirements Document GOES-R Ground Segment Project Plan Algorithm Development Management Plan Functional and Performance Specification Ground Requirements for AWG Algorithm Development
Outline • Introduction • ADR Report and Actions • Requirements • Implementation Concept • Algorithm Theoretical Basis • Software Architecture and Interfaces • Design Overview and System Description • Algorithm Package • Quality Assurance • Requirements Allocation • Risks • Actions • Summary and Conclusions
ADR Risks and Actions Reported:Ocean Dynamcis Proposed Changes to F&PS • Ocean currents • Drop distinction between “Currents” and “Currents: Offshore” • Include Direction Accuracy/Precision of 45 Degrees • Stratify Direction Accuracy/Precision by Ocean Current Speed • Ocean fronts from ABI • Legacy operational GOES-R product with no F&PS requirements • Potential Intermediate Product from Ocean Current Algorithm • Coverage: Full Disk (T), Hemispheric (G) • Surface Product • Horizontal Resolution: 4km (T), 2km (G) • Mapping Accuracy: 4km (T), 2km (G) • Measurement Range: Binary (yes/no) • Refresh Rate: 6hr (T), 1hr (G) • Data Latency: 60 min after SST (T), 15 min after SST (G) • Have provided Julie McNeil with F&PS, MRD and LIRD feedback
Algorithm Theoretical Basis Ocean Surface CurrentsPresented byTim Mavor Ocean Dynamics Application Team Chair NOAA/NESDIS/STAR IMSG, Inc.
Algorithm Theoretical Basis Outline Introduction Observing System Overview Product Generated Instrument Characteristics Algorithm Description Algorithm Overview Processing Outline Algorithm Input Theoretical Description Test Data Sets and Outputs Simulated/Proxy Input Data Sets Output from Simulated/Proxy Data Sets Error Budget 16
Algorithm Theoretical Basis • Purpose: Provide product developers, reviewers and users with a theoretical description (scientific and mathematical) of the GOES-R Ocean Dynamics algorithm • Will be documented in the ATBD of GOES-R ABI Ocean Dynamics Products
Development Strategy • Study of Various Ocean Currents/Fronts Algorithms • Ocean Fronts • Legacy Algorithm • Utilize GOES-R ABI features • Ocean Surface Currents • Evaluate Candidate Algorithms • Maximum Cross Correlation • Sum of Squared Differences (AMV) • Dependencies • SST AWG • Cloud Mask • Navigation • Simulation Study • Accuracy • Sensitivity • Timeliness • Testing and Validation 18
Testing and Validation • SST Analyses Data • OSTIA • Reynolds • RTG • RTOFS • Also Ocean Surface Currents for Validation • ABI Proxy Data • MSG SEVIRI Data • Best ABI proxy in terms of spectral and temporal feature. • Large amount of collections, easily accessible data • Current GOES Imager Data • Ground Measurements • CODAR • OSCAR • Drifting Buoys 19
Ocean DynamicsAlgorithmAncillary Input Ancillary data needed: ABI-specific Dynamic Data: Sea Surface Temperature, Cloud Mask. Non-ABI Dynamic Data: None ABI-specific Static Data: Land Mask. Non-ABI Static Data: None. 21 21 21 21
Ocean Dynamics Algorithm Ancillary Dynamic Input • Ocean Dynamics Algorithm Dynamic ABI Input Data
Ocean Dynamics AlgorithmInput: Sensor Input 23 23 23 23
Ocean Dynamics AlgorithmInput: Sensor Input GOES-R ABI Ocean Surface current product also requires image data from the previous time step each pixel: 24 24 24 24
Ocean Dynamics AlgorithmInput: Sensor Input GOES-R ABI Ocean Surface Current product also requires image data from the next time step each pixel: 25 25 25 25
Ocean Dynamics AlgorithmInput Sensor Input Details For each block Calibrated/Navigated ABI brightness temperatures Latitude/Longitude ABI sensor quality flags 26 26 26 26
Ocean Surface Currents InputSensor Input Details: Previous Time Step
Ocean Surface Currents InputSensor Input Details: Next Time Step
Ocean Dynamics Algorithm Output • Metadata • Processing date stamp & Others • Intermediate Dataset: Ocean Surface Fronts • Scientific Datasets 30 30 30 30
Algorithm Theoretical Basis Outline • Practical Considerations • Numerical Computation Considerations • Programming and Procedural Considerations • Quality Assessment and Diagnosis • Exception Handling • Algorithm Validation • Assumptions and Limitations • Performance • Assumed Sensor Performance • Pre-Planned Improvements • References
ADR Algorithm At ADR, consideration was given to the following algorithm components of the ocean surface currents: • Deriving Ocean Surface Fronts • Target Selection • Feature Tracking
ADR Algorithm At ADR, consideration was given to the following algorithm components of the ocean surface currents: • Ocean Surface Fronts • Adopt existing/proven algorithms used operationally today for GOES SST fronts • Target Selection • Adopt existing/proven tracking algorithms used operationally today for GOES, MODIS, and AVHRR winds • Feature Tracking • Adopt existing/proven tracking algorithms used operationally today for GOES, MODIS, and AVHRR winds • Sum of Squared Differences (SSD) • Cross correlation
CDR Algorithm • Rationale for selection: Ocean Surface Fronts • Proven approach that is used operationally today for GOES SST fronts • Goal is to find fronts which are identifiable as distinct separation between water masses.
CDR Algorithm • Rationale for selection: Target Selection • Proven approach that is used operationally today for GOES, MODIS, and AVHRR winds • Goal is to find high quality targets that can be tracked in time and can be reliably assigned heights • Simple and configurable
CDR Algorithm • Rationale for selection: Feature Tracking • The Sum-of-Squared Differences (SSD) algorithm is a proven approach that is used operationally today for GOES, MODIS, and AVHRR winds • Used operationally by many other satellite wind producers • Good performance • Computationally quick
Implementation of Ocean DynamicsTeam Internal Deliveries • Three internal deliveries to the AIT from the Ocean Dynamics Team for the 80% delivery to the GSP: • Delivery 1 – An algorithm that works • Delivery 2 – An algorithm that runs off proxy or simulated ABI data and conforms to the variable naming convention • Delivery 3 – Software meets the STAR coding standards and 80% of the product accuracy • Two internal deliveries to the AIT by the Ocean Dynamics Team for the 100% delivery: • Delivery 4 – Verification that the algorithm may be run and the timing is close to the latency requirement • Delivery 5 – Algorithm is complete
Algorithm Objectives • Meet the F&PS requirements for ocean surface currents. • Generate intermediate ocean surface fronts product to continue operation heritage. • Generate and append quality indicators to ocean surface current products. • Provide needed performance information to allow for proper use of our products. • Computationally efficient
Physical Description:Estimating Ocean Surface Motion • Oceanic motion is determined through the tracking of features in time. • Features can be eddies, fronts and other oceanographic features. • The choice of spectral band, fronts or SST will determine the intended target. • Assumption: Oceanographic features are conservative, passive tracers of the wind field • A reasonable assumption in many instances that results in feature tracking solutions that serve as a good proxy to the velocity field. • Diurnal heating in many areas make such assumptions weak during summer months. • Quality control important