Global Hydro-Estimator CDR

Global Hydro-Estimator CDR

Global Hydro-Estimator Satellite Rainfall Estimates Critical Design Review September 9, 2011 Prepared By: Limin Zhao2, Bob Kuligowski1, Clay Davenport3, and Walter Wolf1 NOAA/NESDIS/STAR 2 NOAA/NESDIS/OSPO 3 SSAI 1 1 Review Agenda

Introduction 1:00 pm 1:20 pm Risks 1:20 pm 1:30 pm Requirements 1:30 pm 1:50 pm Operations Concept

1:50 pm 2:05 pm Algorithm Theoretical Basis 2:05 pm 3:05 pm Break 3:05 pm 3:15 pm Software Architecture and Interfaces 3:15 pm 4:00 pm Quality Assurance 4:00 pm 4:15 pm Risks and Actions 4:15 pm 4:25 pm Summary and Conclusions 4:25 pm 4:30 pm 2 Outline

Introduction Zhao Risks Wolf Requirements Wolf Operations Concept Zhao Algorithm Theoretical Basis Kuligowski Software Architecture &Interfaces Davenport

Quality Assurance Wolf Risks and Actions Wolf Summary and Conclusions Zhao 3 Introduction Presented by Limin Zhao 4 Introduction Project Background Current Operational System Current Offline Global System

Project Objectives Project Stakeholders Project Plan Project Risk Management 5 Background The H-E has been the operational CONUS algorithm at NESDIS since 2002 The H-E retrieves instantaneous rain rates from IR brightness temperatures (TBs) and uses numerical weather model data to account for subcloud effects Fields of PW, RH and 700 hPa winds plus T and q profiles from a numerical model, such as, NCEP Global Forecast System (GFS), and a Digital Elevation Model (DEM) for the orographic modifications For each routine scan, IR TBs are read, ancillary data are read and processed, algorithm is applied to the TBs with adjustments based

on ancillary data, generated output is converted to several formats, output is sent to server for distribution 6 Requirements 1010-0019, Global Hydro-Estimator Satellite Rainfall Estimates. Transition global Hydro-Estimator from STAR to OSPO to replace current CONUS HydroEstimator. 1006-0009, Making Multi-day (more than 24hrs) NESDIS Hydro-Estimator Rain Estimates Operationally Make 2-7 day HE totals for the CONUS. 9712-8, Implement Graphical Auto-Estimator on AWIPS. The original request for automated satellite products at NESDIS, which led to the Auto-Estimator and Hydro-Estimator over the CONUS. 7

Background The Hydro-Estimator has been run in real-time at STAR since 2005. The CONUS Hydro-Estimator algorithm is applied to data from GOES-E and W, METEOSAT-7 and -9, and MTSAT1, using NAM data for the adjustments where available and GFS data elsewhere. The instantaneous rates are aggregated into 1-h totals, for each sector, and the resulting sectors are then mosaicked into a global 1-h total that is converted to ASCII and served via ftp. All satellite and model data are obtained from OSPO servers via ADDE. 8 Background -- Satellites Central Satellite and

Wavelength Sub-satellite Longitude Band Wavelength Scan Frequency sensor Range (m)m)m) IGFOV (m)km) (m)m)m) GOES-11 135W CONUS: 15 min Imager 4 10.20-11.20 10.7 4 NH: 30 min

GOES-13 SH: 30 min or 3 h 75W Imager METEOSAT-9 0E 9 10.28-11.28 10.8 3 FD: 15 min SEVIRI METEOSAT-7 57.5E 3 10.5-12.5 11.5 5

FD: 30 min MVRI MTSAT-1R NH: 30 min 140E IR1 10.3-11.3 10.8 4 Imager SH: 60 min 9 GHE Objectives Provide global Rainfall Rates within 50 minutes of observation (or 20 minutes of data receipt) to NWS, the Hydrologic Research Center, and

NESDIS: Rainfall Rates derived from GOES-East , GOESWest, METEOSAT-7, METEOSAT-9, MTSAT-1R Product Quality Flags Metadata Diagnostics Retire the operational CONUS-only HE and feed NWS CONUS-HE from the global HE 10 Capabilities & Impacts The Global Flash Flood Guidance (m)GFFG) system, which is the result of collaboration among NOAA, the Hydrologic Research Center (m)HRC), and the WMO, relies on the HydroEstimator rainfall estimate to drive the GFFG, which is currently providing real-time flash flood guidance for Central America and the Mekong Delta and will soon provide guidance for southern Africa and the Black Sea region.

The STAR H-E global product meets this need, but with the continual risk of outages at crucial times. This risk can be resolved only by operational implementation of the global H-E at OSPO. 11 Project Stakeholders Customers and Users Users: Dan Beardsley (m)NWS) Liqun Ma (m)SPB) Sheldon Kusselson (m)SAB) Konstantine Georgakakos, Bob Jubach (m)HRC) 12 Project Stakeholders

Operations and Maintenance OSPO Products Area Lead Limin Zhao OSPO QA Lead Zhaohui Cheng Operational Implementation and Maintenance Team Clay Davenport William Pennoyer Jessica Staude Science Maintenance Team Bob Kuligowski Zhihua Zhang 13 Project Stakeholders Development Team STAR (m)Bob Kuligowski, Clay Davenport,

Peter Keehn, Yi Song) 14 Project Plan Stakeholder Involvement Development Team Operation and Maintenance

Coding and documentation Quality assurance Data verification and validation Configuration Management Code Acceptance Running system Interface with operations Monitoring Distribution

Customers and/or Users Supply customer request Review project development Archive data Communicate with development team 15 HE Project: Organization Chart Customers/Users HE Project

NWS, SPB, SAB, HRC, STAR,CLASS Limin Zhao (PI) Bob Kuligowski (Backup) Development Team Operations Team Bob Kuligowski & Walter Wolf Limin Zhao (Lead) Research Algorithm Bob Kuligowski (Lead) Clay Davenport (Scientist/Programmer)

Pre-Operational Algorithm Support Walter Wolf (Lead) Peter Keehn (Programmer) Yi Song (Programmer) Kexin Zhang (QA Lead) Yunhui Zhao (CM) Larisa Koval (Documentation) Zhaohui Cheng (QA Lead) Clay Davenport (Ops Development) William Pennoyer (Ops Primary) Jessica Staude (Ops Backup)

16 Project Plan: Task and Schedules Tasks: Defined in FY11_Geo_Global_Hydro_Estimator_V4.ppt (SPSRB PSDI) Schedule (key milestones): Preliminary Design Review Aug 3, 2011 (Combined with CDR) Critical Design Review Aug 3, 2011 (m)slides available)

Software Review Oct 31, 2011 System Readiness Review Jan 2012 (TBR) SPSRB Briefing Feb 2012 Operations Commence Mar 2012 17 GHE Project Timeline: Algorithm Development PDR Waived CDR 08/16/11 SRR 01/16/12

18 GHE Project Timeline: Compressed Algorithm Development 19 GHE Project Risk Management Risk Management Process: Identify

Analyze Plan Track Control Risk Reduction: GOES Heritage System Offline Global System Communication Documentation Project risks will be identified in the risks section and risk mitigation plans and actions will also be

addressed. 20 GHE CDR Entry Criteria Risks and Actions Review of Global GHE CDR Operations Concept Requirements Algorithm Theoretical Basis Software Architecture and Interfaces

Quality Assurance New Risks and Actions 21 GHE Team CDR Exit Criteria Critical Design Review Report The CDR Report (CDRR), a standard artifact of the STAR Enterprise Process Lifecycle (EPL), will be compiled after the CDR The report will contain: Actions Comments CDR presentation 22 Review Objectives

Review the project plan Review the operations concept Review the requirements Review the algorithm theoretical basis Review the software system architecture and interfaces Review the plans for quality assurance Review the requirements allocation Review risks and actions 23 Review Agenda

Introduction Zhao Risks Wolf Requirements Wolf Operations Concept Zhao Algorithm Theoretical Basis Kuligowski Software Architecture and Interfaces Davenport Quality Assurance Wolf Risks and Actions

Wolf Summary and Conclusions Zhao 24 CDR Review Report and Actions Presented by Walter Wolf 25 GHE Pre-CDR Reports and Actions Open Pre-CDR Risks and Actions 26 Pre-CDR Risks and

Actions 27 Pre-CDR Risks and Actions For GHE Pre-CDR Risk 1: PDR was waived. Going straight to CDR. Risk Assessment: Medium Impact: If the overall project information is not provided at the CDR then the project will fall behind schedule increasing costs Likelihood: Medium Mitigation: Identify the project tasks and address them within the CDR Status: Closed

28 Pre-CDR Risks and Actions For HE Pre-CDR Risk 2: Possible loss of Meteosat data Risk Assessment: Low Impact: If Meteosat data is lost, then there will not be complete global coverage for the GHE rainfall products Likelihood: Low Mitigation: Work with NESDIS managements to ensure that Meteosat data is readily available Status: Open 29

Pre-CDR Risks and Actions For GHE Pre-CDR Risk 3: Compressed schedule due to funding needing to be spent by 09/30/11 Risk Assessment: Medium Impact: If the tasks are not completed, then the system will not be transitioned to operations Likelihood: High Mitigation: Add more staff on the STAR and OSPO side to complete the transition tasks before 09/30/11 Status: Open 30 Pre-CDR Risks and Actions For GHE

Pre-CDR Risk 4: Uncertainty in availability of any funds unspent by 09/30/11 Risk Assessment: Medium Impact: Project may not be completed if not all funds are available Likelihood: High Mitigation: Work with NWS to extend leftover funding into FY12 Status: Open 31 Outline

Introduction Zhao Risks Wolf Requirements Wolf Operations Concept Zhao Algorithm Theoretical Basis Kuligowski Software Architecture &Interfaces Davenport Quality Assurance

Wolf Risks and Actions Wolf Summary and Conclusions Zhao 32 Global HydroEstimator Requirements Presented by Walter Wolf 33 GHE Requirements Product name Geograph ic

Coverage Horizont al Resoluti on Mapping Uncertai nty Measure ment Range Measurement Precision

Measurem ent Accuracy Latency Refresh Rate Instantaneous rainfall rate , 1hour, 3-hour, 6hour, 24-hour and multi-day rainfall accumulations Global from 60S to 60N

4 km 4 km 0 ~ 76 mm/h 6 mm/h at rates of 10 mm/h, with higher values at higher rates 6 mm/h at rates of 10 mm/h, with higher values at

higher rates 20 min 20 min 34 Project Requirements Have Been Established Established for Critical Design Review (m)CDR) Critical Design Review Report (CDRR this presentation) Requirements Allocation Document (m)RAD) v1r0 35

Requirements Allocation Document Requirements Allocation Document (m)RAD) v1r0 RAD v1r0 is a CDR artifact. Contains the basic and derived requirements for the work products Contains the allocation of the requirements to system components and product components 36 GHE Requirements Basic Requirement 0.0 Basic Requirement 0.0 - The GHE project shall adopt the standard practices of the STAR Enterprise Product

Lifecycle (EPL), as established in the STAR EPL process assets v2.0. (process) 37 GHE Requirements Basic Requirement 1.0 Basic Requirement 1.0: Integrated Product Team (IPT) shall generate real-time estimates of rainfall at the full IR pixel scale for the entire globe. (product, functional) User request: (1010-0019, Global Hydro-Estimator Satellite Rainfall Estimates). Derived Requirement 1.1:The Global Hydro-Estimator algorithm shall be applied to data from GOES-11 and GOES 13, METEOSAT-7 and -9, and MTSAT-1R geosynchronous satellites, using GFS model data for the adjustments for the effects of moisture availability, evaporation, orographic

modulation, and thermodynamic profile effects. 38 GHE Requirements Basic Requirement 1.0 Derived Requirement 1.1: The Global HydroEstimator algorithm shall be applied to data from GOES-11 and GOES13, METEOSAT-7 and -9, and MTSAT-1R geosynchronous satellites, using GFS model data for the adjustments for the effects of moisture availability, evaporation, orographic modulation, and thermodynamic profile effects. Derived Requirement 1.1.1:All satellite and model data shall be obtained from OSPO servers via ADDE. 39 GHE Requirements Basic Requirement 2.0

Basic Requirement 2.0:The rainfall products shall include: (1) instantaneous rainfall rate and 1-hour rain rate over global; (2)1-hour, 3-hour, and 6-hour rainfall estimate, daily rainfall estimate, 2-day rainfall estimate, 3-day rainfall estimate, 4-day rainfall estimate, 5-day rainfall estimate, 6-day rainfall estimate and 7-day rainfall estimate over CONUS. User requests: (1010-0019, Global Hydro-Estimator Satellite Rainfall Estimates; 1006-0009, Making Multiday (more than 24hrs) NESDIS Hydro-Estimator Rain Estimated Operationally). 40 GHE Requirements Basic Requirement 3.0 Basic Requirement 3.0: Global Rainfall Rates shall be generated and distributed within 50 minutes of

observation (or 20 minutes of data receipt) to NWS, the Hydrologic Research Center, and NESDIS users. (product) 41 GHE Requirements Basic Requirement 4.0 Basic Requirement 4.0: The rainfall products shall be in netCDF4/McIDAS formats. 42 GHE Requirements Basic Requirement 5.0 Basic Requirement 5.0: The rainfall products

retrieval quality shall be indicated with a set of quality control flags. 43 GHE Requirements Basic Requirement 6.0 Basic Requirement 6.0: The Integrated Product Team shall define Metadata for each rainfall product. 44 GHE Requirements Basic Requirement 7.0

Basic Requirement 7.0: The Integrated Product Team shall perform validation and verification of the GHE products. Derived Requirement 7.1: GHE products shall be validated by comparing retrieved instantaneous rainfall rates with Tropical Rainfall Measuring Mission (TRMM) spaceborne Precipitation Radar (PR) between 35S and 35N. Derived Requirement 7.2: The IPT shall verify that the GHE products in the output files are generated correctly and documented. 45 GHE Requirements Basic Requirement 8.0 Basic Requirement 8.0:The GHE software shall be delivered to the OSPO team for testing and operational implementation.

46 GHE Requirements Basic Requirement 9.0 Basic Requirement 9.0:The global Hydro-Estimator Rainfall products (netCDF4) and corresponding metadata shall be archived at NCDC/CLASS (TBD) Derived Requirement 9.1: Distribution of the Archive Products to NCDC/CLASS shall be in accordance with a Data Submission Agreement (DSA). 47 GHE Requirements Basic Requirement 10.0 Basic Requirement 10.0: The GHE shall maintain heritage with operational CONUS Hydro-Estimator

and ensure continuity /consistency. Derived Requirement 10.1: The global Hydro-Estimator shall be integrated the current operational HE-SPE, and take it as its sub-system. Derived Requirement 10.2: The global Hydro-Estimator shall have the capability to provide hourly rainfall estimate in GRIB format to NWS. 48 GHE Requirements Summary The Global Hydro-Estimator Requirements have been established. The Global Hydro-Estimator Requirements have been documented in the Requirements Allocation Document (RAD). The Global Hydro-Estimator Requirements are traceable to drivers (customer needs or

expectations) and other requirements. 49 Outline Introduction Zhao Risks Wolf

Requirements Wolf Operations Concept Zhao Algorithm Theoretical Basis Kuligowski Software Architecture &Interfaces Davenport Quality Assurance Wolf Risks and Actions Wolf Summary and Conclusions Zhao 50 Operations Concept Presented by Limin Zhao

NOAA/NESDIS/OSPO 51 Operations Concept Overview Identify intentions of the customers/users of the products Review the concept of operations that the customers/users has documented in the SPSRB user request Interact with customers/users to produce an initial algorithm theoretical basis that is consistent with their concept of operations Review the answers to the following questions based on customer/user needs and expectations and production constraints What is the product?

Why is this product being produced? How will this product be used? How should this product be produced (operational scenario)? The operations concept will be refined by the GHE IPT, in consultation with customers/users, as the product solution and design are matured through the design development phase. 52 GHE Rainfall Products Customers GHE requirements originate from NWS through the SPSRB user request Customers General product types More specific product specifications will require an interactive dialog with the customers when identified.

The U.S. customers are identified as the only requirements driver for products in the global Hydro-Estimator Rainfall Products Requirement Allocation. NWS Hydrological Research Center (HRC) NESDIS/SAB NCDC/CLASS Potential International Customers China Meteorological Administration (CMA) 53 What is the Product?

The global Hydro-Estimator rainfall estimate utilizes IR brightness temperatures to identify regions of rainfall and retrieve rainfall rate, then uses GFS model fields to adjust the rainfall rate for the effects of moisture availability, evaporation, orographic modulation, and thermodynamic profile effects. The rainfall products include: Global: instantaneous rainfall rate and 1-hour rainfall rate CONUS: instantaneous rainfall rate and 1-hour, 3-hour, and 6-hour rainfall estimate, daily rainfall, 2-day, 3-day, 4-day, 5-day, 6-day and 7-day rainfall estimate.

The products will also include observation time, data quality flags, and other metadata information. Parameters Specifications Environmental parameter Instantaneous rainfall rate , 1-hour, 3-hour, 6-hour, 24-hour and multi-day rainfall accumulations Geographical Coverage Global from 60S to 60N Horizontal Resolution/grid spacing

4 km Mapping Uncertainty 4 km Measurement Range 0 ~ 76 mm/h Measurement Precision 9 mm/h at rates of 10 mm/h, with higher values at higher rates Measurement Accuracy 6 mm/h at rates of 10 mm/h, with higher values at higher rates

Latency 20 mins Refresh 20 mins 54 Why Are The Products Being Produced? Current operational HE products cover only over CONUS and surrounding waters Users need the operational capability for Hydro-Estimator rainfall estimate over the entire globe equator-ward of 60 degrees

The products are now only available from research and support under the best effort at STAR, so users is under consistent threat of outages (potentially at critical times) not being addressed in a timely fashion. 55 How Will The Products Be Used? The global HE products are currently used for supporting the OCONUS flash flood forecasting operations (GFFG Global Flash Flood Guidance) HRC users will switch the data access from STAR to OSPO after the products are made operational available 56

How Should The Products Be Produced? (1/6) Satellite Data for Product Generation GOES-W&-E GWR (McIDAS AREA) Meteosat-7 & -9 (McIDAS AREA) MTSAT-1 (McIDAS AREA) Ancillary Data for Product Generation NCEP GFS Model data (GRIB2 converted to McIDAS) Global Terrain Maps (McIDAS Area) Lookup Tables for Viewing Angle Corrections (McIDAS Area) Ancillary Data for Product Validation Radar (netCDF) CPC Daily Rainfall from gauge (GRIB2) 57

How Should The Products Be Produced? (2/6) There will be three distinct environments Development Environment (STAR and OSPO) Development and testing of pre-operational codes on Redhat Linux OS Test environment (ESPC) Pre-operational code (DAP) received from STAR will be tested on the designated Red Hat Linux machine at ESPC and modified as needed before it is promoted to operation Operation Environment (ESPC) Operational DAP will be run to generate the products on the designated Redhat Linux machine at ESPC and the products will be distributed to user through ESPC distribution system (DDS) 58

How Should The Products Be Produced? (3/6) Operational Global HE Products Coverage Global (60S 60 N) Formats netCDF4 McIDAS AREA Latency 20 mins Products Instantaneous rain rate, 1-hour, 3-hour, 6-hour, 24-hour rainfall accumulation, and multi-day rainfall accumulations 59

How Should The Products Be Produced? (4/6) Production and Delivery Scenarios The ESPC Ingest Systems will handle all input satellite data and ancillary data The global HE product system will collect the satellite inputs and required ancillary data to run the HE algorithm The product will be generated in McIDAS AREA and converted into netCDF4 for archive purpose The product users will be granted access to the ESPC distribution system through the data access request submission process. ESPC will handle the distribution of the global and CONUS HE products 60 How Should The Products Be Produced? (5/6)

Production Monitoring and Maintenance Scenarios The product process will be monitored by ESPC and email alerts will be generated when an error occurs The global HE algorithm will provide overall quality control flags and quality summary level information ESPC will cover the monitoring of input data latency, product latency, and product distribution Offline Statistic comparison with radar and gauge data will be generated for product quality validation The Precipitation PAL and maintenance personnel at OSPO will monitor the product quality and will coordinate with the STAR scientists for any product quality issues 61 How Should The Products Be Produced? (6/6) Production Archival Scenarios Current, no formal archive requirement is identified in the user request for

global HE product The CONUS HE is archived at NCAR, and will eventually need be transitioned into NCDC. The IPT will take initiative to discuss with users and CLASS for the possibility of archiving the HE products with NCDC/CLASS The global Hydro-Estimator rainfall product (netCDF4) and corresponding metadata can be archived at NCDC/CLASS The product and metadata can be delivered to NCDC/CLASS by ESPC distribution system Distribution of the Archive Product to NCDC/CLASS can be in accordance with a Data Submission Agreement (DSA) A Request to Archive global Hydro-Estimator Rainfall product can be submitted to NCDC/CLASS 62 CDR Risks and Actions CDR Risk 1: Lack of capability for product quality statistic

and trend monitoring of the GHE algorithm -- not fully scoped in the current project plan Risk Assessment: Moderate Impact: The GHE algorithm will not have a full scale monitoring capability that is newly proposed by OSPO Likelihood: Moderate Mitigation: Work with Zhaohui Cheng & Walter Wolf to leverage the tools to be developed under the Product Monitoring PSDI project Status: Open 63 Risks and Actions CDR Risk 2: No archive requirement is identified in the

SPSRB user request. Risk Assessment: Moderate Impact: The GHE products will not be archived at the time the product is scheduled to go operational Likelihood: High Mitigation: Finalize with the users for their archive need Work with NCDC/CLASS to identify the archive funding requirements Work with OSD and/or NWS to see if there is any funding available for archive. Status: Open 64 Outline

Introduction Zhao Risks Wolf Requirements Wolf Operations Concept Zhao

Algorithm Theoretical Basis Kuligowski Software Architecture &Interfaces Davenport Quality Assurance Wolf Risks and Actions Wolf Summary and Conclusions Zhao 65 Hydro-Estimator (H-E) Algorithm Theoretical Basis Presented by Bob Kuligowski 66

H-E Algorithm Theoretical Basis Outline Introduction Observing System Overview Algorithm Description

Product Generated Instrument Characteristics 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

67 H-E Algorithm Theoretical Basis Outline Practical Considerations Assumptions and Limitations

Numerical Computation Considerations Programming and Procedural Considerations Quality Assessment and Diagnosis Exception Handling Algorithm Validation Performance Assumed Sensor Performance Pre-Planned Improvements References 68 Global H-E Algorithm Theoretical Basis

Purpose: Provide a physical and mathematical description of the Global HydroEstimator algorithm for product developers, reviewers and users. Documented in the Hydro-Estimator Algorithm Theoretical Basis Document (ATBD) 69 H-E Algorithm Background The Hydro-Estimator has been the operational NESDIS rainfall rate algorithm for the CONUS since 2002. Modified from the operational Auto-Estimator algorithm, which in turn was an automation of the Interactive Flash Flood Analyzer (IFFA) developed in the 1970s and 1980s Has run in real-time at STAR since 2005 implementation at OSPO would simply involve code transfer and updating to meet new SPSRB

70 code and documentation standards. Global H-E Algorithm Objectives Provide real-time estimates of rainfall at the full IR pixel scale for the entire globe Maintain heritage with operational CONUS Hydro-Estimator and ensure continuity / consistency 71 H-E Algorithm Processing Outline

72 H-E Algorithm Sensor Input Central Satellite and Wavelength Sub-satellite Longitude Band Wavelength Scan Frequency sensor Range (m)m)m) IGFOV (m)km) (m)m)m) GOES-11 135W

CONUS: 15 min Imager 4 10.20-11.20 10.7 4 NH: 30 min GOES-13 SH: 30 min or 3 h 75W Imager METEOSAT-9 0E 9 10.28-11.28 10.8 3 FD: 15 min

SEVIRI METEOSAT-7 57.5E 3 10.5-12.5 11.5 5 FD: 30 min MVRI MTSAT-1R NH: 30 min 140E IR1 10.3-11.3 10.8 4 Imager SH: 60 min

73 H-E Algorithm Sensor Input Details For each block Calibrated/Navigated imager brightness temperatures Solar-view geometry (m)satellite zenith and azimuth angles) Name Longwave IR window brightness temperature Latitude Type input input

Description Calibrated level 1b brightness temperature at particular sensors IR window Latitude Longitude input Longitude View geometry input ABI view zenith and azimuth angles

Dimension grid (m)xsize, ysize) grid (m)xsize, ysize) grid (m)xsize, ysize) grid (m)xsize, ysize) 74 H-E Algorithm Ancillary Input Ancillary data needed: Satellite-specific Dynamic Data: None. Non-Satellite Dynamic Data (m)from GFS forecasts): Gridded vertical profiles of temperature and water vapor

Gridded total precipitable water Gridded 700-hPa u and v components Satellite-specific Static Data: None. Non-Satellite Static Data: Global digital elevation model. 75 H-E Algorithm Ancillary Input Details Non-satellite Dynamic Data from GFS Forecasts: Name Type Description Dimension

Gridded vertical profiles of temperature and water vapor Input Gridded vertical profiles of temperature and water vapor Gridded total precipitable water Input Gridded column total precipitable water grid (m)xsize, ysize)

Gridded 700-hPa u and v wind components Input Zonal and meridional components of wind at 700 hPa grid (m)xsize, ysize) grid (m)xsize, ysize,zsize) 76 H-EAlgorithm Ancillary Input Details Non-satellite Static Data:

Name Type Digital elevation model Input Description Pixel elevation for the entire globe on a 4-km grid Dimension grid (m)xsize, ysize,zsize) 77 Hydro-Estimator Algorithm

Output Metadata Processing date stamp & others Scientific Datasets Name Type Description Dimension Rainfall Rate Output Gridded rainfall rate in mm/h

grid (m)xsize, ysize) Quality flag Output Rain rate quality flag (m)0good; 0bad) grid (m)xsize, ysize) 78 Hydro-Estimator Retrieval Strategy Screen out non-raining pixels Adjust pixel temperature based on orography and moisture

No rain if adjusted temperature > 235 K No rain if adjusted temperature > local average Determine rain rates for raining pixels Compute core and non-core rain rates Compute rain rate based on proportion of core and non-core rain rates based on local brightness temperature 79 H-E Algorithm: Physical Basis (1) IR data give cloud-top properties only (e.g., temperature, particle size and phase) because clouds are generally opaque in the IR.

IR rain rates assume that colder clouds have stronger updrafts (vertical transport of moisture) and thus higher rain rates. 80 H-E Algorithm: Physical Basis (2) A significant problem is incorrect identification of cold cirrus clouds as raining. This results in significant overestimation of the extent of heavy rainfall in many IR-based algorithms.

81 H-E Algorithm: Physical Basis (3) The H-E addresses this by considering how the cloudtop brightness temperature compares with nearby cloudy pixels: Colder than nearby pixels active updraft with rainfall Warmer than nearby pixels inactive cloud with no rainfall 82 H-E Algorithm: Physical

Basis (4) The H-E also incorporates information from numerical weather models to account for sub-cloud effects, as shown here. In addition, convective equilibrium level temperature is used to identify regions where strong updrafts and heavy rain can occur even if the thermodynamic profile does not support very cold clouds. 83 H-E Algorithm

Mathematical Description Algorithm implementation steps: 1. Perform initial adjustment of IR brightness temperatures based on moisture availability and orographic effects 2. Determine raining areas 3. Compute rain rates 84 H-E Mathematical Description: IR Tb Adjustment (Overview) Adjust the initial Tb values for convective equilibrium level, orographic effects, and moisture effects. Tbs are adjusted instead of rain rates to allow the addition of new rain areas.

85 H-E Mathematical Description: IR Tb Adjustment (1/2) Adjust pixel temperatures downward if the convective EL is warmer than 213 K. This will increase rain rates (or even allow rain) for thermodynamic profiles that will not support very cold clouds (e.g., low tropopause). 86 H-E Mathematical Description: IR Tb Adjustment (2/2)

Adjust the temperature downward for orographically-driven updrafts to enhance (or add) rainfall. Adjust the temperature upward for dry environments. Adjust the temperature downward for very moist environments. 87 H-E Mathematical Description: Determine Raining Areas (Overview) Determine the temperature relative to nearby cloud pixels; those cooler than the average of the nearby pixels are considered for assigning rain. 88 H-E Mathematical

Description: Determine Raining Areas (1/6) If the pixel is below 235 K, compute two search radii for surrounding cloudy pixels (the colder the pixel, the larger the radius). Compute the mean and standard deviation temperature for both radii. 89 H-E Mathematical Description: Determine Raining Areas (2/6) Determine the minimum temperature in the neighborhood and adjust for convective equilibrium level temperature. 90 H-E Mathematical

Description: Determine Raining Areas (3/6) Perform additional equilibrium level adjustments to the temperature that will be used to compute the rainfall rate. 91 H-E Mathematical Description: Determine Raining Areas (4/6) Apply the orographic adjustment to the temperature that will be used to compute the rainfall rate; reduce the adjustment for very cold pixels. 92 H-E Mathematical

Description: Determine Raining Areas (5/6) Adjust the temperature used for computing the rainfall rate for available moisture (adjust downward for moist environments). 93 H-E Mathematical Description: Determine Raining Areas (6/6) Compute the difference between the temperature and local mean (scaled to the standard deviation) for both search radii. Pixels with higher values of Z (colder relative to the local mean) will have higher rain rates. 94

H-E Mathematical Description: Determine Rain Rate (Overview) Compute the rainfall rate based on the values of Z at the two scales, then perform a final adjustment based on RH. 95 H-E Mathematical Description: Determine Rain Rate (1/2) Compute separate core and non-core rainfall rates. Compute the rainfall rate for each neighbor radius, weighting them core and non-core values according to Z. If the far-radius rain rate is positive, use both in the final rain rate.

96 H-E Mathematical Description: Determine Rain Rate (2/2) Adjust the rainfall rates downward for lower RH values using a function with 3 segments. 97 Summary of H-E Rain Rate Retrieval Create adjustment fields from GFS data PW, RH, convective EL, orographic correction Determine if pixel is raining Adjust pixel temperature based on orography and

moisture No rain if adjusted temperature > 235 K No rain if adjusted temperature > local average Determine rain rates for raining pixels Compute core and non-core rain rates Compute rain rate based on proportion of core and non-core rain rates based on local Tb 98 Practical Considerations (1) Numerical computational considerations Each separate satellite can be processed in parallel processing if desired to reduce processing time Programming and procedure considerations Sub-sectors could be processed, but margin needs to be included to avoid errors from processing partial

clouds 99 Practical Considerations (2) Quality assessment and diagnostics Quality flags will be produced, with non-zero values for pixels whose inputs have values outside the acceptable range (values in ATBD) The following routine diagnostic procedures are recommended for evaluating performance: Examine image loops for artifacts or non-physical features Evaluate time series of bias statistics for anomalous behavior 100 Practical Considerations (3)

Exception handling Quality control flags will be checked and inherited from the sensor input data for handling these exceptions Bad sensor input data (depending on what input QC available) Missing sensor input data Missing geolocation or viewing geometry information Missing (negative) values will be assigned to any pixel with quality issues or with any input values outside the acceptable range. 101 Example of Implementation from Current Processing at STAR Retrieval of hourly rain accumulation from 0023 UTC 4 June 2009

Inputs: IR window (11 m) brightness temperatures from GOES-11 and -12, METEOSAT -7 and -9 and MTSAT-1R Numerical weather model adjustment parameters from GFS TOA albedo 102 Rainfall Rate Algorithm Verification Compared retrieved instantaneous rainfall

rates to Tropical Rainfall Measuring Mission (TRMM) spaceborne Precipitation Radar (PR) between 35S and 35N 103 Rainfall Rate Algorithm Performance Estimates The rainfall rate algorithm will likely meet requirements: Validation versus TRMM Precipitation Radar (covering 35 lat only ) for May through November 2007: Specification Rain Rate Evaluation vs. TRMM radar Accuracy

Precision Accuracy Precision 6.0 mm/h 9.0 mm/h 5.8 mm/h 9.0 mm/h 104 Assumptions and Limitations Assumptions:

Cloud-top temperatures are related to surface rainfall rates The entire cloud of interest is contained within the image Striping is minimal (striping will adversely affect the computation of cloud characteristics) ABI data have been corrected for parallax Calibration over the CONUS is applicable to other parts of the world Limitations: Better skill for convective rainfall than for stratiform rainfall (a standard limitation of satellite-based rain rate retrievals) 105 Error Budget Primary sources of error in rain rate are uncertainties in: Physical relationships between cloud-top temperature and rainfall rates

Input IR brightness temperatures, due to errors in calibration and stability GFS model output fields for adjustments Estimation of errors can be done by perturbing the different sources by known amounts and comparing the results to those from the un-perturbed values (at least in the first two cases) 106 Product Quality Monitoring Plan to develop an automated QC system to acquire, match and statistically compare satellite and (ground validation) radar estimates and alert if comparison statistics exceed pre-defined thresholds.

Input radiance and ancillary data QC: Gross checks (identify unphysical, out-of-bound, saturated values). Analysis of consistency with previous values. Check for simultaneous availability of all needed input. Product QC: Quality control satellite product (check for unphysical/missing values, check consistency, etc.) Compare satellite product with radar observations. Flag data and notify when statistics exceed pre-determined levels. 107 Summary The Hydro-Estimator algorithm has been run in operations for the CONUS since 2002 and experimentally at STAR since 2005.

This project is transferring the global operational code at STAR to operations at OSPO. The Hydro-Estimator uses IR brightness temperatures to identify regions of rainfall and retrieve rainfall rate, using GFS model fields to account for the effects of moisture availability, evaporation, orographic modulation, and thermodynamic profile effects. 108 Outline

Introduction Zhao Risks Wolf Requirements Wolf Operations Concept Zhao Algorithm Theoretical Basis Kuligowski Software Architecture &Interfaces Davenport Quality Assurance Wolf Risks and Actions Wolf

Summary and Conclusions Zhao 109 Software Architecture and Interfaces Presented by Clay Davenport 110 Software Architecture Purpose: Demonstrate that the algorithm process flow provides for an implementation that is consistent with the theoretical basis and meets requirements.

111 CDR Software Architecture A preferred solution has been selected for GHE Will be documented in ATBD The software system is an integrated collection of software elements, or code, that implements the preferred solution, producing well-defined output products from a well-defined set of input data. The software architecture describes the structure of the system software elements and the external and internal data flows between software elements. 112 Software Architecture Levels

Context Level - 0 External Interfaces System Level - 1 Flows Between Units Unit Level - 2 Flows Within Units Sub-Unit Level - 3 Flows Within Sub-Units 113

External Interfaces -Definition An external input is defined as a data source needed by the system that is produced or made available by a process external to the system An external output is defined as a data sink that is produced by the system for an external user 114 External Interfaces Criteria Most input/output data files for the GHE algorithms will be obtained from/delivered to the NESDIS data servers in McIDAS format. Static Files: Global terrain file (m)AREA file) Lookup tables for ground/satellite angles (m)ASCII)

Output Files Log files (m)ASCII) NetCDF4 version of output AREA files The data passed to the units and sub-units will be stored in AREA files. 115 External Interface Design at CDR Global HydroEstimator System 116 Purpose

Purpose: Demonstrate that the GHE system provides an infrastructure that will enable the implementation of the GHE algorithms that meet requirements. 117 GHE System Calculation of non-satellite inputs Calculation of Rainfall Rate for each satellite/sector Composite Rainfall Rate outputs 118 Data Flow and Interfaces The following slides show the data flow and

interfaces in the framework. 119 GHE System Context Diagram NCEP GFS Model Server Algorithm Packages Model Data Ancillary Data Satellite Servers

Lookup Tables Satellite Imagery Input Data Products GHE System File Server Products

120 GHE System Level Satellite Data NCEP GFS Model Data GOES-11 GOES-13 Meteosat-7 Meteosat-9 MTSAT-1R Zenith Angle Adjustment Joyce model

PW Parallax Adjustment RH EQL Topo Maps Orog Rain Rates 121

GHE System Level GOES-11 Rain Rates GOES-13 Rain Rates Meteo-9 Rain Rates Meteo-7 Rain Rates

MTSAT-1R Rain Rates Merger Algorithm Global Rain Composite 122 GHE Inputs McIDAS AREA files (m)IR imagery from five geosynchronous satellites) McIDAS GRID files (m)data from GFS model) Static Local Data Global Terrain Maps Lookup tables for viewing angle corrections

123 McIDAS AREA Files The satellite imagery to be processed for rain rates will be received as McIDAS AREA files Five satellites provide global coverage Satellite and sensor GOES-11 Imager GOES-13 Imager METEOSAT-9 SEVIRI METEOSAT-7 MVRI MTSAT-1R Imager

Central Wavelength (m)m)m) Sub-satellite IGFOV (m)km) Longitude Band Wavelength Range (m)m)m) 135W 4

10.20-11.20 10.7 4 75W 4 10.20-11.20 10.8 4 0E

9 10.28-11.28 10.8 3 57.5E 3 10.5-12.5 11.5 5

140E IR1 10.3-11.3 10.8 4 124 McIDAS AREA Files In order to maximize coverage in both space and time, 13 different types of AREA files need to be pulled from the servers GOES-13: GEFDSK04I4 (3 hourly), GENHEM04I4 (30 min), GECONS04I4 (15 min), GESHEM04I4 (30 min)

GOES-11: GWFDSK04I4 (3 hr), GWNEM04I4 (30 min), GWSHEM04I4 (30 min), GWPACU04I4(15 min) Meteosat-9: MSGLOB09I (15 min) Meteosat-7: INDOEXIR (30 min) MTSAT-1R: MTGLOB04I2 (60 min), MTNHEM04I2 (30 min), MTSHEM04I2 (6 hourly) 125 GFS Model Data Model data updates every 6 hours Always selects the most current model run containing data for selected time Will continue to work through two missed model runs Extracts vertical profiles of temperature and humidity at each grid point, total precipitable water, and 700 mb winds Data is obtained in McIDAS GRID format, converted into AREA format to match satellite imagery

126 Static Local Data Cloud-top temperatures are modified from a lookup table based on apparent temperature, zenith angle, latitude, and season (Joyce CPC model) Global topographic files and land/sea masks, in AREA format, from SSEC and USGS 127 Product Precedence Model-based adjustments (PW, RH, Orography, Stability) used by all satellites, are run as standalone jobs every hour Each of the five satellite rainfall products is

run as its own job (attempts every 15 minutes, skipped if no new satellite data) Compositing programs create spatial mosaics and time summations; time summations run with each new rain image, global composite runs hourly 128 Product Precedence Model Data Precipitable water and relative humidity are directly taken from the NFS model, interpolated between model runs to an hourly product Data transformed into a global AREA file Each satellite run will extract the portion of the global field required 129

Product Precedence Model Data Orographic and equilibrium level files have to be derived from NFS model data Orographic data combined model winds with USGS digital terrain data Stability calculated by running model profiles through 1D model Built separately for each satellite field, not a single global product Have traditionally been made every six hours, without interpolation 130 Product Precedence Satellite Runs

Each of the five satellites will run as a separate job to create a rainfall image within its field of view Satellites are spaced 58-82apart, with a 108FOV providing overlapping coverage Latitudinal coverage to 62N and S Each job is completely independent of the others and they can all run simultaneously Latencies to data receipt range from 6-32 minutes after image time 131 Product Precedence Satellite Runs Zenith-angle adjustments to cloud-top temperature calculated from Bob Joyces model developed for CPC Parallax adjustments to locations based on corrected

temperatures and model profile data to determine cloud height Rain calculation based primarily on corrected cloudtop temperatures and geometry, adjusted by other derived products 132 Product Precedence Satellite Runs GOES products are the most complicated Need to follow a hierarchy to grab the best available from Full-disk data (available every 3 hours), to hemispheric data (every 30 minutes), to CONUS/PACUS products (15 minutes) Can lose South American data for up to 3 hours during RSOs Frequent gaps in southeast Pacific 133

Product Precedence Satellite Runs Meteosat-9 covers Europe and Africa every 15 minutes Meteosat-7 covers Indian Ocean and central Asia every 30 minutes MTSAT-1R covers Australia, east Asia, and the western Pacific Northern hemisphere every 30 minutes Southern hemisphere every 60 minutes 134 Product Precedence Composites Each satellite will have its own routine to create an hourly time summation of the observed precipitation

Summation routine runs by pixel, adapts for different sized images being summed Time-weighted average each pixel weighted by the portion of the hour it represents 135 Product Precedence Composites Mosaic program will run hourly to create a global composite rainfall image Creates seamless smooth averaging in the overlap regions using zenith angle weighting Will also run for previous hours to catch laterarriving data 136 Output Files Output files are in McIDAS AREA format and netCDF

Output files will be post-processed for final display and distribution to users and web Composites over multiple time lengths N. America gets 0-1-3-6 hours, 1-7 days World gets 0, 1 hour, 1 day 137 Hardware STAR Linux machine, 8 CPUs Capable of running all five satellite rain products simultaneously OSPO Linux machine, 2 quad core CPUs (Development, Test, and Ops) Capable of running all five satellite rain products simultaneously

138 Software/Compilers GHE System uses McIDAS version 2009 or higher required for Meteosat-9 imagery McIDAS 2010 uses freely available gcc and gfortran compilers (and older g77) Shell scripts Control all processes and logging CVS version control 139 External Interface Design at CDR

Context Level 140 GHE Unit Level Data Flows Table Input, Internal, and Output Data Flows at the Unit Level Interface Item Interface Type Source Description Satellite IR

Input NESDIS Precipitable water Input NCEP NWP forecasts of global PW Relative humidity Input NCEP

NWP forecasts of low-level RH Stability profile (EL) Input NCEP Derived from NWP forecast temperature and moisture profiles Model winds Input NCEP NWP forecasts of 700mb winds

Global topographic map Input SSEC Global 4km elevation map derived from the USGS GTOPO30 Viewing angle adjustments Input CPC Lookup tables for adjusting cloud-top temperatures Rain rates

Output GVAR calibrated and navigated brightness temperatures Global estimated precipitation 141 Design Overview and System Description 142 Design Overview Description The design overview builds on the software architecture by providing a high level description of

each system element that is defined in the software architecture. The design overview describes the project systems functionality and design characteristics at a high level that covers, for each system element: Its purpose External interfaces Decomposition into sub-elements Functional sequence Design Language Input and Output File Descriptions

143 STAR EPL Process Design Overview Fully defines the structure and capabilities of the software product components. Software architecture details are finalized Software components are completely defined Interfaces to software components are fully characterized Connects the design to the allocated productcomponent requirements, architecture, and higher level designs 144 Metadata Design STAR plans to work with OSPO to create a DSA with CLASS still some uncertainty with both

funding and time constraints Metadata design should respond to metadata requirements The metadata will be in the ISO standard STAR is familiar with the ISO standards through the NUCAPS project 145 GHE Unit Description Produce rain rates with associated quality flags. Interfaces Satellite IR data, approx 10.7 um, from geosynchronous satellites Global Topographic maps Lookup tables for ground/satellite viewing angles

Model data for moisture availability, stability, and winds 146 GHE Unit Description PW PW Process Start Select current time Search model data for time match Convert from GRID to AREA Exit

147 GHE Unit Description RH RH Process Start Select current time Search model data for time match Convert from GRID to AREA Exit 148

GHE Unit Description Orographic Start Orographic routine Create 1D, windfollowing terrain array Select global region topo map (input parameter) Select 700 hPa U,V components from GFS Calculate induced vertical lift

Remap winds to match topo region No Is it flat/at sea? Yes Write to output AREA file End orographic routine 149

GHE Unit Description Equilibrium Level Start EL routine Select global region (input parameter) Select T,Z,RH, U,V components from GFS Run 1-D atmospheric model to calculate stability parameters at each grid location Write equilibrium

level temperature into GRID file Rewrite GFS grid data into McIDAS MD format End EL routine 150 GHE Unit Description Rain Rates Start RR routine Run rain rate calculation routine Select satellite data from input

region Remap satellite data into standard regional Mercator Write rain rates to output AREA file Extract regional PW and RH AREAs from global AREA files End RR routine Select pre-made orographic and EL files for selected region 151 GHE

Unit Description Spatial Mosaics Start Mosaic routine Use blank RR No Yes Current Goes-E RR? Use RR Use blank RR

Current GoesW RR? Use RR Use blank RR Current Met-9 RR? Use RR Perform zenith angle weighted sum of all inputs

Use blank RR Current Met-7 RR? Use RR Write to output AREA Use blank RR Current MTSAT RR?

Use RR Remap each component to global map parameters End Mosaic routine 152 GHE Unit Description Design Language FORTRAN 77/90

Assumptions apply to the unit design: NWP data of comparable or superior quality to the current 6 hourly GFS forecasts are available. The sensor input data, IR brightness temperatures, meets the requirement Limitations apply to the unit design: The algorithm does minimal error checks for the input files. 153 Outline

Introduction Zhao Risks Wolf Requirements Wolf Operations Concept Zhao Algorithm Theoretical Basis Kuligowski Software Architecture &Interfaces Davenport Quality Assurance

Wolf Risks and Actions Wolf Summary and Conclusions Zhao 154 Quality Assurance Presented by Walter Wolf 155 QA Overview (1) CMMI = Capability Maturity Model Integration STAR is using the Capability Maturity Model Integrated

(CMMI) for improvement of the process and practices for the transfer of research to operations. STAR Enterprise Life Cycle (EPL) merge the CMMI and SPSRB standards. Multiple PSDI projects are being tranistioned to operations using the EPL process GOES-R AWG algorithm development also followed the same process. 156

QA Overview (2) Product & Process Quality Assurance is one of the CMMI Key Process Areas (KPA). QA Purpose: Problem Prevention Early Error Detection Risk Identification and Mitigation 157 Quality Assurance Quality assurance consists of PROCESS QA and PRODUCT QA PROCESS QA is concerned with assuring that the STAR EPL process standards are met during the planning, development, operations, and distribution phases of the project. Process QA is achieved through the standard reviews of the STAR EPL process. Each review checklist and entry/exit criteria are designed to

ensure that the relevant process standards are met by the implementation of standard practices during the steps leading up to the review. PRODUCT QA is concerned with assuring that the work products created during the projects lifecycle meet their requirements Product QA is achieved by verification of the projects work products and validation of the products, operator needs, and user needs 158 QA Activities

Configuration Management Project Monitoring Validation and Verification Documentation Standard Testing Tools Collaboration and Communication Website 159 Configuration Management (CM) CM Tool (IBM Rational ClearCase, Version 7.0) CM personals have been identified.

CM training has been conducted Administrator training completed (Xingpin Liu) IBM on site training for developers is being scheduled Detailed CM Plan has been developed 160 CM Stakeholders Xingpin Liu (AIT) CM Lead Yunhui Zhao (AIT) CM Administrator Mark Romer, Brian Keffer (STAR IT) CM installation

GHE Team Developers CM Users 161 Project Monitoring and Control Provides management with objective feedback regarding process compliance to approved plans, procedures, standards, and analyses. Identify and track the issues and risks throughout the lifecycle Document these activities in the Project Monthly Reports 162

Validation of GHE Needs The GHE software will be delivered to the OSPO team. The OSPO team will then integrate and operate the GHE software within the development environment. The GHE software will then be run within the test environment before being transitioned to operations. 163 Validation of GHE Needs Functionality Within the Development Environment Able to compile and run on the hardware The development machine is the same hardware as the test machine so a successful compile and run should demonstrate this functionality. Able to handle external interfaces Test files will be used to show that the software units can handle the

external interfaces. The standard output format for near real time products is netCDF4 and McIDAS. A simple demonstration test will show that the output files can be read by netCDF4 and McIDAS readers therefore showing that they are valid output files. STAR code checkers will be used to ensure that code meets the agreedupon coding standards. 164 Validation of User Needs The GHE External Users Manual will be part of the documentation suite. Validation will consist of allowing reviewers to inspect the document to ensure that all required sections are present. The Users are the users of the GHE data products The user needs consist of the following project

documentation and tools: GHE External Users Manual 165 Products Verification and Validation (V&V) Product V&V activities are performed and carried out over the life-time of the project. Pre-Delivery: Performed quality check of the codes. Verify the output running on the test datasets. Verify the output from the GHE system. Use tools for validation of the products

Post-Delivery: Verify the output from the GHE system. Use tools for validation of the products 166 Verification Methods Analysis consists of activities such as the generation of statistics to examine the distribution and errors and the comparison of results with reference data. Inspection is simply verifying that required element is present or that the expected output was obtained. Demonstration is meant to illustrate the functionality of something such as a software unit.

167 Verification: Data Product Item Rainfall Rates Rainfall matchups Metadata Verification Method Analysis Analysis Inspection 168

Verification: Software and Tool Item Method Model Adjustment unit Demonstration/Inspection Rainfall unit Demonstration/Inspection Compositing unit Demonstration/Inspection

Validation unit Demonstration/Inspection 169 Documentation SPSRB Documentation will be produced Documentation will be delivered along with the release of software. 170 Verification Documentation Item

Method Algorithm Theoretical Basis Document (m)ATBD) Critical Design Document (m)CDD) Requirements Allocation Document (m)RAD) Inspection System Maintenance Manual Internal Users Manual Inspection Inspection External Users Manual Review Item Disposition Data Submission Agreement (m)DSA)

Inspection Inspection Inspection Inspection Inspection 171 Algorithm Testing Plans for Testing Unit Testing Integration Testing Test Review/Report 172

Coding Standards Coding standard guidelines and quick references are available. Provide a common list of abbreviations. Adhere to the standards throughout the development life cycle. Have checklists available for developers to keep track of the delivery status of the code. 173 Tools Code Generators Fortran 77 to Fortran 90 Converters Revision Control Clear Case, Clear Quest, CVS 174

Collaboration and Communication Maintain communication with all the stakeholders, such as the OSPO, NCEP, JCSDA, CLASS and the GHE Team. Keep all the project artifacts/assets available to the stakeholders. 175 QA Summary QA activities are being performed throughout the GHE software development life cycle. Code development and documentation follow the guidelines/standards of STAR EPL and SPSRB. Tools and procedures for QA are under development. The QA process will assure faster and more efficient

research to operation transitions. 176 CDR Risks and Actions For GHE CDR Risk 3: Schedule delays Risk Assessment: Low Impact: Schedule delays will cause an increased in cost to the project Likelihood: Low Mitigation: Review all the project tasks on a monthly basis. If tasks start to slip Integration Team will work more closely with the GHE team to help it catch up. Status: Open 177

Outline Introduction Zhao Risks Wolf Requirements Wolf

Operations Concept Zhao Algorithm Theoretical Basis Kuligowski Software Architecture &Interfaces Davenport Quality Assurance Wolf Risks and Actions Wolf Summary and Conclusions Zhao 178 Risks and Actions Summary Presented by Walter Wolf 179

Open Pre-CDR Risks and Actions For GHE Pre-CDR Risk 2: Possible loss of MeteoSAT Mitigation: Work with NESDIS management to ensure that MeteoSAT data is readily available 180 Open Pre-CDR Risks and Actions For GHE Pre-CDR Risk 3: Compressed schedule due to funding needing to be spent by 09/30/11 Mitigation: Add more staff on the STAR and OSPO side to complete the transition tasks before 09/30/11

Pre-CDR Risk 4: No current funding past 09/30/11 Mitigation: Work with NWS to extend leftover funding into FY12 181 GHE CDR Risks and Actions Risk 1: Lack of enough funding for product quality monitoring of the GHE algorithm -- not fully scoped in the current project plan Mitigation: Work with Zhaohui Cheng & Walter Wolf to leverage the Product Monitoring PSDI Risk 2: Lack of time to work through the required archive procedures; No funding is provided for archive from NWS Mitigation:

Work with NCDC/CLASS to identify the archive funding requirements Work with OSD and/or NWS to see if there is any funding available for archive. 182 GHE CDR Risks and Actions CDR Risk 3: Schedule delays Mitigation: Review all the project tasks on a monthly basis. If tasks start to slip Integration Team will work more closely with the GHE team to help it catch up 183 Review Items Summary

4 Pre-CDR risks have been reported in the CDR, 3 of which are still open. 3 risks and actions from the CDR were reported earlier in this CDR and all 3 are still open. 184 Outline

Introduction Zhao Risks Wolf Requirements Wolf Operations Concept Zhao Algorithm Theoretical Basis Kuligowski Software Architecture &Interfaces Davenport Quality Assurance Wolf Risks and Actions Wolf Summary and Conclusions Zhao

185 Summary and Conclusions Presented by Limin Zhao 186 Review Objectives Have Been Addressed Pre-CDR Report has been reviewed Operations concept has been reviewed Requirements have been reviewed Algorithm theoretical basis has been reviewed Software system architecture and interfaces have been reviewed Plans for quality assurance have been reviewed

Open Risks and Actions have been reviewed 187 Next Steps Code Development Phase Code development

Test data generation Unit tests Prepare documentation Software Review (Oct 31, 2011) 188 Open Discussion The review is now open for free discussion 189 Appendix 190

Recently Viewed Presentations

  • 14. Cell Arrays - Cornell University

    14. Cell Arrays - Cornell University

    Cell Arrays A Small Cell Array… Syntax Synonym "Vertical" Cell Array Set-up Another Small Cell Array… Syntax Synonym Problem: Set Up a Card Deck Idea…
  • German Vocational Training Institute based on REFA Methodology

    German Vocational Training Institute based on REFA Methodology

    Arial Times New Roman Calibri SimSun Verdana Larissa-Design 1_Larissa-Design 2_Larissa-Design 3_Larissa-Design 4_Larissa-Design 5_Larissa-Design 6_Larissa-Design 7_Larissa-Design 8_Larissa-Design 9_Larissa-Design 10_Larissa-Design German Vocational Training Institute based on REFA Methodology Folie 2 Folie 3 About GVTI REFA Key Factors of ...
  • Branches of Biology

    Branches of Biology

    Definition. Examples of Scientific. Branches. Characteristics. All the sciences. share. Examples of things . that are NOT scientific
  • Matthew 27 - Brigham Young University-Idaho

    Matthew 27 - Brigham Young University-Idaho

    Matthew 27. Theme = Is he the King of the Jews or not? It takes us right back to Matthew 1 & 2. Pontius Pilate: Appointed Roman ruler in A.D. 25-26. He was anxious to please Caesar. His political life...
  • Rainforest Animals

    Rainforest Animals

    Rainforest Animals Which of these animals are found in the Rainforest? gorilla parrot sheep toucan bat dragonfly horse butterfly frog hamster cow monkey dog snake goldfish beetle Rainforest Animals
  • Privacy: Expectations, Norms, Technology

    Privacy: Expectations, Norms, Technology

    Social norms define the role, impose obligations, create expectations, and shape desires both for the lawyer, doctor, or race car driver, and for those who interact with them. Norms and Identity Similar remarks hold for being a parent, child, lover,...
  • Meeting the needs of LGBT men and women using our residential ...

    Meeting the needs of LGBT men and women using our residential ...

    Gay and bisexual older men are x3 more likely to be single than heterosexual men . Lesbians and bisexual women are more likely than heterosexual women to have been diagnosed with anxiety and depression . 50% are uncomfortable about being...
  • Chapter 9 Concepts and Theories of Stratification Key

    Chapter 9 Concepts and Theories of Stratification Key

    Structural mobility Mobility that occurs because of changes in the relative distribution of upper and lower statuses in a society. Exchange mobility Mobility that occurs because some people fall, thereby making room for others to rise in the stratification system.