1 / 342

NOAA-Unique CrIS-ATMS Product System (NUCAPS) Critical Design Review September 29, 2008

NOAA-Unique CrIS-ATMS Product System (NUCAPS) Critical Design Review September 29, 2008. Prepared By: Tom King 1 , Zhaohui Cheng 1 ,Larisa Koval 1 , Antonia Gambacorta 1 , Lihang Zhou 1 , Walter Wolf 2 and Chris Barnet 2 1 Perot Systems Government Services 2 NOAA/NESDIS/STAR.

malise
Download Presentation

NOAA-Unique CrIS-ATMS Product System (NUCAPS) Critical Design Review September 29, 2008

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. NOAA-Unique CrIS-ATMS Product System (NUCAPS)Critical Design ReviewSeptember 29, 2008 Prepared By: Tom King1, Zhaohui Cheng1,Larisa Koval1, Antonia Gambacorta1, Lihang Zhou1 , Walter Wolf2 and Chris Barnet2 1 Perot Systems Government Services 2 NOAA/NESDIS/STAR

  2. Review Outline • INTRODUCTION • PDR REPORT • OPERATIONS CONCEPT • REQUIREMENTS • ALGORITHM THERORITICAL BASIS • SOFTWARE ARCHITECTURE AND INTERFACES • QUALITY ASSURANCE • REQUIREMENT ALLOCATION • RISKS AND ACTIONS • SUMMARY AND CONCLUSIONS

  3. Review Agenda • INTRODUCTION Lihang Zhou • PDR REPORT Ken Jensen • OPERATIONS CONCEPT Thomas King • REQUIREMENTS Larisa Koval • ALGORITHM THERORITICAL BASIS Antonia Gambacorta • SOFTWARE ARCHITECTURE AND INTERFACES Thomas King Lunch • QUALITY ASSURANCE Zhaohui Cheng • REQUIREMENT ALLOCATION Larisa Koval • RISKS AND ACTIONS Zhaohui Cheng • SUMMARY AND CONCLUSIONS Zhaohui Cheng

  4. INTRODUCTION • PDR REPORT • OPERATIONS CONCEPT • REQUIREMENTS • ALGORITHM THEORETICAL BASIS • SOFTWARE ARCHITECTURE AND INTERFACES • QUALITY ASSURANCE • REQUIREMENTS ALLOCATION • RISKS AND ACTIONS • SUMMARY AND CONCLUSIONS

  5. Section 1 – Introduction Presented byLihang Zhou PSGS

  6. NUCAPS - Research Project Plan • The Research Project Plan (RPP) is a standard artifact of the STAR EPL process. • The RPP identifies project objectives, stakeholder roles and tasks, resources, milestones and schedule • PRR reviewers can access this document at <pointer to the RPP> • Guidelines for the RPP are found in STAR EPL process asset DG-6.1 • PRR reviewers can access this document at <pointer to DG-6.1>

  7. Project Objectives • Subset the CrIMSS SDR’s both spatially and spectrally to produce thinned radiance datasets to distribution to NWP centers. • Provide CrIS/ATMS NOAA Unique products within three hours of observation (or 30 minutes of data receipt from IDPS) to NWS and DOD • Reconstructed Radiances • Cloud Cleared Radiances • NOAA Unique Trace Gas Products • Provide NOAA Unique CrIS/ATMS Products to CLASS. • Validate the official CrIMSS EDR Products.

  8. Project Stakeholders –Customers and Users • U.S.Users: • NCEP- National Centers for Environmental Prediction (Jim Jung/Dennis Keyser) • GMAO- Global Modeling and Assimilation Office (Emily Liu) • NRL – Naval Research Laboratory (Ben Ruston) • FNMOC – Fleet Numerical Meteorology and Oceanography Center (Yiping Wang) • STAR – Center for Satellite Applications and Research (Tony Reale, Murty Divakarla, Zhaohui Cheng) • CLASS - Comprehensive Large Array-data Stewardship System (John Bates) • Foreign Users: • UK Met Office (Nigel Atkinson) • JMA- Japan Meteorological Agency (Yoshiaki Takeuchi) • ECMWF- European Center for Medium range Weather Forecasting (Tony McNally) • DWD- Germany’s National Meteorological Service (Reinhold Hess) • Meteo-France- France’s National Weather service (Lydie Lavanant) • CMC- Canadian Meteorological Center (Louis Garand) • EUMETSAT – Simon Elliott

  9. Project Stakeholders – Operations and Maintenance • NDE – NPOESS Data Exploitation (Jim Yoe) • NDE System Development Team (Ed Wilson) • OSDPD (A.K. Sharma) • Run the CrIS product processing system on the operation side • Distribute the CrIS data and product

  10. Project Stakeholders – Development Team • STAR (Mitch Goldberg-P.I., Chris Barnet-P.I., Walter Wolf-Lead, Lihang Zhou, Thomas King, Zhaohui Cheng, Antonia Gambacorta, Larisa Koval, Haibing Sun, Kexin Zhang, Xingpin Liu) • Develop the CrIS product processing software package

  11. NUCAPS Product Processing System Organization Chart Customers/Users NCEP, GMAO, NRL/FNMOC STAR,CLASS UK Met Office, ECMWF, DWD Meto-France, CMC, EUMETSAT NUCAPS Project Mitch Goldberg (P.I. Division Chief) Hank Drahos (Branch Chief) Development IPT Walter Wolf (Lead) and A.K. Sharma Research Algorithm Chris Barnet (Algorithm Lead) Zhaohui Cheng (PC) Antonia Gambacorta (Algorithm Scientist) Operations & Maintenance Jim Yoe (NDE) Ed Wilson (NDE System Development Team) A.K. Sharma (Operations Lead) Pre-Operational Algorithm Tom King (Programming Lead) Chen Zhang (Programmer) Kexin Zhang & Haibing Sun (Simulation) Support Lihang Zhou (QA Lead) Xinping Liu & Yunhui (CM) Peter Keehn (PBR) Xingpin Liu (Web) Larisa Koval (Documentation)

  12. Project Milestones • Preliminary Design Review – May 9, 2007 • Critical Design Review – Sep. 29, 2008 • Test Readiness Review – Feb., 2010 • Code Unit Test Review – Mar., 2010 • System Readiness Review – Dec., 2010 • SPSRB Briefing – Feb., 2011 • Operations Commence – Feb., 2011

  13. Project Timeline PDR 09/29/04 L1C Products CDR 01/12/06 L1C Pre-Op Phase In Progress L1C Code 04/05/06 L2 Code 07/31/06 ATBD 1st draft 11/10/06 L2 Development Phase In Progress L2 Products CDR 11/14/06 Section 1.4

  14. Project Timeline – Design Development Phase PDR 09/29/04 L1C Products CDR 01/12/06 L1C Pre-Op Phase In Progress L1C Code 04/05/06 L2 Code 07/31/06 ATBD 1st draft 11/10/06 L2 Development Phase In Progress L2 Products CDR 11/14/06 Section 1.4 - Timeline Partition

  15. NUCAPS SPSRB Milestones and Key Tasks

  16. NUCAPS SPSRB Milestones and Key Tasks

  17. NUCAPS SPSRB Milestones and Key Tasks

  18. NUCAPS SPSRB Milestones and Key Tasks

  19. NUCAPS SPSRB Milestones and Key Tasks

  20. NUCAPS SPSRB Milestones and Key Tasks

  21. NUCAPS SPSRB Milestones and Key Tasks

  22. NUCAPS SPSRB Milestones and Key Tasks

  23. Project Plan Stakeholder Involvement • Development Team • Coding and documentation • Quality assurance • Data verification and validation • Configuration Management and archive • Operation and Maintenance • 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

  24. Review Objectives (1) • Review the project plan • Research Project Plan (RPP) • Review the Preliminary Design Review (PDR) • Preliminary Design Review Report (PDRR) • Review the operations concept • Review the requirements • Requirements Allocation Document (RAD) • Review the algorithm theoretical basis • Algorithm Theoretical Basis Document (ATBD)

  25. Review Objectives (2) • Review the software system architecture • Software Architecture Document (SWA) • Review the plans for quality assurance • Project Baseline Report (PBR) • Verification and Validation Plan (VVP) • Review the requirements allocation • Requirements Allocation Document (RAD) • Review risks and actions

  26. INTRODUCTION • PDR REPORT • OPERATIONS CONCEPT • REQUIREMENTS • ALGORITHM THEORETICAL BASIS • SOFTWARE ARCHITECTURE AND INTERFACES • DETAILED DESIGN AND SYSTEM DESCRIPTION • QUALITY ASSURANCE • REQUIREMENTS ALLOCATION • RISKS AND ACTIONS • SUMMARY AND CONCLUSIONS Section 2 Setup Slide

  27. INTRODUCTION • PDR REPORT • OPERATIONS CONCEPT • REQUIREMENTS • ALGORITHM THEORETICAL BASIS • SOFTWARE ARCHITECTURE AND INTERFACES • QUALITY ASSURANCE • REQUIREMENTS ALLOCATION • RISKS AND ACTIONS • SUMMARY AND CONCLUSIONS

  28. Section 2 – Preliminary Design Review Report Presented by<Presenter’s Name> <Presenter’s Title/Role> <Presenter’s Organization> Slide 2.0

  29. Section 2 – PDR REPORT Presented byKen Jensen Raytheon

  30. Preliminary Design Review Report (PDRR) • PDRR is the approved report of the PDR reviewers. The PDRR can be obtained at <Pointer to the PDRR> • The PDRR includes approval status for each preliminary design requirement • Status should be Pass, Conditional Pass, Waive, or Defer • Items with “Conditional Pass” status must have associated actions that should be closed prior to CDR • Items with “Defer” status must have associated actions • Actions deferred to the CDR must be addressed prior to CDR approval • Agreement of relevant stakeholders should be documented • The PDRR includes an assessment of risk items, with recommendations for risk mitigation • Status of the risk items will be addressed in Section 10 of this CDD

  31. Preliminary Design Review Report (PDRR) • PDRR is the approved report of the PDR reviewers. The PDRR will be ready after CDR. • The PDRR includes approval status for each preliminary design requirement • The PDRR includes an assessment of risk items, with recommendations for risk mitigation • Status of the risk items will be addressed in Section 9 of this CDD

  32. NUCAPS CDR –Entry Criteria # 1 - 2 • Entry # 1 -A Preliminary Design Review Report (PDRR) has been written. The CDR reviewers have access to the approved version of the PDRR. • Entry # 2 -A Research Project Plan (RPP) has been written. The CDR reviewers have access to the approved version of the RPP.

  33. NUCAPS CDR –Entry Criteria # 4 - 6 • Entry # 4 -A Requirements Allocation Document(RAD) has been written. The CDR reviewers have access to the approved version of the RAD. • Entry # 5 -An Algorithm Theoretical Basis Document (ATBD) has been written. The CDR reviewers have access to the approved version of the ATBD. • Entry # 6 -A Software Architecture Document (SWA) has been written. The CDR reviewers have access to the approved version of the SWA.

  34. NUCAPS CDR –Entry Criteria # 11 - 13 • Entry # 11 -A Project Baseline Report (PBR) has been written. The CDR reviewers have access to the approved version of the PBR. • Entry # 12 -A Verification and Validation Plan (VVP) has been written. The CDR reviewers have access to the approved version of the VVP. • Entry # 13 -A Critical Design Document (CDD) has been written. CDR review objectives are clearly stated in the CDD.

  35. NUCAPS - Waived CDR Entry Criteria (1) • Entry # 3-An Operations Concept Document (OCD) has been written. The CDR reviewers have access to the approved version of the OCD. [rationale and risk - Given the current constraints on the project, the OCD has been deferred. The risk is low because the operations concept is described in Section 3 of this CDD.] • Entry # 7 –An Interface Control Document (ICD) has been written. The CDR reviewers have access to the approved version of the ICD. [rationale and risk] • Entry # 8 –Detailed Design Documents (DDD) have been written for each unit of the software architecture. The CDR reviewers have access to the approved version of each DDD.[rationale and risk]

  36. NUCAPS - Waived CDR Entry Criteria (2) • Entry # 9 -A Metadata Document (MDD) has been written. The CDR reviewers have access to the approved version of the MDD.[rationale and risk] • Entry # 10 -A System Description Document (SDD) has been written. The CDR reviewers have access to the approved version of the SDD. [rationale and risk]

  37. NUCAPS CDR –Exit Criteria # 1 - 4 • Exit # 1 - PDR "Conditional Pass" items have been satisfactorily disposed of • Exit # 2 - PDR “Defer" items have been satisfactorily disposed of • Exit # 3 - Operations concept is satisfactory • Exit # 4 – Requirements are satisfactory

  38. NUCAPS CDR –Exit Criteria # 5 - 10 • Exit # 5 - Algorithm theoretical basis and ATBD are satisfactory. • Exit # 6 - Software architecture and SWA are satisfactory • Exit # 7 - Project baseline and PBR are satisfactory • Exit # 8 - Verification and validation plan and VVP are satisfactory. • Exit # 9 - Requirements allocation and RAD are satisfactory • Exit # 10 –Project risks and actions are acceptable

  39. NUCAPS CDR –Exit Criteria # 5 - 7, 11 - 14 • Exit # 5 - Algorithm theoretical basis and ATBD are satisfactory. • Exit # 6 - Software architecture and SWA are satisfactory • Exit # 7 – External interfaces are satisfactory • Exit # 11 - Project baseline and PBR are satisfactory • Exit # 12 - Verification and validation plan and VVP are satisfactory. • Exit # 13 - Requirements allocation and RAD are satisfactory • Exit # 14 –Project risks and actions are acceptable

  40. NUCAPS CDR –Waived Exit Criteria • Exit # 8 – Software detailed design and DDDs are satisfactory [rationale and risk] • Exit # 9 – Metadata description and MDD are satisfactory [rationale and risk] • Exit # 10 – System description and SDD are satisfactory [rationale and risk]

  41. INTRODUCTION • PDR REPORT • OPERATIONS CONCEPT • REQUIREMENTS • ALGORITHM THEORETICAL BASIS • SOFTWARE ARCHITECTURE AND INTERFACES • QUALITY ASSURANCE • REQUIREMENTS ALLOCATION • RISKS AND ACTIONS • SUMMARY AND CONCLUSIONS

  42. Section 3 – Operations Concept Presented byThomas King NUCAPS Lead Developer PSGS

  43. Operations Concept - Overview • Before requirements can be developed for a product and product system, the developers must know the intentions of the customers and/or users of the product. They must have the answers to the following questions: • Why is this product being produced? • How will this product be used? • How should this product be produced (operational scenario)? • The answers to the preceding questions should be derived from customer/user needs and expectations • Often, the customers/users will have documented their concept of operations in a ConOps document (see next slide) • Prior to the Development Phase, algorithm developers should interact with the potential customers/users to produce an initial algorithm theoretical basis that is consistent with their concept of operations • The operations concept is typically refined by the development team, in consultation with customers/users, as the product solutions and design are matured through the Design Development phase.

  44. NUCAPS Products Customers • The U.S. Customers are identified as the only requirements drivers for products in the NUCAPS Requirement Allocation. • NCEP/JCSDA • NRL/FNMOC • NASA/GMAO • NCDC/CLASS • Potential International Customers • EUMETSAT • UK Met Office • ECMWF • DWD • JMA • CMC • ABM

  45. NCEP/JCSDA: Why Are The Products Being Produced? • NCEP has requested a thinned CrIS SDR product: • Warmest CrIS FOV per FOR subset for ~600 channels picked by the NUCAPS development team (as was done for IASI) in BUFR. Here are the BUFR specifications: • CrIS radiances stored as 16 bits • Allow negative values of radiance • VIIRS derived cloud fraction on the CrIS FOVs • BUFR table must used delayed replication • CrIS radiances must be apodized (need to know what method was used) • Must be available within 3 hours of observation • How were these determined? • NUCAPS development team met with Jim Jung (JCSDA/NCEP) in October 2007 and asked him what variables are needed in the CrIS thinned radiance BUFR products. From this dialog, a table was developed and given to Jim Jung. • This product table was then circulated in an email from Jim Jung to Dennis Keyser, John Derber, and Paul Van Delst. • Steve Lord met with Jim Yoe. They refined an SPSRB NDE product table called “NPP Phase I Products – Re-formatting priorities for NCEP-EMC March 27 2008”. We obtained this from Tom Schott.

  46. The NCEP/JCSDA Thinned Radiance Product Content

  47. NCEP/JSCDA: How Will The Products Be Used? • Initially the JCSDA will conduct experiments to determine if use of the product increases forecast skill in the models. JCSDA goals: • Reduce from two years to one year the average time for operational implementation of new satellite technology • Increase uses of current satellite data in NWP models • Advance the common NWP models and data assimilation infrastructure • Assess the impacts of data from advanced satellite sensors on weather and climate predictions • After impact tests verify improved forecast skill, the data will be assimilated and used by NCEP forecast models.

  48. NCEP/JCSDA: How Should The Products Be Produced? (1) • Input Data will be the netCDF4 tailored from the NPOESS HDF5 files produced by the IDPS • CrIS SDR granules (netCDF4) • CrIS Geo SDR granule (netCDF4) • VIIRS Intermediate Cloud Product granules (netCDF4) • VIIRS Geo Intermediate Cloud Product granules (netCDF4) • Available production environments • NDE production will occur on IBM P570/P561 machines. • The system will initially by run by the NDE team during the NPP phase and then transitioned to operations (OSDPD) personnel.

  49. NCEP/JCSDA: How Should The Products Be Produced? (2) • Production and Delivery scenarios • The NUCAPS units will be scheduled, executed, and managed by the NDE Data Handling System (DHS). • All file handling will be conducted by the NDE DHS. • When a new CrIS granule arrives, the system will wait for all the associated data (matching in time). Then, the NDE DHS will run the NUCAPS software units. • The thinned radiance product will be generated by a Subsetter software unit to the specifications indicated in the BUFR table (shown earlier) by the NUCAPS software units as a netCDF4 file. • The NUCAPS team will develop the BUFR table, but the tailoring of the netCDF4 into BUFR will be performed by the NDE DHS (outside of NUCAPS) running the netCDF4-to-BUFR tailoring tool (also to be built at STAR, but not by this project). • Distribution will be managed by NDE through their distribution system. • The CrIS BUFR table (needed by BUFR users) will be made available to users through NDE.

  50. NRL/FNMOC: Why Are The Products Being Produced? • NRL/FNMOC has requested 3 products: • Warmest CrIS FOV per FOR subset for ~600 channels picked by the NUCAPS development team. The same specifications as those for the JCSDA/NCEP product were okay with them. • They also wanted ascending/descending status for each CrIS FOV • Principal components from the warmest CrIS FOV per FOR subset in 3-bands with 200 components/band (same as what they receive for IASI). netCDF4 is an acceptable format. • The NUCAPS Retrieval product (especially O3, N2O, HNO3, CO2, CH4, and SO2) in netCDF4. • Within 3 hours of observation. • They do not yet know how many number of levels they want. • How were these determined? • NUCAPS development team talked and emailed Ben Ruston (NRL) and YiPing Wang (FNMOC) several times throughout 2008 to determine which products and what content they will need. • They are happy to get the same BUFR content as JCSDA/NCEP.

More Related