1. HDF5 for NPOESS Data Products Alan M. Goldberg The MITRE Corporation agoldber@mitre.org Organization: W803 Project: 1400NT01-SE This work was performed under NOAA contract 50-SPNA-9-00010. Opinions expressed are those of the author, and do not represent the United States Government. © 2002 The MITRE Corporation. All rights reserved.

2. The NPOESS Program l Products l Requirements l HDF Implementation (Presentation by Chad Fox / Raytheon)

3. Data Flow Overview Field Terminals and Centrals Application Processing, Display, & Dissemination FT Processor Element Central Central Element NPOESS-Unique Processing RF Electronics Demodulator C3S/DRR Space Segment NPOESS-Unique Collection Antenna User Terminal IDPSExternal I/F Other Data

4. Data Delivery to Users l Centrals * - National Environmental Satellite, Data, and Information Service - Naval Oceanography Command - Fleet Numerical Meteorology & Oceanography Command - Air Force Weather Agency l Field terminals * - US government - Private - Worldwide users l NESDIS Archives * l Misc - NASA (for NPP), SARSat, DCS, etc.

5. Major Product Relationships Environmental Phenomena PropagationSensor Sensor Scene Environmental Data Record Environment Model Sensor Model Sensor Data Record A0569F22 3B365CC 369B 707070FFF Comm Raw Data Record Packetized Data A0569F22 3B365CC 369B 707070FFF 10011 01100 11100 10011 01100 11100

6. Product Types l Major products - Raw data records * - Sensor Data Records * - Temperature Data Records * - Environmental data records * l Other - Raw data - Auxiliary data - Ancillary Data - Calibration & correction data - Telemetry & housekeeping - Memory dumps and diagnostics

7. Delivery Requirements l Operational *; platform independence; suitable for transmission, efficient conversion, and storage l Standards based: Interoperability*, consistent with Joint Technical Architecture and National Spatial Data Infrastructure l Rapid & available*: >95% delivered within 30 min. at Centrals; 15 min. goal l Self-documenting l Flexible for over 100 initial products l Flexible for evolutionary or new sensors and algorithms l User selectable aggregation (from one granule up to full orbit) l Delivery: Push or pull; Assured; Secure* l Efficient: 3 TB per day at each Central l Consistent interface for delivery to Centrals*, Field terminals*, & long term archives* * key requirement

8. Schedule l Interface with Centrals to be published (draft) in spring 2003. l First deliverable version of IDPS to be ready in spring 2005 for NPP risk-reduction mission in spring 2006 l Hardware specification for software support at field terminals to be published by Oct. 2005 l Operational system to be ready in mid 2008 for first NPOESS launch in mid 2009.

9. Issues l How much EOSDIS heritage to retain, if any, e.g. – whether to use EOS swath construct l Develop an NPOESS profile to handle particular attributes of NPOESS data, e.g. – variable length compressed packets in RDRs – conical scan geometry l Assure long-term stability of the standard l Provide user support l Suitability for archival use – HDF5 is primarily defined by its API, not the format

10. Backup

11. Data Processing Flow in IDPS Metadata Converted Mission Data Metadata Mission Data Packets Corr. Data Packets Auxiliary/ Telemtry/ Hskpng Data Packets Metadata Envi- ronment Data Ancillary Data RDR EDR Ancillary Data Packets LRD Only Converted Telemetry TDR/ SDR Format EDR Process Environ ment Model SDR Process Sensor Model Delivered Raw Data RDR Process Communi- cations Model SDR- like Process Product Interface to Users Local

12. Raw Data Granule Contents l CCSDS Application Packets, unprocessed, generally from one sensor over a short time interval l Mission data as produced by the sensor or payload l Telemetry l Calibration data & Correction parameters l Auxiliary data: spacecraft location & attitude

13. Sensor/Temperature Granule Contents l Radiometrically corrected data, which is an estimate of the flux at the sensor aperture. l Mission data by in-track position, cross-track position, channel, detector, etc. l Georeferenced in spacecraft coordinates, & intersection with the ellipsoid l Generally, not filtered, resampled, etc. l TDRs are microwave SDRs without antenna pattern removed

14. Environmental Data Granule Contents l SDRs processed with environmental models and ancillary data (by others) to produce estimates of environmental parameters l Reported as cross-track / in-track values identified in earth coordinates - unless resampling is specifically required

15. Metadata - Scope l Identifications: - Name / Level / Type-subtype / Sequential number l Description: - Start-end date-time; Start-end orbit - Subsatellite coordinates; Corner coordinates l History: - Space segment components / DRR components / Source files / Algorithm versions / Processing facility / Processing date-time l Contents: - Size / Granules - Predecessor quality / Missing data / Out-of-bounds / Processing errors / Quality free text l Formats: - Data elements / Structures / Formats

16. Metadata - Structure l As goal, all metadata will be compliant with NSDI standards - = “parameter”, where is defined by FGDC or the NPOESS extension profile. l Metadata will be hierarchical, as appropriate: - file-metadata l granule_metadata –scan_metadata »point_metadata l Metadata should map to the file naming convention l Metadata will be included with associated data files, and accessible as a stand-alone file.

17. Data l Hierarchical l Sensor specific format l “Internal” metadata, such as detailed geolocation, quality, annotation, illumination & view geometry

18. Why HDF5? l Familiarity -- Environmental scientists already have experience with the standard, most recently from EOS products. l Maturity -- HDF has shown its "staying power", and has been available long enough to have matured from user experiences. NASA, DOE, and others invested heavily in its development. l Capability -- HDF was designed to manage large, compound data sets within high performance computing environments. HDF5 incorporates new features that are important for NPOESS. l Compatibility -- HDF operates on multiple appropriate operating systems and languages: C, C++, Java and Fortran.

19. Why HDF5? (concluded) l Availability -- HDF was developed in the public interest at NCSA, and is freely available. HDF also has many free, share and commercial supports tools available. l Interoperability -- The DoD Joint Technical Architecture is in the process of accepting HDF as a standard for interoperability among DoD systems. l Efficiency – Low overhead compared with legacy formats: GRIB and BUFR. Efficient indexing and subsetting. Support for data compression.

20. Notional Structure -- external metadata granule_n granule_2 file_metadata summary_ metadata granule_ metadata granule_1 UniqueFileName.txt

21. Notional Structure -- HDF portion granule_n granule_2 metadatadata granule_1 UniqueFileName.hdf root other local_ metadata mission _data