Presented By: Walter Wolf 1 , Tim Mavor 1,2 , and Qingzhao Guo 3 1 NOAA/NESDIS/STAR

1. GOES-R AWG Ocean Dynamics Team Critical Design Review: Ocean Currents and Ocean Currents: OffshoreMarch 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

2. 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

3. Introduction Presented byWalter Wolf AWG Integration Team Lead NOAA/NESDIS/STAR

4. Project Stakeholders NOAA/CoastWatch NOAA/NOS NOAA/NODC NCEP/OMB NOAA/NESDIS/GhostNet Physical Oceanographic Community Academia 4

5. 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

6. Project Plan • Tasks • Resource Identification • Schedule (Milestones)

7. 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.

8. Project Plan – Resource Identification • Once the proposal was accepted by AWG, resources were identified • SOW was developed • WBS was implemented • Tasks 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.

9. Project Plan – Schedule Milestones for both Products • Schedule (Milestones) • OD Kickoff Meeting – 12/28/06 • Proposal for OD Product Team – 01/12/07 • Algorithm Design Review - 09/10/08 • Critical Design Review – 03/25/09 • Test Readiness Review - 01/11/10 • Covers the software for the 80% delivery • Code Unit Test Review - 09/30/10 • System Readiness Review - 06/24/11 • Covers the software for the 100% delivery

10. Implementation of Ocean Dynamics Product Schedule • Version 1 delivery to the GSP (10/01/07– 09/30/10) • Algorithm Development (10/01/07 – 02/08/10) • Draft ATBD Delivery (09/30/08) • Algorithm Demonstration (09/04/08 – 01/11/10) • Algorithm Documentation (04/01/08 – 02/02/10) • Collaboration with AIT (08/30/10 – 09/30/10) • 80% ATBD Algorithm Package Delivery (09/30/10) • Version 2 delivery to the GSP (02/09/10 – 09/30/11) • Algorithm Development, Testing and Demonstration (02/09/10 – 06/24/11) • Algorithm Documentation (12/01/10 – 06/23/11) • Collaboration with AIT (08/30/11 – 09/30/11) • 100% ATBD Algorithm Package Delivery (09/30/11)

11. 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

12. Algorithm Design Review Reports and Actions Presented by: Tim Mavor

13. 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

14. 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

15. Algorithm Theoretical Basis Presented by Tim Mavor 15

16. 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

17. 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 17

18. Algorithm Theoretical Basis Ocean Currents: OffshorePresented byTim Mavor Task Lead/GOES-R AWG Ocean Dynamics Algorithm Team NOAA/NESDIS/STAR IMSG, Inc.

19. Ocean Currents: OffshoreAlgorithm Theoretical Basis • Purpose: Provide product developers, reviewers and users with a theoretical description (scientific and mathematical) of the GOES-R ABI Ocean Currents: Offshore algorithm • Documented in the GOES-R ABI Ocean Currents: Offshore Algorithm Theoretical Basis Document (ATBD)

20. Requirements Changes Since ADR – Currents: Offshore FD – FullDisk C - CONUS

21. ADR Risks and Actions Reported:Ocean Currents: Offshore Proposed Changes to F&PS • Ocean Currents: Offshore • Drop distinction between “Currents” and “Currents: Offshore” • Rejected • Include Direction Accuracy/Precision of 45 Degrees • Stratify Direction Accuracy/Precision by Ocean Current Speed • Ocean Fronts: Offshore 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

22. ADR Algorithm • At ADR, decision was made in regards to the following algorithm components of the Ocean Currents: Offshore • Utilize algorithm output from Ocean Currents • Mask will be created, as described by F & PS • US Exclusive Economic Zone and CONUS waters • Pre-calculated Input File • Offshore evaluation for every GOES-R pixel

23. Algorithm Theoretical Basis Ocean CurrentsPresented byTim Mavor Task Lead/GOES-R AWG Ocean Dynamics Algorithm Team NOAA/NESDIS/STAR IMSG, Inc.

24. Ocean CurrentsAlgorithm Theoretical Basis • Purpose: Provide product developers, reviewers and users with a theoretical description (scientific and mathematical) of the GOES-R ABI Ocean Currents algorithm • Documented in the GOES-R ABI Ocean Currents Products Algorithm Theoretical Basis Document (ATBD)

25. Requirements Changes Since ADR – Currents FD – FullDisk M - Mesoscale

26. ADR Risks and Actions Reported:Ocean Dynamics Proposed Changes to F&PS • Ocean currents • Drop distinction between “Currents” and “Currents: Offshore” • Rejected • 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

27. ADR Algorithm • At ADR, consideration was given to the following algorithm components of the ocean surface currents: • Deriving Ocean Surface Fronts • At the ADR, one algorithm was chosen and presented. • Target Selection • At the ADR, only one algorithm for target selection • Feature Tracking • Two algorithms were presented: • Sum of Squared Differences (SSD) • Cross correlation • Product Quality Flag Assignment • At the ADR, only one algorithm for Quality Flag

28. 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 targeting 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 • Product Quality Flag Assignment • Adopt existing/proven Quality Indicator as used in wind vector and other ocean vector applications

29. CDR Algorithm • Ocean Surface Fronts: • Advantages • Heritage algorithm used operationally for GOES SST fronts • Works on variety of input • Sea surface temperature • Brightness temperatures • Simple output file @ pixel level • 0 is no front, 1 is front • Quick processing time • Disadvantages • Dependent on Cloud Mask • Difficulty in finding fronts during summer in tropics • Seasonal Thermocline • Rationale for selection • Satisfies goal to find ocean surface fronts as distinct separation between water masses. • Proven operationally valid and used operationally. • Quick processing time

30. CDR Algorithm • Target Selection • Advantages • Heritage in GOES Winds • Similar targeting algorithm to GOES-R Atmospheric Motion Vector • Disadvantages • Target scene effects Tracking Algorithm • Decrease scene size improves speed bias but degrades RMS • Rationale for 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 • Simple and configurable

31. CDR Algorithm • Feature Tracking: Sum-of-Squared Differences (SSD) algorithm • Advantages • Heritage algorithm for GOES winds • Similar algorithm to GOES-R Atmospheric Motion Vector • Computationally quick • Disadvantages • The use of shorter time intervals requires higher spatial resolution imagery in order to resolve the motion • Consideration must be given to the proper mix of spatial and temporal resolution for the derivation of satellite ocean current estimates • Never applied to ocean surface data

32. CDR Algorithm • Feature Tracking: Maximum Cross-Correlation (MCC) algorithm • Advantages • Standard statistical technique for target matching • Developed and tested with polar-orbiting IR-based SST • Few requirements on the image sequence • Disadvantages • May not correctly produce accurate vectors along isolines • For lower contrast areas, the quality of vectors is reduced • Not invariant to eddy rotation or changes in eddy size

33. CDR Algorithm • Rationale for selection • Sum-of-Squared Differences • The Sum-of-Squared Differences (SSD) algorithm is a proven approach that is used operationally today for GOES, MODIS, and AVHRR winds • Possible to combine/leverage with GOES-R AMV code • Good performance in areas of lower contrast • Computationally quicker than MCC

34. CDR Algorithm • Product Quality Flag Assignment • Advantages • Assigns a quality indicator to every ocean current vector • Already used operationally by satellite wind producers • Familiarity by user community that already use wind vectors • Simple to implement • Disadvantages • Additional output field • Additional processing time • Rationale for selection • Anticipates user community need • Output files not imposingly large • Processing time not onerous nor impediment to meeting MRD

35. 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

36. Ocean Dynamics Algorithm Processing Outline 36 36

37. Ocean Dynamics AlgorithmInput: Sensor Input GOES-R ABI Ocean Surface current product also requires image data from each sequential image at each pixel: 37 37 37 37 Present Input Possible Added Input

38. Ocean Dynamics AlgorithmSensor Input Details For each pixel at present time step: Calibrated/Navigated ABI brightness temperatures Geolocation in Latitude/Longitude Time of Image ABI sensor quality flags 38 38 38 38 Present Input Possible Added Input

39. Ocean Dynamics AlgorithmSensor Input Details For each pixel at previous time step Calibrated/Navigated ABI brightness temperatures Geolocation in Latitude/Longitude Time of Image ABI sensor quality flags 39 39 39 39 Present Input Possible Added Input

40. Ocean Dynamics AlgorithmSensor Input Details For each pixel at following time step Calibrated/Navigated ABI brightness temperatures Geolocation in Latitude/Longitude Time of Image ABI sensor quality flags 40 40 40 40 Present Input Possible Added Input

41. Ocean Dynamics AlgorithmAncillary Input Ancillary data needed: ABI-specific Dynamic Data: Sea Surface Temperature, Cloud Mask. Non-ABI Dynamic Data: None ABI-specific Static Data: None Non-ABI Static Data: Land/Sea Mask US EEZ and CONUS Mask (Offshore only) 41 41 41 41

42. Ocean Dynamics Algorithm Ancillary Dynamic Input • Ocean Dynamics Algorithm Dynamic ABI Input Data

43. Ocean Dynamics Algorithm Ancillary Static Input Non-ABI Static Data: • Land/Sea Mask • Offshore Mask (only for Currents Offshore)

44. Ocean Dynamics Algorithm Output • Metadata • Processing time/date stamp & Others • Intermediate Dataset: Ocean Surface Fronts • Scientific Datasets • For Currents: Offshore, similar output fields 44 44 44 44

45. 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. • Typical time-scales of days, versus hours for the atmosphere. • The choice of spectral band, fronts or SST will be determined based on optimized output. • For the spectral bands or SST, the input data may be a “snapshot” of a particular time, or temporal average based on several hours worth of data. • SST fronts are operationally derived from a daily-averaged SST. • Assumption: Oceanographic features are conservative, passive tracers of the ocean surface • 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

46. Physical Description:Ocean Surface Front Detection • Objective of the front detection process is to have scenes that: • Contain sufficient contrast • Allowing connecting of adjacent frontal pixels to form frontal boundaries • Are sufficiently cloud masked to have confidence that frontal boundaries are ocean surface features • Scenes that do not possess these characteristics will provide erroneous ocean surface front detections. • Erroneous fronts may provide invalid input into feature tracking, thereby effecting the quality of the Ocean Surface Vector.

47. Physical Description:Ocean Surface Front Detection Ocean Fronts overlaying corresponding SST field

48. Physical Description:Target Selection • Objective of the target selection process is to select high quality target scenes that: • Contain sufficient contrast • Are stable over time interval in question • Targets that do not possess these characteristics can be difficult to track • Result: Poor quality ocean surface vector estimates • Targets are selected from the middle image of the image triplet

49. Physical Description:Target Selection: Choice (1/4) • Sea Surface Temperature • Justifications for Use: • Strong operational heritage of NESDIS and other operational satellite SST • Compliments ocean surface fronts algorithm • Easily understood by user-community GOES-11 5km Sea Surface Temperature

50. Physical Description:Target Selection: Choice (2/4) • SST Fronts • Justifications for Use: • Operational heritage of NESDIS and other operational satellite SST • Provides additional information for feature tracking. • Only frontal displacements need to be tracked • Smaller compressed filesize GOES-11 5km SST Fronts (overlayed on SST Field)