MODIS

Science Software Delivery Guide

![](media/image1.pct){width="3.0131944444444443in"
height="3.636111111111111in"}

September 23, 2004

SDST-096

Revision C

MODIS

Science

Software Delivery Guide

**Prepared by:**

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Richard Hucek, STG Date

SDST Science Implementation Analyst

**Reviewed by:**

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Gladys Christopher-Knight, STG Date

SDST Configuration Manager

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Dr. Shirley Read, SAIC Date

SDST Systems Analyst

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Robert Wolfe, GSFC/Code 922 Date

MODIS Systems Engineer

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Dr. Ken Mitchell, SAIC/GSO Date

SDST Integration and Test Manager

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Dr. Michael Teague, SAIC/GSO Date

MODIS SDST Task Leader

**Approved by:**

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Edward J. Masuoka, GSFC/Code 922 Date

MODIS SDST Manager

Change Record Page

This document is baselined and has been placed under Configuration
Control. Any changes to this document will need the approval of the
Configuration Control Board.

+---------------+----------+--------------------+--------------------+
| **Document    |          |                    |                    |
| Title:**      |          |                    |                    |
| MODIS Science |          |                    |                    |
| Software      |          |                    |                    |
| Delivery      |          |                    |                    |
| Guide         |          |                    |                    |
|               |          |                    |                    |
| **Document    |          |                    |                    |
| Date:**       |          |                    |                    |
+---------------+----------+--------------------+--------------------+
| **Issue**     | **Date** | **Page Affected**  | **Description**    |
+---------------+----------+--------------------+--------------------+
| Original      | 5/7/97   | All                | Baseline           |
+---------------+----------+--------------------+--------------------+
| Change Notice | 6/17/97  | 33                 | CCR #323           |
| 1             |          |                    |                    |
+---------------+----------+--------------------+--------------------+
| Change Notice | 7/3/97   | TOC, 20, 23 - 30,  | CCR #s: 327 and    |
| 2             |          | 33                 | 330                |
+---------------+----------+--------------------+--------------------+
| Change Notice | 10/8/97  | 33                 | CCR #353           |
| 3             |          |                    |                    |
+---------------+----------+--------------------+--------------------+
| Revision A    | 11/13/97 | 32,33, 34, A-34    | CCR #s: 360 and    |
|               |          | thru A-39          | 366                |
+---------------+----------+--------------------+--------------------+
| Change Notice | 1/9/98   | A-34 thru A-40     | CCR #371           |
| 1             |          |                    |                    |
+---------------+----------+--------------------+--------------------+
| Revision B    | 3/26/98  | All                | CCR #s: 382, 385,  |
|               |          |                    | 386, 408           |
+---------------+----------+--------------------+--------------------+
| Change Notice | 12/3/98  | 30-32              | CCR 440            |
| 1             |          |                    |                    |
+---------------+----------+--------------------+--------------------+
| Revision C    | 9/23/04  | All                | Major Post Launch  |
|               |          |                    | Revisions          |
+---------------+----------+--------------------+--------------------+
|               |          |                    |                    |
+---------------+----------+--------------------+--------------------+
|               |          |                    |                    |
+---------------+----------+--------------------+--------------------+
|               |          |                    |                    |
+---------------+----------+--------------------+--------------------+
|               |          |                    |                    |
+---------------+----------+--------------------+--------------------+
|               |          |                    |                    |
+---------------+----------+--------------------+--------------------+
|               |          |                    |                    |
+---------------+----------+--------------------+--------------------+
|               |          |                    |                    |
+---------------+----------+--------------------+--------------------+
|               |          |                    |                    |
+---------------+----------+--------------------+--------------------+

MODIS

Science Software Delivery Guide

Table of Contents

# 1. Introduction [1](#introduction) {#introduction-1 .TOC-1}

## 1.1 Content and Structure [1](#content-and-structure) {#content-and-structure-1 .TOC-2}

# 2. Related Documentation [2](#related-documentation) {#related-documentation-2 .TOC-1}

## 2.1 Parent Documents [2](#parent-documents) {#parent-documents-2 .TOC-2}

## 2.2 Applicable Documents [2](#applicable-documents) {#applicable-documents-2 .TOC-2}

## 2.3 Informational Documents [2](#informational-documents) {#informational-documents-2 .TOC-2}

## 2.4 Universal Resource Locators [3](#universal-resource-locators) {#universal-resource-locators-3 .TOC-2}

## 2.5 MODIS FTP Sites [4](#modis-ftp-sites) {#modis-ftp-sites-4 .TOC-2}

# 3. Development Approach [5](#development-approach) {#development-approach-5 .TOC-1}

## 3.1 Delivery Schedule and Dependencies [5](#delivery-schedule-and-dependencies) {#delivery-schedule-and-dependencies-5 .TOC-2}

## 3.2 Pre-Delivery Material [6](#pre-delivery-material) {#pre-delivery-material-6 .TOC-2}

### 3.2.1 Product Change Requests [6](#product-change-requests) {#product-change-requests-6 .TOC-3}

#### 3.2.1.1 PCR Levels [6](#pcr-levels) {#pcr-levels-6 .TOC-4}

#### 3.2.1.2 Prerequisite to Filing PCR [7](#prerequisite-to-filing-pcr) {#prerequisite-to-filing-pcr-7 .TOC-4}

### 3.2.2 Product File Specifications [7](#product-file-specifications) {#product-file-specifications-7 .TOC-3}

### 3.2.3 Production Rules [7](#production-rules) {#production-rules-7 .TOC-3}

#### 3.2.3.1 Production Considerations/Rules [8](#production-considerationsrules) {#production-considerationsrules-8 .TOC-4}

#### 3.2.3.2 Interim Files [8](#interim-files) {#interim-files-8 .TOC-4}

#### 3.2.3.3 Ancillary Data [8](#ancillary-data) {#ancillary-data-8 .TOC-4}

#### 3.2.3.4 Exit Codes [8](#exit-codes) {#exit-codes-8 .TOC-4}

#### 3.2.3.5 Temporary Files [9](#temporary-files) {#temporary-files-9 .TOC-4}

#### 3.2.3.6 Browse Files [9](#browse-files) {#browse-files-9 .TOC-4}

### 3.2.4 Coding Standards and Practices [9](#coding-standards-and-practices) {#coding-standards-and-practices-9 .TOC-3}

## 3.3 Process Control Files [9](#process-control-files) {#process-control-files-9 .TOC-2}

## 3.4 Status Message Facility Seed Numbering [10](#status-message-facility-seed-numbering) {#status-message-facility-seed-numbering-10 .TOC-2}

## 3.5 HDF-EOS Guidelines [10](#hdf-eos-guidelines) {#hdf-eos-guidelines-10 .TOC-2}

### 3.5.1 Swath Recommendations [11](#swath-recommendations) {#swath-recommendations-11 .TOC-3}

#### 3.5.1.1 Swath Membership [11](#swath-membership) {#swath-membership-11 .TOC-4}

#### 3.5.1.2 Geolocation Information [11](#geolocation-information) {#geolocation-information-11 .TOC-4}

#### 3.5.1.3 Merging Data Arrays [13](#merging-data-arrays) {#merging-data-arrays-13 .TOC-4}

#### 3.5.1.4 Swath Naming [13](#swath-naming) {#swath-naming-13 .TOC-4}

### 3.5.2 Grid Recommendations [13](#grid-recommendations) {#grid-recommendations-13 .TOC-3}

#### 3.5.2.1 Grid Membership [13](#grid-membership) {#grid-membership-13 .TOC-4}

#### 3.5.2.2 Georeferencing Information [13](#georeferencing-information) {#georeferencing-information-13 .TOC-4}

#### 3.5.2.3 Merging Data Arrays [16](#merging-data-arrays-1) {#merging-data-arrays-16 .TOC-4}

#### 3.5.2.4 Grid Naming [16](#grid-naming) {#grid-naming-16 .TOC-4}

## 3.6 Metadata [16](#metadata) {#metadata-16 .TOC-2}

### 3.6.1 Background [16](#background) {#background-16 .TOC-3}

### 3.6.2 ECS Metadata Implementation [17](#ecs-metadata-implementation) {#ecs-metadata-implementation-17 .TOC-3}

#### 3.6.2.1 Metadata Configuration File [17](#metadata-configuration-file) {#metadata-configuration-file-17 .TOC-4}

#### 3.6.2.2 Science Data Production Toolkit Metadata Tools [19](#science-data-production-toolkit-metadata-tools) {#science-data-production-toolkit-metadata-tools-19 .TOC-4}

#### 3.6.2.3 Metadata Toolkit Programming Hints [20](#metadata-toolkit-programming-hints) {#metadata-toolkit-programming-hints-20 .TOC-4}

#### 3.6.2.4 MODIS-Application Program Interface [20](#modis-application-program-interface) {#modis-application-program-interface-20 .TOC-4}

### 3.6.3 Metadata Lists [21](#metadata-lists) {#metadata-lists-21 .TOC-3}

### 3.6.4 Integration into MODIS Processing Software [28](#integration-into-modis-processing-software) {#integration-into-modis-processing-software-28 .TOC-3}

### 3.6.5 Metadata Setting Guidelines [28](#metadata-setting-guidelines) {#metadata-setting-guidelines-28 .TOC-3}

#### 3.6.5.1 Product Identification Attributes [29](#product-identification-attributes) {#product-identification-attributes-29 .TOC-4}

#### 3.6.5.2 Spatial Metadata [29](#spatial-metadata) {#spatial-metadata-29 .TOC-4}

#### 3.6.5.3 Time Range [30](#time-range) {#time-range-30 .TOC-4}

#### 3.6.5.4 Quality Assurance Attributes [31](#quality-assurance-attributes) {#quality-assurance-attributes-31 .TOC-4}

#### 3.6.5.5 Reprocessing [31](#reprocessing) {#reprocessing-31 .TOC-4}

#### 3.6.5.6 Product-Specific Attributes [32](#product-specific-attributes) {#product-specific-attributes-32 .TOC-4}

#### 3.6.5.7 Tracking and Production Archived Metadata Attributes [32](#tracking-and-production-archived-metadata-attributes) {#tracking-and-production-archived-metadata-attributes-32 .TOC-4}

## 3.7 Testing Approach [33](#testing-approach) {#testing-approach-33 .TOC-2}

### 3.7.1 Processing Host [33](#processing-host) {#processing-host-33 .TOC-3}

### 3.7.2 Anomalous Data Conditions 34 {#anomalous-data-conditions-34 .TOC-3}

### 3.7.3 Ancillary/Alternative Data Identification [35](#ancillaryalternative-data-identification) {#ancillaryalternative-data-identification-35 .TOC-3}

## 3.8 Process Versioning [35](#process-versioning) {#process-versioning-35 .TOC-2}

# 4. Delivery Process [36](#delivery-process) {#delivery-process-36 .TOC-1}

## 4.1 Delivery Process Overview [36](#delivery-process-overview) {#delivery-process-overview-36 .TOC-2}

## 4.2 Algorithm Delivery Package Contents [37](#algorithm-delivery-package-contents) {#algorithm-delivery-package-contents-37 .TOC-2}

## 4.3 File Naming Conventions [38](#file-naming-conventions) {#file-naming-conventions-38 .TOC-2}

### 4.3.1 Delivery Package Files [38](#delivery-package-files) {#delivery-package-files-38 .TOC-3}

### 4.3.2 Product File Names [40](#product-file-names) {#product-file-names-40 .TOC-3}

#### 4.3.2.1 Level-1A, Level-1B, and Level-2 Product Naming Convention [40](#level-1a-level-1b-and-level-2-product-naming-convention) {#level-1a-level-1b-and-level-2-product-naming-convention-40 .TOC-4}

#### 4.3.2.2 Level-2G , Level-3 and Level-4 Product Naming Convention [40](#level-2g-level-3-and-level-4-product-naming-convention) {#level-2g-level-3-and-level-4-product-naming-convention-40 .TOC-4}

#### 4.3.2.3 Level-3 Product Naming Convention (Oceans) [41](#level-3-product-naming-convention-oceans) {#level-3-product-naming-convention-oceans-41 .TOC-4}

#### 4.3.2.4 Browse Product Naming Convention [41](#browse-product-naming-convention) {#browse-product-naming-convention-41 .TOC-4}

#### 4.3.2.5 File Naming Examples [41](#file-naming-examples) {#file-naming-examples-41 .TOC-4}

## 4.4 Acceptance and Baselining Process [42](#acceptance-and-baselining-process) {#acceptance-and-baselining-process-42 .TOC-2}

### 4.4.1 Configuration Management Officer Responsibilities [43](#configuration-management-officer-responsibilities) {#configuration-management-officer-responsibilities-43 .TOC-3}

### 4.4.2 Directory Structure and Access [43](#directory-structure-and-access) {#directory-structure-and-access-43 .TOC-3}

### 4.4.3 Scripts and Their Usage [44](#scripts-and-their-usage) {#scripts-and-their-usage-44 .TOC-3}

## 4.5 Iterations with SDST SSTG Staff [45](#iterations-with-sdst-sstg-staff) {#iterations-with-sdst-sstg-staff-45 .TOC-2}

## 4.6 Aqua and Terra Specific PGEs [46](#aqua-and-terra-specific-pges) {#aqua-and-terra-specific-pges-46 .TOC-2}

## 4.7 Combined Product Generation [46](#combined-product-generation) {#combined-product-generation-46 .TOC-2}

# 5. Programming Guidelines/Recommendations [48](#programming-guidelinesrecommendations) {#programming-guidelinesrecommendations-48 .TOC-1}

## 5.1 Production System Related Items [48](#production-system-related-items) {#production-system-related-items-48 .TOC-2}

## 5.2 Platform Related Items [48](#platform-related-items) {#platform-related-items-48 .TOC-2}

# APPENDIX A: ACRONYMS A-1 {#appendix-a-acronyms-a-1 .TOC-1}

# APPENDIX B: PRODUCTION RULE EXAMPLE A-3 {#appendix-b-production-rule-example-a-3 .TOC-1}

# APPENDIX C: HDF-EOS AND GRID EXAMPLES A-5 {#appendix-c-hdf-eos-and-grid-examples-a-5 .TOC-1}

## C.1 HDF-EOS Example 1: Swath with Full Resolution External Geolocation Data Set A-5 {#c.1-hdf-eos-example-1-swath-with-full-resolution-external-geolocation-data-set-a-5 .TOC-2}

### C.1.1 Code A-5 {#c.1.1-code-a-5 .TOC-3}

### C.1.2 Corresponding Sample File Specification Addendum A-5 {#c.1.2-corresponding-sample-file-specification-addendum-a-5 .TOC-3}

### C.1.3 Output File A-6 {#c.1.3-output-file-a-6 .TOC-3}

## C.2 HDF-EOS Example 2: Single Swath with High Resolution Data Array A-8 {#c.2-hdf-eos-example-2-single-swath-with-high-resolution-data-array-a-8 .TOC-2}

### C.2.1 Code A-8 {#c.2.1-code-a-8 .TOC-3}

### C.2.2 Corresponding Sample File Specification Addendum A-9 {#c.2.2-corresponding-sample-file-specification-addendum-a-9 .TOC-3}

### C.2.3 Output File A-10 {#c.2.3-output-file-a-10 .TOC-3}

## C.3 Grid Example 1: Geographic Map Projection A-20 {#c.3-grid-example-1-geographic-map-projection-a-20 .TOC-2}

### C.3.1 Code A-20 {#c.3.1-code-a-20 .TOC-3}

### C.3.2 Corresponding Sample File Specificaton Addendum A-22 {#c.3.2-corresponding-sample-file-specificaton-addendum-a-22 .TOC-3}

### C.3.3 Output File A-22 {#c.3.3-output-file-a-22 .TOC-3}

## C.4 Grid Example 2: Sinusoidal Map Projection A-24 {#c.4-grid-example-2-sinusoidal-map-projection-a-24 .TOC-2}

### C.4.1 Code A-24 {#c.4.1-code-a-24 .TOC-3}

### C.4.2 Corresponding Sample File Specificaton Addendum A-26 {#c.4.2-corresponding-sample-file-specificaton-addendum-a-26 .TOC-3}

### C.4.3 Output File A-27 {#c.4.3-output-file-a-27 .TOC-3}

# APPENDIX D: PACKING LIST CONTENTS A-30 {#appendix-d-packing-list-contents-a-30 .TOC-1}

# APPENDIX E: README FILE CONTENTS A-31  {#appendix-e-readme-file-contents-a-31 .TOC-1}

# APPENDIX F: MAKEFILE STANDARDS AND EXAMPLES A-32 {#appendix-f-makefile-standards-and-examples-a-32 .TOC-1}

## F.1 Makefile Standards A-32 {#f.1-makefile-standards-a-32 .TOC-2}

## F.2 Example of C MAKEFILE A-34 {#f.2-example-of-c-makefile-a-34 .TOC-2}

## F.3 Example of FORTRAN MAKEFILE A-37 {#f.3-example-of-fortran-makefile-a-37 .TOC-2}

# APPENDIX G: PROCESSING FILE FORMAT DESCRIPTION A-40 {#appendix-g-processing-file-format-description-a-40 .TOC-1}

## G.1 Processing File Format Description Template A-40 {#g.1-processing-file-format-description-template-a-40 .TOC-2}

## G.2 Processing File Format Description Example A-41 {#g.2-processing-file-format-description-example-a-41 .TOC-2}

# APPENDIX H: PROCESS CONTROL FILE STANDARDS AND EXAMPLE A-43 {#appendix-h-process-control-file-standards-and-example-a-43 .TOC-1}

## H.1 Process Control File Standards A-43 {#h.1-process-control-file-standards-a-43 .TOC-2}

## H.2 Process Control File Example A-44 {#h.2-process-control-file-example-a-44 .TOC-2}

# APPENDIX I: METADATA CONFIGURATION FILE EXAMPLES A-57 {#appendix-i-metadata-configuration-file-examples-a-57 .TOC-1}

# APPENDIX J: CHECKLIST FOR ITEMS TO ACCOMPANY DELIVERY A-74 {#appendix-j-checklist-for-items-to-accompany-delivery-a-74 .TOC-1}

# APPENDIX K: CHECKLIST FOR CODING REQUIREMENTS A-75 {#appendix-k-checklist-for-coding-requirements-a-75 .TOC-1}

# APPENDIX L: C LANGUAGE EXAMPLES OF METADATA TOOL USAGE A-76 {#appendix-l-c-language-examples-of-metadata-tool-usage-a-76 .TOC-1}

## L.1 PGS_MET_Init A-76 {#l.1-pgs_met_init-a-76 .TOC-2}

## L.2 PGS_PC_GetConfigData A-76 {#l.2-pgs_pc_getconfigdata-a-76 .TOC-2}

## L.3 getMODISECSinfo A-77 {#l.3-getmodisecsinfo-a-77 .TOC-2}

## L.4 PGS_MET_GetPCAttr A-77 {#l.4-pgs_met_getpcattr-a-77 .TOC-2}

## L.5 PGS_MET_SetAttr A-78 {#l.5-pgs_met_setattr-a-78 .TOC-2}

## L.6 completeMODISfile A-78 {#l.6-completemodisfile-a-78 .TOC-2}

## L.7 PGS_MET_Write A-78 {#l.7-pgs_met_write-a-78 .TOC-2}

# APPENDIX M: SCF TEMPLATE FOR REQUIRED METADATA A-80 {#appendix-m-scf-template-for-required-metadata-a-80 .TOC-1}

# APPENDIX N: BROWSE FORMAT EXAMPLE A-91 {#appendix-n-browse-format-example-a-91 .TOC-1}

# APPENDIX O: PCR FORM A-95  {#appendix-o-pcr-form-a-95 .TOC-1}

List of Tables

Table 2-1. Universal Resource Locators [3](#__RefHeading___Toc80090112)

Table 2-2. FTP Sites [4](#__RefHeading___Toc80090113)

Table 3-1. ECS Core Inventory Metadata Attributes
[23](#__RefHeading___Toc80090114)

Table 3-2. MODIS Archived Metadata Attributes
[25](#__RefHeading___Toc80090115)

Table 3-3. Collection Metadata Attributes
[26](#__RefHeading___Toc80090116)

Table 4-1. Naming Conventions [39](#__RefHeading___Toc80090117)

Table 4-2. Submittal Package Acceptance/Baselining Scripts
[44](#__RefHeading___Toc80090118)

MODIS

Science Software Delivery Guide

# Introduction

Moderate Resolution Imaging Spectroradiometer (MODIS) science software
is developed by the MODIS Science Team at various Science Computing
Facilities (SCF) around the country and even abroad. This software
supports NASA's Mission to Planet Earth (MTPE), Earth Observing System
(EOS) program on the Aqua and Terra Missions, both of which contain
MODIS instruments that are currently active. Most MODIS science
algorithms (referred to as PGEs - Product Generation Executives) are
already mature and running operationally at either the Goddard Space
Flight Center (GSFC) Distributed Active Archive Center (GDAAC) or in the
MODIS Adaptive Processing System (MODAPS), also located at GSFC. The
maintenance of existing codes and the addition of completely new
algorithms require the science team member (STM) to submit a PGE
delivery package to the Science Data Support Team (SDST) at the Team
Leader Computing Facility (TLCF). The delivery package is checked for
conformance to MODIS and project standards, integrated into the MODIS
system and science tested prior to promotion into operational use.

This document defines the material to be delivered by the Science Team
Members (STMs) to SDST and describes the interactions between the STM
and SDST personnel in accomplishing this delivery process. It also
provides information to enable the STM to develop software capable of
running in the EOS Core System (ECS) production system. It covers topics
such as coding standards, file specifications, metadata usage,
Hierarchical Data Format (HDF)-EOS usage, Science Data Processing (SDP)
Toolkit usage, map projections, and other science software related
information.

## Content and Structure

This document is organized into the following sections:

-   Section 1 contains the introduction and structure of this document.

-   Section 2 identifies the related documentation.

-   Section 3 describes the development approach.

-   Section 4 describes the delivery process.

-   Section 5 describes the programming guidelines and recommendations.

-   Appendix A identifies the acronyms included in this document.

-   Appendix B provides an example of the Production Rules for Product
    Generation Executives (PGEs).

-   Appendix C provides examples of HDF-EOS .

-   Appendix D provides the information required for Packing Lists.

-   Appendix E provides a template for README files.

-   Appendix F describes the Makefile standards and gives example
    templates for C and FORTRAN code.

-   Appendix G provides the processing file format description template
    and example.

-   Appendix H defines the Process Control File (PCF) standards and
    shows an example file.

-   Appendix I provides examples of Metadata Configuration Files
    (MCF's).

-   Appendix J provides a checklist of required delivery items.

-   Appendix K provides a coding requirements checklist.

-   Appendix L provides an example of a metadata tool usage in C.

-   Appendix M exemplifies an on-line template for defining and
    requesting required and frequently used optional ECS metadata for
    new ESDTs.

-   Appendix N illustrates a typical browse data format.

-   Appendix O contains a copy of the Process Change Request Form.

# related Documentation

This section provides documentation relevant to the MODIS Science
Software Delivery Guide. Sections 2.4 and 2.5 list the WWW Universal
Resource Locator (URL) or ftp site where MODIS STMs can find the Earth
Observing System Data and Information System (EOSDIS) documents listed
below and other helpful information for launch-ready software delivery.

## Parent Documents

-   Team Leader Working Agreement for MODIS Between EOS AM & PM Projects
    GSFC and the MODIS Science Team Leader; GSFC 421-12-14-02; April
    1994.

-   MODIS Science Data Processing Software Requirements Specification,
    Version 2 and Beyond; SDST-089; December 1996.

## Applicable Documents

-   MODIS Software Development Standards and Guidelines; SDST-022C;
    January 1997.

-   Release 6B Implementation Earth Science Data Model for the ECS
    Project; 420-TP-023-002; October 2002.

-   An ECS Data Provider\'s Guide to Metadata; 163-WP-001-001; January
    1997.

-   SDP Toolkit Primer for the ECS Project; 194-815-S14-001; June 11,
    1997.

-   Release 6A.07 SDP Toolkit User's Guide for the ECS Project;
    333-CD-605-003; March 2003.

-   Version 2 Science Software Integration and Test Procedures and
    Agreement with the EDC DAAC; SDST-108; Final Review; March 1998.

-   Version 2 Science Software Integration and Test Procedures and
    Agreement with the GSFC DAAC; March 1998.

-   Version 2 Science Software Integration and Test Procedures and
    Agreement with the NSDIC DAAC; Review; SDST-109.

## Informational Documents

The following documents were used for requirements information in this
Delivery Guide.

-   Data Production Software (DPS) and Science Computing Facility (SCF)
    Standards and Guidelines; EOSDIS 423-16-01, Rev. A; October 1996.

-   Interface Control Document Between the EOSDIS Core System (ECS) and
    Science Computing Facilities (SCFs); EOSDIS 505-41-33; Rev. D;
    October 2002.

-   MODIS Configuration Management Plan; SDST-004; June 30,1995.

-   Science User's Guide and Operations Procedure Handbook Volume 4;
    Software Developer's Guide to Preparation, Delivery, Integration,
    and Test with the ECS; 205-CD-002-006; February 1998.

The following documents were used to collect information for this
Delivery Guide.

-   MODIS-Application Program Interface (MAPI) User's Guide, Version
    2.1; SDST-064A; January 1997.

-   MODIS Data Management Plan; SDST-006; October 25, 1995.

-   MODIS SDST Software Quality Assurance Plan; SDST-003; June 30, 1995.

-   MODIS Software Management Plan; SDST-002; March 24, 1996.

-   MODIS Product Volumes and Process Load Estimates; SDST-009; August
    11, 1995.

-   MODIS Version 1 TLCF Integration and Test Plan; SDST-060; July 8,
    1996.

-   MODIS Version 1 Science Computing Facility Software Delivery Guide;
    SDST-066; December 4, 1996.

-   HDF-EOS 2.7 Version Description Document for the ECS Project;
    814-RD-601-01; November 2000.

-   Writing HDF-EOS Grid Products for Optimum Subsetting Services;
    170-TP-007-001; December 1996.

-   Writing HDF-EOS Swath Products for Optimum Subsetting Services;
    170-TP-009-001; December 1996.

-   MODIS Science Data Processing Software Version 4.0 Syetem
    Description, SDST_119B; May 2004.

## Universal Resource Locators

The URLs listed in Table 2-1 should be used to access the
documents/material referenced in this document.

[]{#__RefHeading___Toc80090112 .anchor}Table 2-1. Universal Resource
Locators

  ----------------------------------------------------------------- ------------------------
  **URL**                                                           **Material**

  http://modis.gsfc.nasa.gov/                                       MODIS home page

  http://edhs1.gsfc.nasa.gov/                                       ECS documents

  http://ltpwww.gsfc.nasa.gov/MODIS/SDST/documents.html             MODIS SDST documents

  http://edhs1.gsfc.nasa.gov/waisdata/toc/cd33360503toc.html        SDP Toolkit (V6A.07) SCF
                                                                    User\'s Guide

  <http://newsroom.gsfc.nasa.gov/sdptoolkit/primer/tkprimer.html>   SDP Toolkit Primer for
                                                                    the ECS Project

  http://hdf.ncsa.uiuc.edu/                                         HDF information

  http://hdfeos.gsfc.nasa.gov/hdfeos/index.cfm                      HDF-EOS information
  ----------------------------------------------------------------- ------------------------

## MODIS FTP Sites

The ftp sites listed in Table 2-2 should be used to send/return material
between the STMs and SDST. Unless otherwise indicated, the ftps
referenced in this document are accessed from:
**ftp://ltpftp.gsfc.nasa.gov/projects/modis/\...**.

[]{#__RefHeading___Toc80090113 .anchor}Table 2-2. FTP Sites

+------------------------------+---------------------------------------+
| **FTP Site**                 | **Material**                          |
+------------------------------+---------------------------------------+
| ftp://ltpftp\                | MODIS Logical Unit Numbers            |
| ...delivery/tables/LUN.table |                                       |
+------------------------------+---------------------------------------+
| ftp://                       | MODIS templates for README files,     |
| ltpftp\...delivery/templates | Packing Lists, File Descriptions, and |
|                              | PCFs                                  |
+------------------------------+---------------------------------------+
| ftp://ltpftp\...documents    | MODIS CM-controlled documents         |
+------------------------------+---------------------------------------+
| ftp://modular.nascom.        | MODIS File specifications             |
| nasa.gov/pub/LatestFilespecs |                                       |
+------------------------------+---------------------------------------+
| ft                           | MODIS CM baselined code               |
| p://modular.nascom.nasa.gov/ |                                       |
|                              |                                       |
| modisbaselinedcode           |                                       |
+------------------------------+---------------------------------------+

#  Development Approach

The approach used for the development of MODIS science data processing
software is based on methodologies used in the current, proven MODIS
system. It includes:

-   STMs develop and deliver to SDST/Science Software Transfer Group
    (SSTG) robust data processing code, containing their science
    algorithms, based on recommendations and procedures supplied by
    SSTG. There is an expectation that:

```{=html}
<!-- -->
```
-   delivered science algorithms have been tested to run successfully on
    one or more of the computer hosts employed in MODAPS using the
    actual MODIS and ancillary data products that are planned as inputs
    to the PGE;

-   and that the science software closely represents the algorithm
    description provided in the Algorithm Theoretical Basis Document
    (ATBD).

```{=html}
<!-- -->
```
-   SSTG packages the STMs' delivered code into PGEs and processing
    scripts for operational processing in MODAPS or in ECS at the GSFC
    DAAC.

-   SDST integrates and tests the PGEs and processing scripts in a
    series of separate MODAPS environments:

```{=html}
<!-- -->
```
-   A MODAPS instance for SSTG testing of PGEs, scripts, and MODAPS
    loader modules.

-   A MODAPS instance for PGE and system integration and test
    activities.

-   A MODAPS instance for science test activities on new and changed
    PGEs.

```{=html}
<!-- -->
```
-   A Product Change Request (PCR) process that requires new and
    scientifically changed PGEs to meet the approval of the MODIS
    Science Discipline Teams and be authorized for operations by the
    MODIS Science Team Leader.

The following sections describe the delivery process, pre-delivery
material, and MODIS and project standards and conventions for product
file specifications, coding practices, HDF-EOS use, metadata
requirements, PCF standards, and test approaches. Adherence to these
standards will simplify the delivery process and facilitate integration
and science testing in MODAPS and at the GDAAC. Note especially, that at
MODAPS L2 and L3 PGEs run on both IRIX and Linux hosts. This makes it
imperative that the MODIS science algorithms be developed and tested for
portability on both platforms. (See Section 3.7 Testing Approach)

## Delivery Schedule and Dependencies

The basic series of events involved in delivery to MODAPS or to the GSFC
DAAC are as follows:

-   SSTG verification of delivered software;

-   SSTG submittal of science software package to CMO;

-   SDST test team thread testing of the delivered Science Software
    PGEs;

-   Science Test for Science Changes, and;

-   Submittal to MODAPS or to the GSFC DAAC.

The SSTG Code Acceptance Process, which describes the interactions
between SSTG and the SCFs in developing the code, and the orderly
sequence of events followed from the time the code is first received
until its final delivery from SSTG to the SDST CMO is designed to ensure
that the code meets all Earth Science Data and Information System
(ESDIS) coding requirements, that the code is ready for MODAPS or the
EOSDIS production environment, and that the science products can be
archived in the EOSDIS production environment.

## Pre-Delivery Material

New PGEs and changes to existing PGEs may impose new system processing
requirements and PGE interactions. It is paramount in these cases to
acquire the material targeted for the delivery package prior to software
submittal.

The pre-delivery material/information needed includes:

-   Product Change Request

-   Product file specifications - layout, content, size.

-   Production Rules.

Once these pre-delivery materials are received, changes to them will be
made in a controlled fashion to enable assessment of the impact of the
proposed changes on system performance and requirements. Changes to the
above items have a significant bearing on the ability of the processing
system to produce the desired products in a timely fashion. These affect
the sizing of the system, the downstream processing (which relies on the
upstream product specifications to provide parameters as indicated in
the file specifications) and scheduling requirements of the system.
Changes to the product file specifications will be subjected to a formal
review process. The process definitions impact the sizing of the system
and the external interfaces for data sources which impact the system
architecture. Although not controlled in the same manner as product file
specifications these are needed early on in the process and should be
somewhat stable to allow for proper design of the system.

### Product Change Requests

PCR forms (See PCR Form in Appendix O) are currently filed with the
MODIS Systems Engineer, who investigates the PCR, coordinates with the
STM as appropriate, and makes a recommendation to the Team Leader as to
its disposition. The Team Leader is the final authority on the PCR.

#### PCR Levels

There are four levels of PCRs.

Type1: Minor bug fixes which correct or improve known problems (or that
improve QA/metadata/intermediate products) with no significant impact on
the distributed data product or on continuous time-series record. No
reprocessing is needed as a result of these fixes.

Type 2: Changes that fix broken code that is generating bad or no data
in current production. Such changes may or may not warrant additional
reprocessing. If reprocessing associated with this change is required,
it must be accompanied by a strong rationale.

Type 3: Major changes to the science code that result in a
scientifically signficant discontinuity to the product and has
downstream impacts and reprocessing implications for a continuous data
set.

Type 4: New code for products that have yet to be made.

#### Prerequisite to Filing PCR

What to do before filing a PCR:

-   Understand the requirement for the change.

-   Ensure that the change is approved by the MODIS Science Discipline
    Lead.

-   If the change involves a non-backward compatible file spec change,
    discuss it with SDST personnel and get their agreement before
    proceeding.

### Product File Specifications

MODIS Standard data products are formatted in National Center for
Supercomputing Applications (NCSA) Heirarchical Data Format (HDF) 4 with
EOS (Earth Observing System) extensions for swath and grid data products
know collectively as HDF-EOS and described in more detail in Section
3.5. Product file specifications define the parameters and describe the
format of the MODIS data products. These file specifications are used by
developers of downstream processes to know what parameters are being
produced by upstream processes. The developers of downstream processes
can also use the file specifications to know how to access the file in
the most efficient manner. Therefore, these should be baselined early in
the process to allow for development of downstream algorithms and
development of file access toolkits. Once the STM has established the
file specification, it will be baselined in the fashion discussed in
Section 4 where the STM will deliver it to the SSTG and the
acceptance/baselining process is followed. Subsequent to baselining,
changes to the product file specification will require a Process Change
Request (PCR) to be written and Team Leader approval before changes to
the product specification are implemented.

### Production Rules

Production rules describe how to initiate execution of the process, what
data are required for the process, what interim products and standard,
archived products are generated by the process, what the exit codes
represent, and what temporary files are generated.

MODAPS offers a variety of search capabilities to support flexible
production rules development, particularly in the selection of dynamic
MODIS and ancillary product input granules. A representative Level 3
data requirement, for example, might be to stage all granules of a
specified ESDT in a day that overlap a given spatial tile. To enable
rules like this and others, MODAPS supports queries on the following
granule attributes, either alone or in combination:

> ESDT
>
> StartTime/EndTime
>
> OrbitNumber
>
> Day/Night Flag
>
> BoundingCoordinate
>
> GRingLatitude/Longitude
>
> TileID

Production rules need further definition through the identification of
required versus optional inputs. If required, a processing request will
not be initiated until the required files are staged to the PGE. In
contrast, optional products are not needed to ensure successful
processing of a PGE and their absence does not significantly impact the
output product quality. In this case, MODAPS allows the PGE to run,
after an acceptable wait period, even if the optional inputs are still
unavailable to the system.

#### Production Considerations/Rules

Production rules indicate to the scheduling system which files need to
be staged, how long to wait for files, and what alternatives are
available. Appendix B provides an example of the production rule
information needed for each process. Additional information on
production rules is available at the ECS Information for Scientists web
page (see Table 2-1).

In general, production rules for a process spell out the following:

-   Frequency of execution.

-   Input product files requirements.

-   Input ancillary data file requirements.

-   Input static file requirements.

-   Backup data strategies.

-   Output product description.

#### Interim Files

Some processes generate interim products which are then used to create
the final output products. The STMs need to identify the existence of
these files, the size of the files, and how/when these files can be
removed from the systems. This affects the way the PGE gets executed in
the production system and where the files reside. Interim products are
handled by the production system in the same manner as final products
except that they are not accessible by external users and are not
permanently archived.

#### Ancillary Data

The STMs need to identify which ancillary data files are needed and the
fall-back strategy to be employed. The STMs should specify these
ancillary data requirements as part of the pre-delivery package so the
information can be captured in the MODIS Science Data Processing
Software System Description document. Additionally, the STMs need to
identify the fall-back strategy to be employed if the primary data set
is unavailable. An example of a fall-back strategy is "use the most
recent version if the current version is not available". Another example
is to "use the most recent files in the time period 0600 to 1200".

The types of questions to be answered by this fall back strategy
include: Should the process wait forever until that data set is
available? Should an alternative be selected? Is there a time beyond
which if no files are available, processing should be initiated anyway?

#### Exit Codes

Exit codes are used to communicate to the scheduler component of the
production system. There are two basic values used in MODIS: 0 indicates
success and 1 indicates failure. Success indicates that the process
terminated with no errors. Failure means process terminated due to an
error.

#### Temporary Files

Some of the processes use temporary files during their execution. These
files are created by the process and must be deleted by the process
before exiting. The STMs should include estimated sizes and the number
of these types of files in their process description as part of the
pre-delivery material. These files do not include the temporary files
created by the SDPTK (Science Data Processing Toolkit).

#### Browse Files

Browse data enables users who are ordering data to preview the product
to better identify specific products that meet their needs (i.e., to
eliminate products with too much cloud cover). These files are linked to
the corresponding product files before they are transmitted to the
DAACs. Browse data are written in HDF format and contain one or more
JPEG image fields with minimal metadata (see example in Appendix M).

### Coding Standards and Practices

Science software is expected to conform to the MODIS Software
Development Standards and Guidelines document. SSTG personnel will work
with the STMs to ensure the software delivered for Integration and Test
adheres to MODIS Software Development Standards and Guidelines.

## Process Control Files

Each MODIS Process (MOD_PRxx) delivered by the STM must contain a
Process Control File (PCF) consistent with the version of the SDPTK used
at the SCF. The PCF identifies input and output files accessed by the
process as well as Runtime Parameters for directing processing flow and
documenting configuration (e.g. run on Linux or IRIX host). Processes
using one or more LUT files as input shall verify the identity of each
by comparing version information within the LUT against a PCF
configuration parameter set to value of the expected version string. If
the LUT value differs from the PCF setting, the process will issue a log
message explaining the problem and then cease execution.

At SDST, science integration analysts will run a PCF checker utility
(pccheck.sh - found in the bin directory of the SDPTK) as part of their
delivery-package evaluation. PCF standards and a sample PCF are shown in
Appendix H. The PCF template can be found on the MODIS ftp site (see
Table 2.2). It is essential that no lines be removed from the template
format to ensure compatibility at the DAAC.

The following numbering scheme for the PCF logical numbers has been
established by SDST and should be followed by the developers to prevent
logical number "collisions" (i.e., two processes in the same PGE using
the same logical number for referencing different files) when thread
testing begins:

Land: 200,000-299,999

Ocean: 300,000-399,999

Atmosphere: 400,000-499,999

Level 1A (L1A): 500,000-599,999

Geolocation: 600,000-699,999

Level 1B (L1B): 700,000-799,999

The SSTG lead in each of the land, ocean, and atmosphere disciplines
will be responsible for coordinating the distribution of discipline LUNs
among developers. It is preferable to establish process LUN numbers
early in the development period by contacting the SDST science
integration discipline lead.

## Status Message Facility Seed Numbering

The ECS Status Message Facility (SMF) provides an error and message
handling capability for use in science software. At the heart of the SMF
is the status message text file or "seed" file. A seed file is, in
essence, a listing or dictionary of mnemonic names linked to specified
message content. The mnemonic names are referenced directly by the PGE
to aid the process of logging status messages, especially those
occurring frequently. More detailed information regarding the format,
content and usage of "seed" files is available in the SDP Toolkit Primer
for the ECS Project (See Table 2-1 for on-line access to SDP Toolkit
Primer).

The numbering scheme for the Status Message File (SMF) seed numbering
assignments used by the software processes to log error messages to the
Science Data Production Toolkit (SDPTK) should be in accordance with the
following discipline-specific ranges for SMF numbering:

L1A: 35000 to 35500

L1B: 36000 to 36500

Land: 37000 to 37500

Ocean: 38000 to 38500

Atmosphere: 39000 to 39500

Common: 39501 to 39999, includes:

39501 for Global SMF messages

39601 for PGE Scripts

As with the PCF numbering, the SSTG discipline leads will make the
assignment of SMF ranges to each developer for particular processes.
Each process should be delivered with its own process-specific seed
file.

## HDF-EOS Guidelines

The MODIS SDST has reviewed the HDF-EOS implementation and recommends
the following guidelines for the use of the \"Swath\" construct for
MODIS Level 2 (L2) Standard Data Products and the \"Grid\" construct for
the MODIS Level 2g (L2g), Level 3 (L3) and Level 4 (L4) products. In the
case that one or more of the baselined MODIS parameters will be written
to the product file in other than either of these HDF-EOS constructs,
please make a special note in the File Specification.

Note that Standard Data Products may contain non-HDF-EOS constructs
(using NCSA HDF) in addition to the HDF-EOS constructs if there is a
good reason to do so.

In general there are two ways to approach reading HDF-EOS files: you can
use the HDF-EOS Application Program Interface (API), or you can use the
NCSA HDF API. Note that some HDF-EOS constructs do not facilitate use of
the NCSA HDF API (by reason of alteration of data structures and data
structure name changes), but these constructs are not recommended for
use in the MODIS Standard Data Products.

Likewise, there are two ways to approach writing HDF-EOS files: you can
use the HDF-EOS API to create and write the data structures, or you can
use the HDF-EOS API to create the data structures and use the NCSA HDF
API to write the data. In the absence of a reason for using the second
approach, the first should be followed. (Minimizing the changes to your
code is a good reason for using the second approach.) If you do use the
second approach, use the HDF-EOS routine \"EHidinfo\" to obtain the HDF
file id (consult your SDST representative for further information on its
use).

The rationale for the guidelines presented below is to comply fully with
the EOSDIS\'s HDF-EOS mandate in as simple and straightforward a way as
is appropriate for the MODIS Standard Data Products. We expect that by
following these guidelines the MODIS Standard Data Products will be
correctly formatted to support EOSDIS services that will facilitate user
search and order.

The MODIS Product Specifications must contain information on the names
of the \"Swath\" and \"Grid\" constructs and the data constructs that
are components of the \"Swath\" or \"Grid\". The \"Swath\" Product
Specification must also include an indication of whether the geolocation
data set is \"internal\" or \"external.\"

Consult the HDF-EOS Library Users Guide for specific technical
information on the use of the API.

The following sections present recommendations for Swath and Grid
constructs as well as code and data file examples. The examples are
\"bare bones brief\" to show the essentials; software developers should
use any additional HDF-EOS and/or HDF constructs as appropriate to their
products.

### Swath Recommendations

There are four main areas to which our guidelines apply:

1.  Swath Membership

2.  Geolocation Information

3.  Merging Data Arrays

4.  Naming

#### Swath Membership

All MODIS geophysical parameters and related quantities for which
display based on interpretation as numerical values is appropriate
should be included in the swath construct. For example, Science Data
Sets (SDSs) such as \"surface temperature\" and \"three sigma confidence
range\" should be included, but a bit field of \"Quality Assurance (QA)
indicators\" or \"coefficients for a model\" should not be.

Data sets that are related to different geographic data sets should be
in different swaths, otherwise they should be in the same swath (even if
they are related in different ways - see the two different \"dimmaps\"
shown in Example 2 of Appendix C). Swaths should contain two or three
dimensional data sets; if there is a reason that a four (or higher)
dimensional array is desirable contact your SDST representative.

#### Geolocation Information

If the data set(s) in the swath have the same geographic scale as the
MOD03 product (Geolocation data), use the option of identifying an
external geolocation data file and read MOD03 for geolocation. The
Geolocation product is formatted to support this use. (Note this implies
that the values are decimal degrees.) If the data set elements are of
coarser resolution (e.g., 5X5 pixels), create an internal geolocation
swath component and populate it appropriately. Note that the L1B data
set will contain a coarse resolution (5X5 pixels) geolocation swath
component, so if it is appropriate for your product you should simply
copy it. In any case the File Specifications must indicate how the
geolocation information is provided, \"external\" or \"internal\".

The Offset and Increment entries in the HDF-EOS metadata need to be set
appropriately to preserve the geolocation accuracy when the data stored
has a different resolution than the geolocation. The values should be
set as follows:

  --------------------------- ----------- ----------- ----------- -----------
  Description                 Scan                    Track       
                              direction               direction   

                              Offset      Increment   Offset      Increment

  1km data, 5km geolocation   2           5           2           5
  (every 5^th^ geolocation                                        
  pixel)                                                          

  500m data, 1km geolocation  0           2           0           2

  250m data, 1km geolocation  0           4           1           4
  --------------------------- ----------- ----------- ----------- -----------

An offset of 1 instead of 0 in the track direction for the 250m case is
needed because of the way the 250m samples are nested within the 1km
samples.

Because HDF-EOS does not support fractional offset values, it doesn\'t
properly handle sub-pixel offsets in Swath files. This means that when
the HDF-EOS metadata is strictly interpreted the 500m and 250m products
are off by 250m and 125m in the track direction, respectively.

To better document the true offset an HDF global attribute of type
"float32" should be written for a swath when the swath and data
dimensions are different. These attributes are named:

HDFEOS_FractionalOffset\_\<DataDimensionName\>\_\<SwathName\>

where

\<DataDimensionName\> is the name of the data dimension;

\<SwathName\> is the HDF-EOS swath name.

This fractional offset is meant to be added to the \"integer\" offset
provided in the HDF-EOS metadata. The following gives the values for the
fractional offset:

  --------------------------- --------------------- ----------------------
                              Scan Fractional       Track Fractional
                              Offset                Offset

  1km data, 5km geolocation   0.0                   0.0
  (every 5^th^ geolocation                          
  pixel)                                            

  500m data, 1km geolocation  0.0                   0.5

  250m data, 1km geolocation  0.0                   0.5
  --------------------------- --------------------- ----------------------

For example, the following HDF global attribute would be added to the
MOD02QKM product:

HDFEOS_FractionalOffset_4_Max_EV_frames_MODIS_SWATH_Type_L1B = 0.0

HDFEOS_FractionalOffset_40_nscans_MODIS_SWATH_Type_L1B = 0.5

#### Merging Data Arrays

HDF-EOS provides a mechanism to \"merge\" data arrays that have the same
dimensions and the same relationship to the geolocation information.
Unless you have a large number of data arrays, do not use this option.
(If you feel you should for some reason, contact your SDST
representative.) In general each array that is intended to be handled
separately should be in its own SDS.

The merge option is not recommended because it reformats multiple two
dimensional data arrays into a three dimensional array and changes the
names of things. It is provided for the case that the swath contains
many SDSs; by reducing the number of objects there is an expectation of
greater efficiency of handling the file in certain HDF operations.

#### Swath Naming

Use the prefix \"MODIS_Swath\_\" for all MODIS swath constructs.

### Grid Recommendations

There are four main areas to which our guidelines apply:

1\. Grid Membership

2\. Georeferencing Information

3\. Merging Data Arrays

4\. Naming

#### Grid Membership

All MODIS baselined parameters and related quantities for which display
based on interpretation as numerical values is appropriate should be
included in the grid construct. For example, SDSs such as \"surface
temperature\" and \"three sigma confidence range\" should be included,
but a bit field of \"QA indicators\" or \"coefficients for a model\"
should not be.

Data sets that are related to different geographic projections should be
in different grids, otherwise they should be in the same grid (even if
they are related in different ways - see the two different \"dimmaps\"
shown in Example 2 of Appendix C). Grids should contain two or three
dimensional data sets; if there is a reason that a four (or higher)
dimensional array is desirable contact your SDST representative.

#### Georeferencing Information

There are three different map projections which MODIS data products may
be produced:

1\. Geographic (Plate Carree or latitude/longitude)

2\. Sinusoidal

3\. Lambert Azimuthal Equal Area (for Polar Projections)

These grids are defined using the \"GDdefproj\" call. The parameters
needed are based on the General Carteographic Transformation Package
(GCTP) parameter set. The following shows the parameters for each
projection:

-   Geographic

> gridID = GCTP_GEO
>
> zone = NULL (not used)
>
> spherecode = NULL (not used)
>
> projparm\[0-12\] = 0.0 (not used)

-   Sinusoidal

> gridID = GCTP_SNSOID
>
> zone = NULL (not used)
>
> spherecode = -1 (not a standard sphere)
>
> projparm\[0\] = 6371007.181
>
> (sphere with best surface area fit of WGS84 ellipsoid)
>
> projparm\[1-3\] = 0.0 (not used)
>
> projparm\[4\] = 0.0
>
> projparm\[5\] = 0.0 (not used)
>
> projparm\[6-7\] = 0.0
>
> projparm\[8-12\] = (not used)

-   Lambert Azimuthal Equal Area

> gridID = GCTP_LAMAZ
>
> zone = NULL (not used)
>
> spherecode = -1 (not a standard sphere)
>
> projparm\[0\] = 6371228.0 (sphere with best surface area fit of an
>
> international ellipsoid)
>
> projparm\[1-4\] = 0.0
>
> projparm\[6\] = 90000000.0 (center latitude; north pole) or
>
> -90000000.0 (center latitude; south pole)
>
> projparm\[7-12\] = 0.0

For each of these grids the caller must also specify the location of the
grid in the map projection using a call to \"GDcreate\". The four
parameters which must be specified are:

1.  xdimsize - Number of columns in the grid

2.  ydimsize - Number of rows in the grid

```{=html}
<!-- -->
```
1.  upleftpt - Location of the upper left corner of the upper left pixel

```{=html}
<!-- -->
```
1.  lowrightpt - Location of the lower right corner of the lower right
    pixel

The locations are x and y map projection coordinates (x first). The
units are in meters for all of the map projections except Geographic
which uses the standard GCTP degrees/minutes/seconds (\"dddmmmsss.sss\")
format.

The following table shows the parameter for each map projection for the
entire global grids:

-   Geographic

> xdimsize = 2 \* ydimsize

ydimsize = 180 (1 degree), 360 (1/2 degree) ,720 (1/4 degree) or 3600
(1/20 degree)

> upleftpt = {-18000000.0, 90000000.0}
>
> lowrightpt = {18000000.0, -90000000.0}

-   Sinusoidal

> xdimsize = 2 \* ydimsize
>
> ydimsize = 21600 (30 arcsec), 43200 (15 arcsec) or 86400 (7.5 arcsec)
>
> upleftpt = {-20015109.354, 10007554.677}
>
> lowrightpt = {20015109.354, -10007554.677}

-   Lambert Azimuthal Equal Area (for Polar Projections)

> xdimsize =18069 (1 km) or 36138 (500 m)
>
> ydimsize = xdimsize
>
> upleftpt = {-9058902.1845, -9058902.1845}
>
> lowrightpt = {9058902.1845, -9058902.1845}

For the land tiling system, these dimensions and coordinates will
change. The following calculations are done to calculate the grid
locations of an individual tile:

-   Sinusoidal

> xdimsize = 1200 (30 arcsec), 2400 (15 arcsec) or 4800 (7.5 arcsec)
>
> ydimsize = xdimsize
>
> upleftpt = {-20015109.354, 10007554.677} +
>
> { itile_horiz \* 1200 \* 926.62543305, -itile_vert \* 1200 \*
> 926.62543305}
>
> lowrightpt = upleftpt + {1200 \* 926.62543305, 1200 \* 926.62543305}

-   Lambert Azimuthal Equal Area

> xdimsize = 951(1 km) or 1902 (500 m)
>
> ydimsize = xdimsiz
>
> upleftpt = {-9058902.1845, -9058902.1845} +
>
> { itile_horiz \* 951 \* 1002.701, -itile_vert \* 951\* 1002.701}
>
> lowrightpt = upleftpt + {951 \* 1002.701, 951 \* 1002.701}

Where {\"itile_horiz\", \"itile_vert\"} are the horizontal and vertical
tile numbers, {0,0} is the tile in the upper left corner. Tile {35, 17}
is the tile in the lower right corner for the Sinusoidal grids and tile
{19, 19} is for the Lambert Azimuthal Equal Area grid. Since the
Lambrert Azimuthal Equal Area global grid dimensions are not a multiple
of the tile size, the tiles on the left and bottom of the grids are
sligtly smaller.

Finally, \"GDorigin\" must callled to define the origin of the grid. The
MODIS grids will have the origin in the upper left corner (HDFE_GD_UL).

#### Merging Data Arrays

HDF-EOS provides a mechanism to \"merge\" data arrays that have the same
dimensions and the same relationship to the geolocation information.
Unless you have a large number of data arrays, do not use this option.
(If you feel you should for some reason, contact your SDST
representative.) In general each array that is intended to be handled
separately should be in its own SDS.

The merge option is not recommended because it reformats multiple two
dimensional data arrays into a three dimensional array and changes the
names of things. It is provided for the case that the swath contains
many SDSs; by reducing the number of objects there is an expectation of
greater efficiency of handling the file in certain HDF operations.

#### Grid Naming

Use the prefix \"MOD_Grid\_\" for all MODIS grid constructs. The
dimension names \"Xdim\" and \"Ydim\" are required by the HDF-EOS grid
routines.

## Metadata 

ECS has defined metadata as descriptive information about the data in a
format that uses a common set of terms and definitions. The Earth
Science Data Type (ESDT) is the interface between the science data and
ECS. Metadata for each ESDT are organized into an ESDT Descriptor that
primarily contains groups of Collection Level Metadata and Inventory
Level Metadata. The Collection Level Metadata describe the data
collection as a whole and will not vary from data granule to data
granule. Inventory Level Metadata, which is also called granule metadata
or Core metadata depending on the context, describes each granule within
the Collection. This information varies with each granule. The set of
attributes uniquely identifies the granule within the Collection. Within
each of these main groups ECS has defined sub-groups and attributes for
the different categories of data. The ECS B.0 Earth Science Data Model
defines all of these attributes. The ESDT Descriptor also defines a
third group of Archived Level Metadata in which the data producers may
define other metadata for their products that have not been included in
the ECS Data Model.

The published references on metadata include the SDPTK User\'s Guide
(specifically Section 6.2.1 and Appendix J); B.0 Implementation Earth
Science Data Model for the ECS Project, which describes the mandatory
metadata; and a draft white paper titled \"An ECS Data Provider\'s Guide
to Metadata.\"

The following sections present background information, the ECS metadata
implementation in the SDPTK, and the approach to integrating metadata
support into the MODIS software.

### Background

Most of the Collection Level Metadata has been constructed in the ESDTs
by ECS with input from MODIS SDST. Many of the attributes are common to
MODIS ESDTs and some are common to MODIS Science Disciplines or to the
DAACs at which the products are archived. The SCF is required to supply
only a very limited set of Collection Level Metadata information for the
design of the ESDT for a new product.

ECS requires certain information to be provided in every archived
product, in a specific format and syntax, for the purpose of creating
the inventory of archive products in the ESDIS database and allowing
subsequent retrieval of the data from the archive. From the composite of
the Inventory metadata attributes ECS has constructed a minimum set of
required attributes for products produced or archived in the DAACs. Many
other attributes are optional. In addition MODIS has added several
required Inventory attributes for various purposes.

All of the Inventory attributes are searchable when ordering data
through the DAACs. Data producers also have the option of adding
searchable attributes to the Inventory, which are unique to their
products, by following the same rules of format and syntax as for the
other Inventory metadata. These attributes are referred to as
Product-Specific Attributes (PSAs) or Additional Attributes depending on
the context. The PSAs should not be confused with the Archived Metadata,
which data providers may add to their science products. The Archived
metadata values are present only in the science product and are not
entered into the ECS Database at the DAACs during the archival process.
However, all PSAs and Archived Metadata attributes must be defined in
the ESDT Descriptor.

There is another category of metadata called structural metadata that
are not manipulated by the user. Structural metadata are automatically
generated by the HDF-EOS API tools. This category is mentioned here for
completeness, but developers do not need to know the details of this
type of metadata.

ECS metadata are stored in the HDF product files as string attributes,
consisting of large text blocks. Different categories of metadata are
stored in separate attributes. The individual items are described using
the Parameter Value Language (PVL) syntax, which is a proposed
Consultative Committee for Space Data Systems (CCSDS) standard. Each
text block contains multiple metadata attributes up to the maximum HDF
attribute length (65,535 characters); additional attributes are added as
necessary to store all of the metadata.

### ECS Metadata Implementation

The implementation of the ECS metadata in science processing code has
two major elements: the Metadata Configuration File (MCF) and the
metadata routines in the SDPTK and MODIS-API (M-API). ECS creates the
MCF from the ESDT Descriptor and delivers it to SDST for use by MODIS.
SDST will provide the MCFs delivered by ECS to the SCFs for use in
development of their software. ECS also delivers the ESDT Descriptor to
the DAACs where it is installed into the database for use in archiving
the products.

#### Metadata Configuration File

A process must utilize an MCF in order to write ECS metadata to a
product using the SDPTK. For processes that produce multiple products,
each product will need to have a corresponding MCF. The basic format of
the MCF is described in Appendix J of the SDPTK User\'s Guide. The MCF
specifies both the overall categories and the specific attributes of the
metadata for a product. Appendix I of this delivery guide provides
examples of MCFs.

Inventory metadata consists of all attributes which are required to be
searchable and must be stored in the DAAC inventory database when the
granule is inserted into the archive. PSAs are defined by the data
providers but they must be registered with ECS prior to inclusion in the
MCF and use in the operational science software. Archived metadata
attributes are stored in the product but not in the inventory database
at the DAACs. It is important to note that the inventory metadata
includes all ECS-specified granule level Core attributes, along with any
PSAs, which the data producer wants to be searchable.

The MCF lists the individual metadata attributes for a particular
product and also defines the metadata categories for the product. Each
attribute specification includes the following:

-   **Data_Location** -- The source for the data. Valid settings are
    MCF, PGE, TK, DSS, and DP. In the metadata context these have
    associated meanings. MCF means the value is hard-coded in the MCF
    itself. PGE means the processing software sets the value. TK means
    the SDP Toolkit sets the value. DSS means that the value is set
    after processing by the Data Server. DP means that the value is set
    after processing by the Data Provider.

-   **TYPE** - Data type. Valid settings are INTEGER, DOUBLE,
    UNSIGNEDINT, STRING, DATE, TIME, and DATETIME.

-   **NUM_VAL** - Number of values. If more than one is expected but the
    number in a particular instance may be less, the setting should be
    the maximum to be allowed.

-   **Mandatory** -- An indicator of whether it is mandatory that the
    value of the attribute be set and written when the software is run.
    Valid settings for Mandatory are TRUE and FALSE. If Mandatory is set
    to TRUE, the software must set and write the value. There are some
    attributes that the software developer wants to include in the MCF
    but may not want the software to write the values for these
    attributes in some cases. Mandatory for these attributes should be
    set to FALSE. ECS requires that Mandatory for PSAs or Additional
    Attributes always be set to FALSE.

-   **Value** - If the MCF is the source, the value must be set in the
    MCF itself.

-   **Class** - The MCF can also support multiple instantiations of an
    attribute or group of attributes by use of a Class = "M"
    specification. The multiple instances have different informational
    values and are assigned a unique Class number (digit).

Setting attribute values in the MCF is discouraged for all but the
ShortName and VersionID that are required by ECS and several attributes,
such as Associated Platform, Instrument, and Sensor ShortName that have
been set in MCFs by MODIS SDST and tested in prototypes by the DAACs
before being included in operational MCFs. The values that are set in
the MCF will not be overridden by software in the production
environment.

Within the MCF, the metadata are categorized as Inventory or Archived by
placement within the appropriate the top-level master group. The
metadata tools associate each master group with a metadata handle as
described below.

ECS imposes strict requirements on the format of the inventory group of
the MCF as follows:

-   The specific groups of attributes, such as ECSDataGranule, within
    the Inventory master group have been defined by ECS and must be
    used.

-   Certain groups of attributes, such as GRing and GRingPoint in a
    GPolygon Container, are also required to be a "container object."

-   PSAs are not included explicitly in the MCF. However, they must be
    previously defined in the ESDT Descriptor. The attributes
    AdditionalAttributeName and ParameterValue are used in pairs to
    store the name and value of each PSA. The use of PSAs is described
    in more detail in Section 3.6.5.7.

The actual MCF for each MODIS product will be generated by ECS from the
ESDT Descriptor file based on the metadata specifications for the
product and other information provided by SDST in the ESDT generation
request. These MCFs will be verified and used by SDST for testing at the
TLCF. Products generated by the PGE, using these MCFs, will be tested
for insert into the ECS Database at the DAAC that will archive the
products. If the insert test is successful, the new version of the PGE
with this MCF will be installed into operations at MODAPS or the GES
DAAC.

The sample MCFs provided by SDST in Appendix I are consistent with ECS
requirements and the STMs should not alter the format of the MCFs
without first consulting with SDST.

#### Science Data Production Toolkit Metadata Tools

The metadata tools are used by production software to create and store
the ECS metadata in the products. The underlying principle is that all
metadata are initialized and stored in memory through multiple calls to
the tools; the final step is to write the metadata to the file, which is
performed as a single call for each category of metadata. The tools are
also used to read ECS metadata from an input file or to get values from
the PCF.

A brief summary of the tools follows:

  ------------------------ -----------------------------------------------
  PGS_MET_Init             Initializes metadata in memory using
                           information in the MCF; this is the first
                           metadata tool called by a process.

  PGS_MET_SetAttr          Sets the value of a single metadata attribute.

  PGS_MET_GetPCAttr        Retrieves the value of a metadata attribute
                           from an input file. (There is a similar routine
                           called PGS_MET_GetConfigData which retrieves a
                           PCF data value using an attribute name.
                           PGS_MET_GetConfigData will not be used by MODIS
                           software because it impacts combining multiple
                           processes in PGEs.)

  PGS_PC_GetConfigData     Retrieves a data value from the PCF by
                           specifying a logical.

  PGS_PC_GetUniversalRef   Retrieves a Universal Reference (UR) for an
                           input file.

  PGS_MET_GetSetAttr       Retrieves a previously set metadata value from
                           memory.

  PGS_MET_Write            Writes all metadata attributes for a single
                           category of metadata to an HDF product file.

  PGS_MET_Remove           Frees memory allocated for metadata.
  ------------------------ -----------------------------------------------

Only PGS_MET_Write actually accesses the output product and requires
explicit reference to an HDF file ID. The tool PGS_MET_GetPCAttr reads
metadata values from HDF input files, but the files are specified using
the PCF file IDs and the HDF file access is handled internally by the
tool.

#### Metadata Toolkit Programming Hints

The functionality of the SDPTK metadata tools has been verified, but
developers should take note of the following items:

-   The tool PGS_MET_GetPCAttr requires that the attribute field refer
    to either the file itself, if it is an HDF file containing ECS
    metadata attribute strings, or to a correctly formatted text file
    describing the main file. The \*.met file that is created
    automatically by PGS_MET_Write can be used for this purpose. The
    metadata attribute names specified in the MCF and the calls to the
    toolkit routines may be mixed case, but will be written to the files
    in all upper case. The attribute names in the B.0 Data Model and the
    sample MCFs use mixed case.

-   The first master group in the MCF must be called INVENTORYMETADATA.

-   The metadata Input/Output (I/O) tools (PGS_MET_GetPCAttr and
    PGS_MET_Write) use two files in the SUPPORT OUTPUT files section of
    the PCF as work space. The logical IDs referenced by these tools are
    10252 and 10254, respectively. These entries need to be included in
    the PCF, and not used for other purposes.

#### MODIS-Application Program Interface

SDST provides a MODIS Application Programming Interface to HDF called
M-API that also supports two tools for the reading and writing of ECS
granule metadata. These routines are named differently in Fortran (in
parentheses) than C and are described below. In addition, M-API header
files (mapi.h/mapi.inc) contain macro definitions for all ECS granule
metadata attribute names and global attribute names.

-   getMODISECSinfo (GMECIN) - This tool supports the reading of
    metadata attributes from existing input files. It is designed to be
    used in place of PGS_MET_GetPCAttr in order to allow M-API users to
    specify input files using the M-API file handle instead of the PCF
    logical ID and version number. This will simplify the access to
    metadata for M-API users. The API is very similar to the existing
    M-API tool getMODISfileinfo.

-   completeMODISfile (CPMFIL) - This M-API tool performs the calls to
    PGS_MET_Write.

While M-API furnishes a viable, simplified access to HDF, it does entail
placing another API over the already multilayered HDF interface and the
installation of the M-API library on the local development machine. Due
to these drawbacks, and the fact that many of today's developers are
already familiar with HDF formats, SDST no longer advocates reliance on
the M-API toolkit. It is mentioned here for completeness and because
there are active MODIS PGEs that continue to build off the M-API
library.

### Metadata Lists

The three categories of metadata used by MODIS products are ECS
Collection, Inventory (including product-specific), and Archived. ECS,
EOS DAACs, MODIS SDST, MODIS Science Disciplines, and MODAPS may require
certain attributes for all ESDTs or for individual ESDTs for several
reasons:

-   Attributes are required by the ECS B.0 Data Model in order to
    describe a data collection for a standard product or an interim
    product archived at an EOS DAAC.

-   Attributes are required by ECS for insert of products into an EOS
    DAAC Archive.

-   Attributes are required by ECS for Search and Order of products.

-   Attributes are required by MODAPS in its data production system.

-   Attributes are required by MODIS Science Disciplines and SDST for
    tracking product granules produced by different versions of PGEs and
    for ordering products archived at MODAPS.

Table 3-1 lists ECS Inventory metadata attributes used by MODIS products
made by MODIS PGEs. The table lists the names of the metadata
attributes, data location, an indicator of whether the attribute is
required or optional, an indicator of whether or not the setting of the
attribute is mandatory (TRUE or FALSE), and the number of values,
including whether the attribute uses the Class = "M" specification to
store multiple instances. The Required/Optional column is explained
above. The other three columns have been described in Section 3.6.2.1.
In this context note that PGE actually refers to the processing
software, including the PGE script, that generates the product
containing the attribute in its metadata. The ShortName and VersionID
used in the ECS Metadata MUST be the same as the ShortName and VersionID
used in the Earth Science Data Type (ESDT) Descriptor because the
combination of these two attributes is the key to a unique ESDT
Collection for the product in the ECS Database.

PSAs may be included in the inventory metadata to support production
rules and user query. The choice of attributes clearly depends on the
type of product and the requirements for the inventory. In this case
there is no distinction made between Inventory and PSAs that are
attributes within the AdditionalAttribute Group.

PSAs must be registered with ECS prior to usage in products. The MODIS
SDST Systems Analyst performs this function using an established process
with ECS. When ECS has completed the registration, MODIS is notified
that the PSA may be included in product ESDTs. ECS also adds the new PSA
to their PSA table on the ECS information web page. The current ECS URL
for viewing all PSA information may be obtained from SDST.

The first step in getting a new PSA is for the SCF to send an email to
the Systems Analyst with the following information:

-   PSA Name --Required. Maximum length of 40 characters.

-   PSA Description -- Required. Maximum length of 255 characters.

-   PSA Data Type -- Required. Valids: (int, varchar, float, date, time,
    datetime).

-   Maximum Number of Values -- Required.

-   Data Length -- Required only for PSAs with varchar data type.
    Maximum allowed is 255 characters.

-   PSA Range -- Optional. Provide min-value and max-value if
    applicable.

-   Valid Value Flag -- Required only if PSA with varchar data type has
    an enumerated list of valid values. Valids: (Yes, No). Default is
    No.

-   PSA Valid Values -- Optional. Generally used for PSAs with varchar
    data type. Provide an enumerated list of valid values if Valid Value
    Flag is specified as Yes.

-   PSA Units of Measurement -- Optional.

-   ESDT Products that will be using the new PSA -- Required.

There are a few Archived Metadata attributes that are required by MODIS.
The addition of other Archived Metadata attributes is entirely up to the
software developer. The attributes in the Archived Metadata may include
copies of those listed as ECS Core attributes from the B.0 Earth Science
Data Model that are not included in the product's Inventory Metadata and
additional MODIS-specific attributes. Table 3-2 is a listing of Archived
Metadata attributes for MODIS products based on the conventions adopted
by the MODIS Science Discipline Groups. The list includes attributes
required by MODIS, attributes recommended by MODIS, and some of the more
common attributes defined by MODIS SCFs.

A small subset of the Collection Level attributes, for which the data
producers at the SCFs must provide metadata information for their
products, is listed in Table 3-3. The primary information to be supplied
includes the ShortName, LongName, and CollectionDescription for the
product; the ESDT Collection VersionID; a selection of at least one
Global Climate Modeling Data (GCMD) keyword for search and order of the
product; any PSAs to be included with a description of each; and whether
Terra, Aqua, and Combined Terra plus Aqua products are to be made. The
Data Location in the Collection Level is always MCF and with the
exception of Additional Attributes, the Mandatory setting is TRUE. The
SCF needs to supply only the values for the Collection Level attributes
listed. Some of the attributes have a group of valid settings, called
"valids". These valids are listed in Section 3.6.5 where the attributes
are described. The ESDT Collection Version into which the products are
to be archived at the DAAC is generally determined by each MODIS Science
Discipline as a group. The entire group decides when to change to the
next collection. At any one time the ESDT Collection VersionID may vary
for Terra, Aqua and Combined Terra plus Aqua products. The values for
remainder of the required Collection Metadata in the ESDT Descriptor can
usually be determined from this provided information.

For Table 3-1, Table 3-2, and Table 3-3 the following symbols are used
in the Required/ Optional column:

-   R = Attribute is required.

-   R (g) = Attribute is required if the product granule is global.

-   O = Attribute is optional.

-   S = Attribute is recommended by SDST.

-   O (r) = Attribute is in an optional group or container but is
    required if the group or the container is included.

-   A = Attribute is required in the Archived Metadata if GRing is the
    Spatial Group in the Inventory Metadata.

[]{#__RefHeading___Toc80090114 .anchor}Table 3-1. ECS Core Inventory
Metadata Attributes

  --------------------------------------------------------------------------------------
  **Attribute Name**                  **Required / **Data       **Mandatory   **Number
                                      Optional**   Location**   Setting**     of
                                                                              Values**
  ----------------------------------- ------------ ------------ ------------- ----------
  ShortName                           R            MCF          TRUE          1

  VersionID                           R            MCF          TRUE          1

  SizeMBECSDataGranule (9)            R            DSS (1)      FALSE         1

  ReprocessingActual                  R            PGE          TRUE          1

  ReprocessingPlanned                 R            PGE          TRUE          1

  LocalGranuleID                      R            PGE          TRUE          1

  DayNightFlag                        R            PGE          TRUE          1

  ProductionDateTime                  R            TK (1)       TRUE          1

  LocalVersionID                      S            PGE          FALSE or TRUE 1

  PGEVersion                          R            PGE          TRUE          1

  InputPointer                        R            PGE          TRUE          n (7)

  RangeBeginningDate                  R            PGE          TRUE          1

  RangeBeginningTime                  R            PGE          TRUE          1

  RangeEndingDate                     R            PGE          TRUE          1

  RangeEndingTime                     R            PGE          TRUE          1

  EastBoundingCoordinate (2)          R            PGE          TRUE          1

  NorthBoundingcCordinate (2)         R            PGE          TRUE          1

  SouthBoundingCoordinate (2)         R            PGE          TRUE          1

  WestBoundingCoordinate (2)          R            PGE          TRUE          1

  ExclusionGRingFlag (2)              R            PGE          TRUE          1, M

  GRingPointLatitude (2)              R            PGE          TRUE          4, M

  GRingPointLongitude (2)             R            PGE          TRUE          4, M

  GRingPointSequenceNo (2)            R            PGE          TRUE          4, M

  OrbitNumber (3)                     O(r)         PGE          FALSE         M

  StartOrbitNumber (3)                O (r)        PGE          FALSE         M

  StopOrbitNumber (3)                 O (r)        PGE          FALSE         M

  EquatorCrossingLongitude (3)        O (r)        PGE          FALSE         M

  EquatorCrossingDate (3)             O (r)        PGE          FALSE         M

  EquatorCrossingTime (3)             O (r)        PGE          FALSE         M

  ParameterName (4)                   R            PGE          FALSE         M

  AutomaticQualityFlag (4)            R            PGE          FALSE         M

  AutomaticQualityFlagExplanation (4) R            PGE          FALSE         M

  OperationalQualityFlag (4), (9)     R            PGE          FALSE         M

  OperationalQualityFlagExplanation   R            PGE          FALSE         M
  (4), (9)                                                                    

  ScienceQualityFlag (4), (9)         R            DP (1)       FALSE         M

  ScienceQualityFlagExplanation (4),  R            DP (1) or    FALSE or TRUE M
  (9)                                              PGE                        

  QAPercentInterpolatedData (4)       O            PGE          FALSE         M

  QAPercentMissingData (4)            R            PGE          FALSE         M

  QAPercentOutofBoundsData (4)        O            PGE          FALSE         M

  QAPercentCloudCover (4)             O            PGE          FALSE         1

  AncillaryInputType (5)              O (r)        PGE          FALSE         M

  AncillaryInputPointer (5)           O (r)        PGE          FALSE         M

  AssociatedPlatformShortName         R            MCF          TRUE          1

  AssociatedInstrumentShortName       R            MCF          TRUE          1

  AssociatedSensorShortName           R            MCF          TRUE          1

  AdditionalAttributeName (6)         O (r)        PGE          FALSE         M

  ParameterValue (6)                  O (r)        PGE          FALSE         M

  LocalityValue (8)                   R (g)        MCF          TRUE          1
  --------------------------------------------------------------------------------------

Notes:

\(1\) The sources TK, DP, and DSS indicate that these fields will be set
independently of the processing software in the production environment.
The OperationalQualityFlag used to be set to DAAC, but ECS changed this
in 1999 so that MODAPS and other data processing systems could set this
before export of products to the DAAC.

\(2\) In the B.0 data model, the Bounding Coordinates and the GRing
Polygon are mutually exclusive; therefore it is mandatory to include one
of these as inventory metadata. The other can be stored as archived
metadata if desired. MODAPS requires the Bounding Coordinates in the
Archived Metadata if the Inventory uses GRing Polygon.

\(3\) If the OrbitCalculated SpatialDomain Container is included in the
ESDT and MCF, then either OrbitNumber or the pair of StartOrbitNumber
and StopOrbitNumber must be selected. Each value of OrbitNumber must be
accompanied by values of EquatorCrossingLongitude, EquatorCrossingDate,
and EquatorCrossingTime. Alternatively, the StartOrbitNumber and
StopOrbitNumber must be accompanied by values of these attributes.

\(4\) All Standard Archived Science Products are required to have at
least one Measured Parameter. The ParameterName attribute and the QA
attributes are co-located within the MeasuredParameterContainer of the
MCF. Each set of QA attributes is referenced to the contents of the file
(entire granule, science data field or data abstraction) depending on
the value of the corresponding ParameterName attribute. The combination
of ParameterName and QA attributes can be stored multiple times if
desired, by use of the CLASS = M specification in the MCF. The
attributes of AutomaticQualityFlag and Explanation,
OperationalQualityFlag and Explanation, ScienceQualityFlag and
Explanation, and QAPercentMissingData are required for each instance of
ParameterName. The other QAPercent attributes are optional. Data
location for the ScienceQualityFlagExplanation can be set to either DP
(with corresponding setting of the value in the MCF and Manditory set to
FALSE) or to PGE (with writing of the value by the PGE and Manditory set
to TRUE).

\(5\) The AncillaryInputPointer group was designed to specify input
files that are necessary in order to interpret the data in the output
product. Each AncillaryInputPointer must have an AncillaryInputType set
as well. The type values must be chosen from the valid domain values as
specified in the B.0 Data Model. ECS is now discouraging the use of this
attribute and is no longer supporting any associated functions for this
attribute at the DAACs. SDST recommends that this attribute not be used
and that all input files now be put into the InputPointer.

\(6\) The AdditionalAttributeName and ParameterValue attributes are used
to set PSA names and values in the granule metadata. Each value of
AdditionalAttributeName must correspond to a previously-registered PSA.
MODIS requires the inclusion of the PROCESSVERSION PSA for all products,
but does not currently require that the software write this PSA. MODIS
Land also requires the TileID PSA for all of its tiled products.

\(7\) The value of n must be set for each product according to the
maximum number of values expected for this attribute.

\(8\) The Locality Value is now required by the DAAC if the product
granule is global. ECS has added this attribute with a Data_Location of
"MCF" and hard-coded value of "Global" for all global products.

\(9\) The SizeMBECSDataGranule, OperationalQualityFlag,
ScienceQualityFlag, OperationalQualityFlagExplanation, and
ScienceQualityFlagExplanation fields will be present in the MCFs but
should not be included in the file specifications since they are set in
the inventory by sources external to the science code. ECS changed the
original requirements and required MODIS to change SizeMBECSDataGranule
to "Mandatory = FALSE" because the size is computer system dependent and
therefore must be set at the DAAC by the Data Server when the science
granule is archived.

[]{#__RefHeading___Toc80090115 .anchor}Table 3-2. MODIS Archived
Metadata Attributes

  ---------------------------------------------------------------------------
  **Attribute Name**                  **Required / **Data       **Mandatory
                                      Optional**   Location**   Setting**
  ----------------------------------- ------------ ------------ -------------
  DESCRrevision (1)                   R            MCF          TRUE

  LongName (2)                        R            MCF          TRUE

  ProcessingEnvironment (3)           R            PGE          FALSE

  ProductionHistory (3)               R            PGE          FALSE

  EastBoundingCoordinate              A            PGE          TRUE

  NorthBoundingCoordinate             A            PGE          TRUE

  SouthBoundingCoordinate             A            PGE          TRUE

  WestBoundingCoordinate              A            PGE          TRUE

  AlgorithmPackageAcceptanceDate      S            PGE          TRUE or FALSE

  AlgorithmPackageMaturityCode        S            PGE          TRUE or FALSE

  AlgorithmPackageName                S            PGE          TRUE or FALSE

  AlgorithmPackageVersion             S            PGE          TRUE or FALSE

  InstrumentName                      O            MCF or PGE   TRUE or FALSE

  ProcessingCenter                    O            MCF or PGE   TRUE or FALSE

  SPSOParameters                      O            MCF or PGE   TRUE or FALSE

  LocalInputGranuleID                 O            PGE          TRUE or FALSE
  ---------------------------------------------------------------------------

Notes:

(1) MODIS SDST assigns the value based on the ESDT Collection to be used
    in archiving the product and the number of ECS-allowed revisions
    made to the ESDT since the basic Collection was installed at the
    DAACs.

(2) The LongName in the Archived Metadata is an exact copy of the
    LongName in the Collection Metadata. MODIS decided that the LongName
    should be included in every science granule since the EOS Clients
    for ordering data use the LongName as the primary description of the
    product.

(3) MODIS requires the attribute to be included. However, Mandatory is
    set to FALSE to allow time for the software developers to implement
    the setting of values for the attribute in the code.

[]{#__RefHeading___Toc80090116 .anchor}Table 3-3. Collection Metadata
Attributes

  ----------------------------------------------------------------------------------------
  **Attribute Name**                   **Required/   **Data       **Mandatory   **Number
                                       Optional**    Location**   Setting**     of
                                                                                Values**
  ------------------------------------ ------------- ------------ ------------- ----------
  ShortName                            R             MCF          TRUE          1

  VersionID                            R             MCF          TRUE          1

  LongName                             R             MCF          TRUE          1

  CollectionDescription                R             MCF          TRUE          1

  ProcessingCenter                     R             MCF          TRUE          1

  ArchiveCenter                        R             MCF          TRUE          1

  SpatialSearchType                    R             MCF          TRUE          1

  DisciplineTopicParametersContainer   R             MCF          TRUE          M
  (1)                                                                           

  ECSDisciplineKeyword (1)             R             MCF          TRUE          1

  ECSTopicKeyword (1)                  R             MCF          TRUE          1

  ECSTermKeyword (1)                   R             MCF          TRUE          1

  ECSVariable (1)                      R             MCF          TRUE          1

  ProcessingLevelID                    R             MCF          TRUE          1

  ProcessingLevelDescription           R             MCF          TRUE          1

  PlatformInstrumentSensorContainer    R             MCF          TRUE          M

  PlatformShortName (2)                R             MCF          TRUE          1

  InstrumentShortName (2)              R             MCF          TRUE          1

  SensorShortName (2)                  R             MCF          TRUE          1

  AdditionalAttributeContainer (3)     O             MCF          FALSE         M

  AdditionalAttributeDataType (3)      O (r)         MCF          FALSE         1

  AdditionalAttributeDescription (3)   O (r)         MCF          FALSE         1

  AdditionalAttributeName (3)          O (r)         MCF          FALSE         1
  ----------------------------------------------------------------------------------------

Notes:

(1) At least one GCMD keyword is required for a Standard Archived
    Science Data Product. The GCMD keyword is described by four
    attributes named Discipline, Topic, Term, and Variable. Each set of
    Discipline, Topic, Term, and Variable is put into a
    DisciplineTopicParametersContainer that is labeled Class M in the
    ECS Data Model. Each GCMD keyword gets its own Class number starting
    with 1.

(2) The Terra and Aqua products have only one container of Class M with
    the Platform name of "Terra" and "Aqua" , respectively. The Terra
    plus Aqua Combined products have two containers of Class M, one for
    Terra and one for Aqua. The Platform, Instrument, and Sensor
    ShortNames as well as other descriptive information must be included
    for a single platform and repeated for multiple platforms. ECS has
    supplied the valids for Terra and Aqua information. The SCF needs
    only to provide the platform or platforms associated with each
    product.

(3) MODIS requires only one AdditionalAttribute (PROCESSVERSION) for the
    AdditionalAttributeContainer of Class M. Most products have other
    AdditionalAttributes or PSAs. These are optional. Each PSA gets its
    own Class number starting with 1. If a PSA is defined, the SCF must
    provide all of the information required to set the attributes of
    DataType, Description, and Name.

Appendix M contains a template that the SCF data providers may use to
supply all of the required and optional metadata for their products and
some additional PGE information needed by SDST to request ECS to
generate the ESDT Descriptor and corresponding MCF. It is important for
the STM to include in this template all optional metadata that are
desired for this ESDT Collection of the product. Once this ESDT
Descriptor is installed at the DAAC and is being used for the archive of
the product granules, only certain types of changes are allowed in the
metadata. ECS may make changes to the GCMD keywords as GCMD makes
changes to their database. The STM may request other GCMD keywords to be
added or deleted for their product. They may also update the Science
Quality information for a Measured Parameter. Most other allowed
metadata changes require ECS to make a new version of the ESDT
Descriptor and MCF, but not a new version of the ESDT Collection itself
(same ShortName and VersionID). Some of the most commonly, allowed
changes are additions of PSAs, additions of Archived Metadata
attributes, and deletions of Archived Metadata attributes. Deletions of
PSAs are not allowed. Other proposed changes should be discussed with
the SDST Systems Analyst.

MODIS has also added an interactive, data-entry version of this template
on the SDST Web Site for the convenience of the STM. The user will be
prompted for choices in alternative, required metadata groups and text
values that must be supplied. The user may view all required groups and
attributes that will automatically be included in the MCF and ESDT
Descriptor in addition to the metadata that is entered during the
session. Help information will be provided for attributes requiring
choices and text entry. At the end of the session the completed ESDT
request will be sent to the MODIS SDST Systems Analyst.

### Integration into MODIS Processing Software

As stated above, the implementation of the ECS metadata for the science
granule, including both the Inventory attributes and the Archived
attributes, involves the development of the MCF and the integration of
the function calls into the software. SDST provides sample MCFs that can
be used as the basis for all MODIS process MCFs in Appendix I. The
sample MCFs were selected to show the structure for both Bounding
Rectangle Coordinates and GRing Coordinates for the spatial metadata,
different processing levels, specific information for the MODIS
Disciplines, and a variety of Archived Metadata attributes.

The integration of the metadata tools into processing code will be a
joint responsibility of the developers and the SSTG. This section and
the appendices are intended to provide the guidance necessary to allow a
developer to perform the integration. The tools to be integrated are as
follows:

-   Initialization -- one call to PGS_MET_Init is required prior to
    setting any metadata values for the output product. This will also
    set the values specified in the MCF. Note that this routine is not a
    precursor to reading metadata from input files.

-   Retrieving runtime values from the PCF -- multiple calls to
    PGS_PC_GetConfigData, one for each attribute to be retrieved from
    the PCF.

-   Retrieving metadata values from input files -- for M-API users,
    multiple calls to getMODISECSinfo, one for each attribute; direct
    HDF users will perform multiple calls to PGS_MET_GetPCAttr, one for
    each attribute. After the first call to getMODISECSinfo, the
    PVLAttrname should be set to NULL. This will prevent the software
    from rebuilding the internal Object Description Language (ODL) tree,
    thus saving memory and time.

-   Retrieving URs for input files -- ­multiple calls to
    PGS_PC_GetUniversalRef, one for each input file.

-   Setting metadata values for the output product -- multiple calls to
    PGS_MET_SetAttr, one for each attribute to be set in the output
    product\'s metadata.

-   Writing metadata to the output product -- for M-API users, the call
    to completeMODISfile will also write the ECS metadata to the
    product; direct HDF users will perform a minimum of two calls to
    PGS_MET_Write, one for each category of metadata.

-   Freeing memory -- one call to PGS_MET_Remove. Also, getMODISECSinfo
    should be called with all NULLs. This will free memory used by
    getMODISECSinfo.

Example C code for the use of these routines is included in Appendix L.

### Metadata Setting Guidelines

The following guidelines are intended to aid the STM in designing code
to set the values for the Inventory and Archived metadata. Note that the
term \"pass through\" is used to mean that a attribute is read from the
metadata of an input product (using PGS_MET_GetPCAttr or
getMODISECSinfo) and written without modification to the metadata of one
or more output products. The complete list of valids for all attributes
is given in the ECS B.0 Data Model; it is important to note that all
string valids are case sensitive.

### 3.6.5.1 Product Identification Attributes {#product-identification-attributes .unnumbered}

**ShortName --** This attribute must be set in the MCF to the ShortName
which has been defined for the product in the ECS Baseline and the ESDT
Descriptor that is installed at the DAAC where the product is to be
archived. SDST provides lists of all MODIS ESDT ShortNames and
associated information about the products in the MODIS Science Data
Processing Software System Description document. The ShortName in the
MCF at the DAAC must match the ShortName in the MCF that is used by the
PGE software.

**Version ID --** The VersionID represents the version of an ESDT
Collection at the DAAC. The combination of ShortName and VersionID are
used as the database key to the collection. The VersionID will be set to
a fixed integer value in the MCF. Each MODIS Science Discipline decides
on the ESDT Collection to be used for current processing. As mentioned
above, the current VersionID may be different for Terra, Aqua, and
Combined products.

**Day/Night Flag ­--** The Day/Night Flag value ("Day," "Night," or
"Both") should be passed from an input data product to the output
product(s); if input products have different values for this attribute,
it should be set to "Both." L1 products are the original source in the
processing stream for the setting of DayNightFlag. There is one more
valid of "NA" (not applicable) that could be set in rare cases when the
spacecraft is not in earth view or is having problems that make the
setting impossible.

**LocalGranuleID** **­--** This should be set to the MODIS Product File
Name using the convention specified in section 4.3.2.

### 3.6.5.2 Spatial Metadata {#spatial-metadata .unnumbered}

Note that in the ECS Data Model the boundary coordinates and GRing
polygon are mutually exclusive in inventory metadata. All current MODIS
products fit into one of these spatial structures.

**Bounding Coordinates --** Specified in decimal degrees. For L1 and L2
products, these will have been determined by the Geolocation process and
put into its Archived Metadata since its Inventory contains the GRing;
all downstream products should pass these values from the Geolocation
product or (for L2 processing) the L1B product to the output products.
For L3, and Level 4 (L4) products, the determination of the bounding
coordinates is somewhat product-specific, and needs to be determined by
the algorithm developer. Possible choices are: extremes of bounding
coordinates of all input products; fixed limits based on output product
(e.g., tile); fixed values of +/-180 degrees longitude and +/-90 degrees
latitude (e.g., for a global grid product). SDST can provide assistance
in this area if required.

**G-ring Polygon --** The GRing attribute is a series of connected
points, forming a polygon that bounds the geographic area corresponding
to the granule. The ordering of the points must be clockwise as viewed
from above. SDST recommends including it in the inventory metadata for
L1 and L2 products, since it provides a more realistic description of
the granule area. The GRing is determined by the Geolocation process;
all downstream software that directly inputs either the geolocation
product or the L1B product should read the values from either of these
and write them to its output product(s). In general, software reading
the Geolocation GRing will include L1, L2, L2G, and some L3 daily PGEs.
For many L3 and L4 products the spatial extent is better described by
the bounding coordinates and replace the G-ring by at this level. The
Land tiles at higher levels continue to use the GRing. Spatial metadata
for products from other disciplines may be set to the corners of a
geographic region.

### Time Range

**Range Date and Time --** The MODIS groups developed a convention that
attempted to set the Range Date and Time metadata consistently across
MODIS products. For most products the convention is that the beginning
and ending date and times refer to the bounds of the data collection
(compositing) period, not the extent of the data within the granule or
file. MODIS Atmosphere, Land, and Oceans Disciplines have adopted some
variations to these conventions for some of their products. For L2G, L3,
and L4 products, the Range Date and Time values need to be determined by
the code according to the specific output product within the MODIS
Discipline.

-   **MODIS L1** software processes the MODIS data into 5-minute swath
    granules. For both L1A and Geolocation, PGE01 sets the
    RangeBeginningDate and RangeEndingDate throughout the MODIS data day
    to the Greenwich Mean-Time day. The RangeBeginningTime starts at
    00:00:00z and progresses by 5 minutes for each granule.
    RangeEndingTime starts at 00:05:00z and incremented by 5 minutes
    throughout the day. However for the last granule of the day, the
    RangeEndingDate is set to the next day and RangeEndingTime is reset
    to 00:00:00z. For L1 and L2 products these values will be passed
    through from the L1 input products from PGE01.

-   **Atmosphere** software copies the Geolocation or L1B RangeDateTime
    into its L2 products. RangeDateTime metadata for Daily through
    multi-day L3 products are set to the bounds of the data collection
    period using the same convention as L1 software but adding a
    fraction of second to the time. Each data granule has the
    RangeBeginningDate of the first day in the period,
    RangeBeginningTime of 00:00:00.000000z, RangeEndingDate of the first
    day of the next data collection period, and RangeEndingTime of
    00:00:00.000000z.

```{=html}
<!-- -->
```
-   **Land** software copies the Geolocation or L1B RangeDateTime into
    its L2 products. RangeDateTime metadata for L2G and Daily L3 tiled
    products are set to the extent of the actual data within the file.
    The RangeBeginning Date and Time of the earliest input granule and
    RangeEnding Date and Time of the latest input granule are copied
    into the RangeDateTime for the output granule. RangeDateTime
    metadata for 8-day through yearly L3 and L4 products and all CMG
    products are set to the data collection (compositing) period.
    RangeBeginningDate is the first day of the compositing period,
    RangeBeginningTime is 00:00:00z, RangeEndingDate is the last day in
    the compositing period, and RangeEndingTime is 23:59:59z.

-   **Ocean** software copies the Geolocation or L1B RangeDateTime into
    its L2 products. RangeDateTime metadata for all of the daily through
    yearly L3 products are set to the extent of the actual data within
    the file. The RangeBeginning Date and Time of the earliest input
    granule and RangeEnding Date and Time of the latest input granule
    are copied into the RangeDateTime for the output granule. The Oceans
    Discipline defined two PSAs, StartDataDay and EndDataDay, to
    indicate the data collection period.

### Quality Assurance Attributes

QA attributes are referenced to the science data content of the file by
use of the ParameterName attribute, as indicated in Table 3-1. The
instances of the QA attributes with a specific Class apply to the
ParameterName with the Class. The ParameterName should be set to the
name of a specific data object in the file (HDF-EOS data field or HDF
SDS/Vdata), indicating that the QA attributes apply to that data object.
General guidelines for setting the QA attributes are given in the
following paragraphs.

**QA Statistics ­--** Providing guidance for these attributes is
difficult since their meaning is very algorithm-specific. In generic
terms, it is left to the algorithm developers to choose science data
attributes in the output product for calculating statistics, as well as
defining limits for determining when these attributes are out of bounds.
ECS may provide more guidance for setting these in the future. The valid
range is 0 to 100.

**QA Collection Flags --** The AutomaticQualityFlag should be set by the
code to "Passed," "Failed," or "Suspect." The criterion for determining
this is up to the algorithm developer. The
AutomaticQualityFlagExplanation should be set to a brief explanation of
the criterion used for setting the AutomaticQualityFlag.

At the end of the PGE run, the OperationalQualityFlag and
OperationalQualityFLagExplanation will be set by the PGE script in
MODAPS and by an equivalent process at the DAAC in their respective
production environments. For all MODIS products the ScienceQualityFlag
is initialized in the MCF to "Not Investigated". The corresponding
ScienceQualityFlagExplanation is initialized to Web URLs containing QA
information for the MODIS products. There is a different Web site for
each MODIS Discipline. After a product has been archived at the DAAC and
the STM Data Provider has assigned a validation status to the product
for release to the public, the STM or designated science analysts can
use an ECS tool to update the ScienceQualityFLag for a group of product
granules. The STM may request support from the DAAC for the update.

### Reprocessing

**Reprocessing Actual and Reprocessing Planned --** ECS has valids for
both of these attributes. The valids are the following:

-   ReprocessingActual -- "processed once", "reprocessed once",
    "reprocessed twice", "reprocessed".

-   ReprocessingPlanned -- "no further update anticipated", "further
    update is anticipated", "further update anticipated using enhanced
    PGE".

MODIS suggested settings are the following:

-   ReprocessingActual - Set to \"processed once\" for the first
    processing of the data product and "reprocessed" for all subsequent
    reprocessings.

-   ReprocessingPlanned - Set to \"further update is anticipated\".

### Product-Specific Attributes

The PSAs are set using the combination of AdditionalAttributeName and
ParameterValue. For each PSA the AdditionalAttributeName is set to the
PSA name and the ParameterValue to the PSA value, using the same class
for both. The ParameterValue must have a type of string, so if the
intrinsic type of the PSA is numeric it must be converted to a character
string representation before being written as metadata. The class values
must be digits starting at 1. As previously stated, all PSA names must
be registered with ECS in advance of use.

If a given PSA has multiple values within a single product, this must be
accomplished by setting multiple instances of the PSA (as opposed to
setting ParameterValue to an array of values). This is accomplished by
repeatedly setting the AdditionalAttributeName to the same PSA name and
the ParameterValue to each value for the PSA, as many times as required
to store all of the values for that PSA. Please note, however, that the
total number of PSAs stored for a single product should be kept within
reasonable limits (\~100) to avoid abnormally long search times for
PSAs.

### Tracking and Production Archived Metadata Attributes 

# DESCRrevision -- This attribute was designed to label and track revisions to an existing ESDT Collection for a product at the DAAC and its associated MCF and be able to match this MCF at the DAAC with one being used for making the product at MODAPS. After a product is already being archived into an ESDT Collection, the SCF or other group sometimes would like to make a change in the metadata for the ESDT but keep same VersionID or Collection number. The ECS allows only certain types of changes. The DESCRrevision is an attribute of data type string in the format of "n.m", where n and m are digits. The first digit corresponds to the VersionID of the ESDT Collection. The first version is always "n.0". When the ESDT Descriptor and MCF are changed, the second digit "m" is incremented. In cases of a suspected discrepancy, this attribute provides a quick method to verify whether the version of the MCF being used at MODAPS is the same as the corresponding one at the DAAC.  {#descrrevision-this-attribute-was-designed-to-label-and-track-revisions-to-an-existing-esdt-collection-for-a-product-at-the-daac-and-its-associated-mcf-and-be-able-to-match-this-mcf-at-the-daac-with-one-being-used-for-making-the-product-at-modaps.-after-a-product-is-already-being-archived-into-an-esdt-collection-the-scf-or-other-group-sometimes-would-like-to-make-a-change-in-the-metadata-for-the-esdt-but-keep-same-versionid-or-collection-number.-the-ecs-allows-only-certain-types-of-changes.-the-descrrevision-is-an-attribute-of-data-type-string-in-the-format-of-n.m-where-n-and-m-are-digits.-the-first-digit-corresponds-to-the-versionid-of-the-esdt-collection.-the-first-version-is-always-n.0.-when-the-esdt-descriptor-and-mcf-are-changed-the-second-digit-m-is-incremented.-in-cases-of-a-suspected-discrepancy-this-attribute-provides-a-quick-method-to-verify-whether-the-version-of-the-mcf-being-used-at-modaps-is-the-same-as-the-corresponding-one-at-the-daac. .unnumbered}

# Processing Environment -- Science Team Members requested a metadata attribute to distinguish granules produced on a Linux box from those produced on IRIX hosts. The information is to be obtained by the PGE perl script as the value returned by the "uname --a" command on the processing host. The script will put the Processing Environment text string into LUN 800550 in the PCF. The PGE will read the string from this LUN and put it into the ProcessingEnvironment attribute in the MCF. {#processing-environment-science-team-members-requested-a-metadata-attribute-to-distinguish-granules-produced-on-a-linux-box-from-those-produced-on-irix-hosts.-the-information-is-to-be-obtained-by-the-pge-perl-script-as-the-value-returned-by-the-uname-a-command-on-the-processing-host.-the-script-will-put-the-processing-environment-text-string-into-lun-800550-in-the-pcf.-the-pge-will-read-the-string-from-this-lun-and-put-it-into-the-processingenvironment-attribute-in-the-mcf. .unnumbered}

**Production History --** This attribute contains the name and current
version of the PGE that is generating the product and the names and
versions of PGEs that generated the input products for each type of
ESDT. For PGEs with multiple processes, the process version may also be
included after the PGE version if it is relevant for distinguishing the
product from some other process version. The attribute has a maximum
string length of 255 characters. MODIS PGEs have versions in the format
of "n.m.o", where m,n, and o are digits. PGE02 has a fourth digit to
indicate the version of the L1B calibration LUT. The steps for building
the ProductionHistory string in the current PGE run are the following:

-   The current PGE should examine the ProductionHistory strings for the
    group of input granules of each ESDT and select the highest version
    of the PGE that generated each input product type.

-   The PGE should then concatenate the ProductionHistory strings from
    each of of these highest-version PGEs into an output
    ProductionHistory string in an order starting with the most
    downstream product to the most upstream product with a semicolon as
    the separator between PGE strings. See the examples below.

-   To build its own string of information, the current PGE should
    append its own PGE name to its own version using a colon as the
    separator between them. The PGE may also append its process name and
    version in the same way after the PGE version separated by a colon.
    However the 255-character limit must be considered.

-   The current PGE then should then append its own string of
    information to the front of the output ProductionHistory string
    using a semicolon as a separator. Now the ProductionHistory is ready
    for output into the Archived Metadata.

> Examples:
>
> "PGE30:4.3.2;PGE02:4.0.5.3;PGE01:4.1.6"
>
> "PGE10:4.10.8:modcol:4.10.6;PGE02:4.2.4.0;PGE01:4.1.6"

## Testing Approach

PGE testing at the SCF is expected to span the operational processing
hosts in use at the MODIS Adaptive Data Processing System (MODAPS),
which currently includes IRIX and Linux platforms. A minimum requirement
is that a PGE run under IRIX, but this is a less desirable
implementation due to the constraints it imposes on operational resource
usage and distribution. A concerted effort to port new PGEs to Linux
prior to delivery is expected. Not only will the processing system
benefit, but the PGE code too which will be more robust after removal of
bugs missed on IRIX.

In addition, PGE testing at the SCF should verify that processing
performs to expectations under both normal and abnormal conditions. The
SCF may simulate many abnormal conditions (e.g. data drop out) by
modifying existing operational MODIS products. The SCF must also verify
the correct processing of ancillary data and alternative data sources.

### Processing Host

The MODIS Adaptive Data Processing System (MODAPS) distributes
processing requests across IRIX and Linux host for Recipes and PGEs
certified portable by the science team. PGEs portable to IRIX only
should be identified early in the development cycle.

Below are several Linux-IRIX portability issues gleaned from the SDST
project.

a.  Little-endian and Big-endian System

Intel and Intel clone CPUs are little-endian, SGIs CPUs are big-endian.
Binary data files require the proper byte-order I/O to be meaningful.
Certain file formats, though, while binary are also portable because the
library code to read them expects a defined byte order. HDF and GRIB
files do not require byte swapping, nor do ASCII files.

b.  Compiler Options

> Only the most common compiler options are portable (-o, -c, -O1, -D).
> Many people never use more than those so most C compiles easily. In
> Fortran, only the basic common options will port. There isn't an easy
> solution, other than reading the manuals and testing different
> options.

c.  Makefiles

> MODIS currently uses a recursive makefile that is compatible with GNU,
> Clearcase, and MIPS make. Example:
>
> case \"\$(BRAND)\" in \\
>
> sgi32 \| sgi64 ) \\
>
> \$(MAKE) \$(TARGET) -f MOD_PR10.mk \\
>
> ADD_CFLAGS=\"-O3 -ffloat-store"\\
>
> ;; \\
>
> linux ) \\
>
> \$(MAKE) \$(TARGET) -f MOD_PR10.mk \\
>
> ADD_CFLAGS=\" -O3 -fwriteable-strings\" \\
>
> ;; \\

d.  Memory allocation

> Gnu compilers (for C) are not as forgiving when dealing with memory
> leaks as are MIPS compilers. Be sure that memory is properly allocated
> and managed.

### Anomalous Data Conditions

MODIS algorithm developers need actual MODIS data to test and improve
the quality of their science data product. They also need MODIS data to
ensure the development of robust code, code that is capable of running
over a global scene, 24 hours a day in a near real-time operational
environment. Below is a list of some operational situations that are
likely to occur over duration of the mission which should be handled
effectively by the processing software:

-   Missing MODIS/ancillary input products

-   Input products staged for wrong time period

-   Corrupted input products (unable to open/read)

-   Out-of-bounds data

-   Dead/Noisy/Saturated detectors

-   90-degree spacecraft yaw during inclination maneuvers

-   Missing MODIS scans/data drop outs

-   MODIS viewing off Earth

Some of these situations (dead detectors, missing scans) are easily
simulated by modifying actual MODIS HDF products to flag a subset of
detectors as dead or noisy, for instance, or to fill a scan or partial
scan with fill values or corrupt data. Rigorous testing of these
conditions prior to operational use will undoubtedly uncover processing
problems and save costly re-work and possible delays in product
generation.

### Ancillary/Alternative Data Identification

Some MODIS science algorithms rely on input products generated by
agencies external to the EOS program. A common requirement, for example,
is the need for Global Data Assimilation System (GDAS) products from
agencies like the National Center for Environmental Products (NCEP) or
the Fleet Numerical Meteorological Oceanographic Center (FNMOC). In such
cases, the developer must verify in advance that these products are
already available to the project or that an agreement to acquire new
ancillary data product can be established with the provider agency.
Initiating new agreements can be a lengthy process and should be started
at least three months prior to the operational use of these products.

A related concern is the adaptability of operational science software in
situations where anncillary inputs are late or missing. If required
input is unavailable and there is no suitable alternative product, then
the PGE will be deleted by operations after some reasonable wait period.
If, on the other hand, an alternative product is available, it will be
provided to the PGE via the PCF. The PGE must of course embody logic to
enable the switch and contain robust source code capable of properly
reading the alternate product. These features require careful testing at
the SCF prior to SDST delivery.

## 3.8 Process Versioning {#process-versioning .unnumbered}

A process is an executable that generates one or more products. Although
built from science software provided primarily by individual SCFs, it is
typically linked to software libraries including the SDP toolkit,
HDF-EOS library, operating system run-time libraries and in some cases,
other SDST and/or common discipline specific supplied libraries. A
change in any of components of the resulting executable or the data
product generated constitutes a version change. Tracking the process
version is the responsibility of the SCF. Below is the MODIS approach to
process versioning.

A process version consists of three parts: a major version number, a
minor version number, and an update number. Version 2.1.3, for instance,
has major version 2, minor version 1, and update version 3. The major
version number is incremented when process changes occur either in
preparation for, or following, a major project milestone. PGE changes
made in anticipation of reprocessing a new MODIS data collection is a
typical example. This allows the resynchronization of the versions of
the individual processes with the rest of the system. Whenever the major
version number is changed, the minor and update version numbers will be
reset to zero.

The minor version tracks significant changes in the science algorithm or
product. Whenever the minor version number is changed, the update
version number is reset to zero. This enables the user to determine
whether the current algorithm version represent important changes in the
data product or algorithm relative to some previous version.

The update number tracks all other changes, including, minor algorithm
changes that handle specific cases and do not impact a significant
amount of the data produced. Changes in error messages and minor changes
in the product format also fall into this category.

The decision on whether to increment the minor or update version number
is left to the individual scientist/developer. However, a large number
of increments in the minor version number, i.e., a large number of
changes in the science algorithm, are discouraged because they confuse
the end user and make analysis of multi-date data (time series) more
difficult.

# Delivery Process

Each STM is responsible for making his/her delivery to SDST
electronically. There are different options for how a delivery can be
made by the STM depending on whether they are making a partial or full
code delivery. These options are defined in section 4.1 of this
document.

## Delivery Process Overview

SDST uses the following process between the initial code delivery by the
STM and the final delivery from SSTG to CMO prior to thread testing:

1.  If the STM is preparing changes to an existing piece of code, then
    prior to working on any updates, the STM will retrieve the latest
    CMO baselined version. The default location for the Land,
    Atmospheres and Oceans disciplines is:
    /modisbaselinedcode/\<DISCIPLINE\>/STORE/\<PGE##\>/\<PROCESS ID\> on
    modular. For those versions of PGEs that are Aqua specific, the
    location for the Land, Atmospheres and Oceans disciplines baselined
    version is
    /modisbaselinedcode/\<DISCIPLINE\>/STORE_PM1M/\<PGE##\>/\<PROCESS
    ID\>.

2.  The STM makes a delivery electronically. There are different options
    for how a delivery can be made by the STM depending on whether they
    are making a partial or full code delivery.

```{=html}
<!-- -->
```
a)  For partial code deliveries, which are for minor changes or changes
    that only affect a limited number of files there are three delivery
    options.

b)  The STM can submit their changes by using the CMO provided delivery
    script and area

c)  The STM can place the modified files in a directory on a machine
    accessible by the SSTG Lead for their discipline and send an email
    notice to the SSTG Lead notifying them of the delivery, where it is
    located, what it consists of, and what the purpose of the changes
    are.

d)  The STM can email the changes directly to the SSTG Lead. Note: this
    option is intended for extremely minor changes, especially those
    where the STM is requesting the SSTG to modify a source code file.

e)  For full code deliveries, where all source code and process related
    files are being submitted by the STM, there are two delivery
    options.

f)  The STM can submit their changes by using the CMO provided delivery
    script and area

g)  The STM can place the modified files in a directory on a machine
    accessible by the SSTG Lead for their discipline and send an email
    notice to the SSTG Lead notifying them of the delivery, where it is
    located, what it consists of, and what the purpose of the changes
    are.

    Note that whether a full or partial code change is being submitted
    the STM should clearly indicate if any changes also include the
    removal of source code files. This information should be indicated
    either in the delivery email or the packinglist.

```{=html}
<!-- -->
```
3.  The SSTG discipline leads will pick up the code delivery and place
    it into a backup area and review it for completeness.

4.  [SSTG]() will notify CMO and I&T of receipt of code changes.

5.  SSTG completes the Configuration Management (CM) Transfer Checklist
    (shown in Appendix J), which is a final verification that all of the
    items required in the code delivery and as output of the code
    acceptance process are accounted for. Note that the contents of the
    CM Transfer Checklist closely match the content of the Packing List
    template found in Appendix D and the README template found in
    Appendix E.

The SDST development philosophy is to iterate with each of the science
algorithm developers until the software is baselined. Once the SCF
delivers software the SSTG will typically perform one or more of the
following tasks:

-   Evaluate code for standards compliance.

-   Integrate SDPTK I/O or error handling routines.

-   Integrate M-API.

-   Identify specific portions of the code which are resource intensive.

If significant changes are required, the software is returned to the SCF
for re-delivery. At that time, SSTG will discuss with the SCF the
changes and mutually agree on the content and schedule for the next
delta version. The next delta version could consist of an algorithm
update (performed by STM) or a further SDST software update (performed
by SDST). The turnaround time will normally be 10-15 working days,
depending on the nature of the changes.

## Algorithm Delivery Package Contents

The algorithm delivery package consists of the following items:

-   Source code.

-   Packing list (see Appendix D).

-   Readme files (see Appendix E).

-   Test data files (both input and output files).

-   Processing data file format descriptions (see Appendix G).

-   Product file specification.

-   Process specific seed files.

-   PCF (see Appendix H).

-   Production rules (see Appendix B).

One of the more dependable means of demonstrating that a new or changed
science algorithm has been properly transferred, compiled and run at the
TLCF is to compare output products generated at the SCF against TLCF
results. In the special case where the computer brands and operating
system versions are the same, the comparison data should match
identically. SDST relies on this match as the fundamental criterion for
accepting a new PGE version into the MODIS baseline.

To support the baseline process, the science team submits both input and
reference output test data as an integral component of a code delivery.
The test inputs should be granules of the actual MODIS and ancillary
data products that are planned as inputs for operational use. The ideal
amount of test data would be adequate to exercise all aspects of the PGE
code, including separate logic branches for PGEs that supports both
Terra and Aqua missions. Practical considerations, though, limit the
amount of testing possible. The actual amount of test data delivered is
left to the discretion of the science team.

The final delivery to CM shall include a Processing File Format
Description, a bit-level description of every data file the algorithm
needs to run, including ASCII LUTs, binary files including ancillary
data, and the output HDF product specification. If possible, processing
file format descriptions (except those for the HDF product
specifications, whose delivery is subject to the agreed-to schedules)
should be provided in advance of the final SCF delivery. The
SSTG-provided template (shown in Appendix G) shall be used for providing
the information on ASCII and binary files. The contents of Appendix G
along with sample inputs are available from the MODIS ftp site (see
table 2.2). The files are requested to be delivered in ASCII format to
alleviate formatting issues encountered while transitioning between SGIs
and MacIntosh or PC Word Processors.

Product file specifications are unique to each product. They define the
parameters to be generated and the structure of the file. All MODIS
products will be in HDF (or HDF-EOS). Actual MODIS file specifications
are available from the MODIS ftp site (see table 2.2).

Typically, no more than one seed file per process is needed. In some
cases, it may even be convenient to maintain a shared seed file that is
common to one or more PGEs.

## File Naming Conventions

The following conventions for file names have been adopted by MODIS for
ease of integration and testing.

### Delivery Package Files

The delivery package will contain several types of files: source code,
readme, production rules, processing file format, makefile, PCF, MCF,
and test. If the test files (input test data) are already in existence,
then just the names of the files need to be provided as part of the
delivery package. However, if the STMs use their own test data file,
those must accompany the delivery and follow the indicated naming
convention. Table 4-1 lists the naming conventions and/or the extensions
to be used for the other files in the package.

[]{#__RefHeading___Toc80090117 .anchor}Table 4-1. Naming Conventions

+---------------------------+------------------------------------------+
| **File Type**             | **Naming Convention**                    |
+===========================+==========================================+
| Ancillary data            | \<filename\>.anc                         |
+---------------------------+------------------------------------------+
| ASCII text file           | \<filename\>.txt                         |
+---------------------------+------------------------------------------+
| Borne shell script file   | \<filename\>.sh                          |
+---------------------------+------------------------------------------+
| C shell script file       | \<filename\>.csh                         |
+---------------------------+------------------------------------------+
| Coefficient file          | \<filename\>.coeff V\<PGE version\>      |
+---------------------------+------------------------------------------+
| File Specification        | ESDT.\< 20 char \>.fs                    |
+---------------------------+------------------------------------------+
| Header files              | \<filename\>.h                           |
+---------------------------+------------------------------------------+
| Include files             | \<filename\>.inc                         |
+---------------------------+------------------------------------------+
| Input test data file      | \<filename\>.hdf                         |
+---------------------------+------------------------------------------+
| Korn shell script file    | \<filename\>.ksh                         |
+---------------------------+------------------------------------------+
| Makefiles                 | \<process_id\>.mk                        |
+---------------------------+------------------------------------------+
| MCF                       | \<ESDT Name\>.mcf                        |
+---------------------------+------------------------------------------+
| Output test data file     | \<filename\>.hdf                         |
+---------------------------+------------------------------------------+
| Packing list              | PACKINGLIST.txt                          |
+---------------------------+------------------------------------------+
| PCF                       | \<process_id\>.pcf                       |
+---------------------------+------------------------------------------+
| Perl script file          | \<filename\>.pl                          |
+---------------------------+------------------------------------------+
| Processing file format    | \<filename\>.pff.doc                     |
+---------------------------+------------------------------------------+
| Production rules          | \<process_id\>\_pr.txt                   |
+---------------------------+------------------------------------------+
| Readme                    | README.txt                               |
+---------------------------+------------------------------------------+
| SMF seed file             | MODIS\_\<#\>.t                           |
+---------------------------+------------------------------------------+
| Source code C source      | \<filename\>.c                           |
| files                     |                                          |
|                           | \<filename\>.f                           |
| Fortran 77 source files   |                                          |
|                           | \<filename\>.f90                         |
| Fortan 90 source files    |                                          |
+---------------------------+------------------------------------------+

> NOTES:
>
> 1\. \<process_ID\> is as specified in Table B-1 of the SDPS
> Requirements Specification.
>
> 2\. \<filename\> is free format text.
>
> 4\. \<#\> is the SMF Seed file number.
>
> 5\. ESDT is the ESDT Shortname of the product (8 characters).
>
> 6\. \<20 char\> is free format text describing the product file.
>
> 7\. \<PGE_version\> is the x.y.z version of the process, or optionally
> x.y.z.a, where the additional .a index is used to distinguish multiple
> LUT versions associated with a single PGE version.

### Product File Names

Within the naming conventions, bolded items are literally part of the
name as indicated, while other parts of the name are defined as
indicated. These names are to be included in the metadata under
LocalGranuleID =. Use all the digits specified, e.g. for a two-digit
tile number 05 is correct but 5 is incorrect.

The ESDT within the LocalGranuleId, which is the FileName of the
products, reflects the satellite instrument of the data processed. For
Terra products the ESDT begins with the characters "MOD". For Aqua
products the ESDT begins with the characters "MYD". For Terra + Aqua
combined products the ESDT begins with "MCD".

#### Level-1A, Level-1B, and Level-2 Product Naming Convention

ESDT**.A**yyyyddd.hhmm.vvv.yyyydddhhmmss.**hdf** where:

\- ESDT represents the ESDT shortname of the product (eight characters),

\- **A** represents the Acquisition Date,

\- yyyyddd represents the four-digit year followed by the day number
(1-366) within the year, for the start of the granule,

\- hhmm represents the time of day applying to the start of the granule,
in hours and minutes,

\- vvv represents a three-digit version number , with leading zeroes as
needed, that matches the Collection number for the product,

\- yyyydddhhmmss represents the four digit year, day number (1-366)
within the year, hours, minutes, and seconds of a time at which the
granule was processed. These times should be UTC times, not local time
zone values,

\- **hdf** represents this is an hdf file.

#### Level-2G , Level-3 and Level-4 Product Naming Convention 

> (Atmosphere and Land)

ESDT.**A**yyyyddd\[.**h**\<hnum\>**v**\<vnum\>\].vvv.
yyyydddhhmmss**.hdf** where:

\- ESDT represents the ESDT shortname of the product,

\- **A** represents the Acquisition Date,

\- yyyyddd represents the four-digit year followed by day number (1-366)
within the year, for the the start of the granule within the file,

\- hnum is the two-digit tile number in the horizontal direction for the
global grid, and is zero-based (Note: Used for Land files only),

\- vnum is the two-digit tile number in the vertical direction for the
global grid, and is zero-based (Note: Used for Land files only),

\- vvv represents a three-digit version number , with leading zeroes as
needed, that matches the Collection number for the product,

\- yyyydddhhmmss represents the four digit year, day number (1-366)
within the year, hours, minutes, and seconds of a time at which the
granule was processed. These times should be UTC times, not local time
zone values,

\- **hdf** represents this is an hdf file.

#### Level-3 Product Naming Convention (Oceans)

ESDT.\<param\>.**A**yyyyddd.hhmm.**DD**yyyydddvvv.yyyydddhhmmss**.hdf**
(L3 space binner- msbin)

ESDT.\<param\>.**ADD**yyyyddd vvv.yyyydddhhmmss**.hdf** (L3 time binner-
mtbin)

where:

-   ESDT represents the ESDT shortname of the product,

\- \<param\> represents the PARAMETERNAME for the product, which can be
found within the metadata of the product.

\- **A** represents the Acquisition Date,

\- yyyyddd represents the four-digit year followed by day number (1-366)
within the year, for the the start of the granule within the file,

\- hhmm represents the time of day applying to the start of the granule,
in hours and minutes,

\- **DD** yyyddd represents the StartDataDay (four-digit year followed
by the day number (1-366) within the year),

\- vvv represents a three-digit version number for the product, which in
Oceans' case indicates not only the collection the product is a part of,
but whether or not it was generated as part of forward processing or
reprocessing. Forward processing is indicated by "0x0", with x
referencing the collection version. Reprocessing is indicated with
"0xy", with x referencing the collection version and y referencing the
times this data has been reprocessed.

\- yyyydddhhmmss represents the four digit year, day number (1-366)
within the year, hours, minutes, and seconds of a time at which the
granule was processed. These times should be UTC times, not local time
zone values,

\- **hdf** represents this is an hdf file.

#### 4.3.2.4 Browse Product Naming Convention {#browse-product-naming-convention .unnumbered}

The browse product are the normal file names with a "BROWSE." prefix.

BROWSE.filename.hdf

where:

\- BROWSE represents the a browse product prefix.

\- filename represents the corresponding file name

\- hdf represents this is an hdf file.

#### 4.3.2.5 File Naming Examples {#file-naming-examples .unnumbered}

a\. Land example - the fourth version of a Terra 16-day L3 BRDF-Adjusted
Reflectance product for March 6, 2003, at the 10th horizontal tile and
4th vertical tile, generated on March 3, 2004 at 2:26:07 pm would be
encoded as follows:

**MOD43B4. A2003065.h10v03.004.2004064142607.hdf**

b\. Oceans example - the fourth version of a Terra L3 ocean spacebinning
product for data collected on January 31, 2003 at 9:35 pm, dataday
January 31, 2003 generated on June 22, 2004 at 11:16:32 pm would be
encoded as follows:

**MOD28BD1. sst.A2003031.2135.DD2003031.040.2004174231632.hdf**

c\. Oceans example - the first reprocessing of the fourth version of the
Aqua L3 ocean time binning product for data collected for dataday May 1,
2003 generated on February 24, 2004 at 3:18:25 pm would be encoded as
follows:

**MYD28DD1.sst.ADD2003121.041.2004055151825.hdf**

d\. Atmospheres example - the third version of the Terra L2 cloud mask
product for January 1, 1999 at 08:30, generated on January 1, 1999 at
9:00:20 am would be encoded as follows:

**MOD35_L2.A1999001.0830.003.1999001090020.hdf**

e\. L1B example - the second version of the Terra L1B radiance product
for January 1, 1999 at 10:15, generated on January 1, 1999 at 9:00:20 am
would be encoded as follows:

**MOD021KM.A1999001.1015.002.1999001090020.hdf**

f.  Combined product example -- this is for products where both Terra
    and Aqua data are combined into one output product or the input to
    the product is a combined product containing both Aqua and Terra
    data. The ESDT reflects the fact that this is a combined product
    through the use of the leading characters "MCD". In this example the
    product is a Land 16-day L3 Global 0.05Deg CMG product for March 12,
    2003 generated on March 5, 2004 :

**MCD43C1.A2003065.004.2004065151610.hdf**

g.  Browse product example -- a browse file for the Terra land product
    in example a above.

**BROWSE. MOD43B4. A2003065.h10v03.004.2004064142607.hdf**

## Acceptance and Baselining Process

The science software will go through a series of steps before being
considered ready for integration testing at the TLCF. These constitute
the acceptance and baselining process. The basic process is initiated
when the STM delivers the software package to SSTG. The SSTG may or may
not need to iterate with the STM to correct files. Once the SSTG has
successfully accomplished their tasks, they submit the entire package to
CM for building of binary executables and baselining. The CMO checks the
package delivered by SSTG and again either accepts or rejects the
package. If the package is accepted, the package is then considered
baselined and subsequently forwarded to the integration team for their
testing. Whenever the CMO rejects a package, the deliverer of the
package (the SSTG) must make the noted corrections and redeliver the
entire package. Once the package is baselined, corrections due to
problem resolution from will require a new delivery of the entire
package. To facilitate this process, various directories and scripts
have been established.

### Configuration Management Officer Responsibilities

The SDST CMO is responsible for:

-   Maintaining the baselined set of the HDF product specifications and
    making the baselined set available on the MODIS ftp site;

-   Notifying the SCFs of changes to baselined HDF product
    specifications;

-   Checking in code deliveries from the SSTG after transfer activities
    are completed and inspecting the deliveries for completeness;

-   Maintaining the MODIS ftp site, and the associated archive of
    documents, templates, data sets, tables, etc.

The process of code acceptance, as described in Section 5, terminates
with the CMO certifying that all of the required elements of a
successful software delivery have been received. Until this
certification takes place, the delivered process cannot be moved to the
SDST Test Team for thread testing. Therefore, it is essential that the
SCF work closely with their SSTG contact to account for all of the
required elements. The CMO will maintain the deliveries under version
control in the IBM Rational ClearCase environment at the TLCF. Once the
hand-off to the DAAC is complete, DAAC personnel will be responsible for
managing the software in the IBM Rational. ClearCase environment at the
DAAC.

### Directory Structure and Access

A directory structure has been established to track the package through
the following steps:

1.  /DEV/IN/ process_ID = used for initial delivery by the STM to SSTG.

2.  /home/vobadm/scripts/SSTG_DLV_PGE.pl = used for delivery of SSTG
    modified packages (PGEs and/or LUTs) to CMO.

3.  A series of scripts are maintained in the CM repository which are
    used for CMO baselined packages.

(NOTE: process_ID is specified in the SDPS Requirements Specification.)

The protections on the directories will be as follows:

-   DEV/IN and the DEV/OUT directories will be set so that the SSTG
    programmer and the STM both have access to the appropriate
    directories.

-   modular:/mobisbaselinedcode will be readable by STM, SSTG, CMO, and
    Test Team.

Ftp can be used for the transfer. The following steps can be used as a
guide for making deliveries using ftp:

1.  Verify that you have ftp at your site. (It is standard on UNIX
    platforms.)

2.  Set your default to the directory where your files are at the SCF.

3.  Find out how to start ftp and attach to the modular machine - the
    command will likely be: ftp modular.nascom.nasa.gov.

4.  You will be asked to enter your modular account name and password.

5.  Change to the delivery directory for the process: *cd
    /DEV/IN/process_ID.*

6.  Copy files from the SCF to modular using the *put* command (e.g.,
    *put abc.c* where abc.c is a file in your SCF directory). Use the
    *mput* command with wild cards (e.g., *mput \*.c*) for multiple
    files.

7.  Verify that all the files you want to move to modular are actually
    there.

8.  Enter *bye* or *quit* to exit ftp.

To pick up your files from the OUT, a similar sequence of steps would be
done except that once you had connected to modular, you would *cd
/DEV/OUT/process_ID* and use the *get (or mget)* command to copy files
from modular to the SCF. For larger deliveries, you may opt to use *tar*
to compress the files before transferring to or from the TLCF. The SSTG
uses the /DEV/INto pick up the package for their use. The CMO is
responsible for removing the files from the /DEV/IN directory once SSTG
have copied them to their working directory.

### Scripts and Their Usage

To support file specification and code deliveries to CM, scripts have
been developed which must be run at each step of the delivery process.
These scripts move files, change protection (ownership) of the
directory, and automatically sends e-mail to the appropriate personnel
to inform them of the progress of the package through the process. All
the scripts needed by STM are located in /DEV. Scripts needed by the
SSTG and CMO are maintained under version control in IBM Rational
ClearCase. Table 4-2 summarizes the scripts and their functionality.

[]{#__RefHeading___Toc80090118 .anchor}Table 4-2. Submittal Package
Acceptance/Baselining Scripts

  -------------------------------------------------------------------------------
  **Script**                 **Function**
  -------------------------- ----------------------------------------------------
  SPEC_IN                    Run by the STM when file specifications are
                             delivered to /DEV/IN directory. SSTG retrieves the
                             files from this directory.

  DEV_IN                     Run by the STM when the delivery is made, it changes
                             ownership of the files to CM. SSTG retrieves the
                             files from this directory.

  SSTG_DLV_PGE.pl            SSTG notifies CM that a delivery is ready for
                             baselining.

  CM_MERGE_SSTG_DLV_PGE.pl   CMO picks up the SSTG delivery.

  CM_LABEL_SSTG_DLV_PGE.pl   CMO completes the baselining progess; notifies SSTG,
                             STM, Integration and Testing.

  BASELINE_REJECT            CMO rejects SSTG delivery
  -------------------------------------------------------------------------------

The CMO stores binary executables, perl scripts, and MCFs for each PGE
in a controlled holding area for subsequent installation into
Integration and Testing environment.

## Iterations with SDST SSTG Staff

An SSTG programmer is assigned to work with one or more SCF algorithms.
The SSTG programmer will review each algorithm, suggest changes, and
make changes in coordination with the STM.

The following outlines the process for the STM and SSTG programmers to
follow for making updates to the code. The SSTG recognizes that this
process will vary from STM to STM with some STMs preferring to make all
necessary code changes themselves and others preferring the SSTG staff
to make the changes for them. Note that in the following steps, STM may
refer to the STM's designee:

1.  Early in development, the STM and SSTG programmer coordinate with
    each other to determine the division of labor between the two
    groups. These tasks should be small in scope to provide quick
    turnaround to the STM, so that the work of the STM and the SSTG
    programmer do not interfere. The programmer will also try to be
    cognizant of time when the STM will not be working on the algorithm,
    and make best use of that time. New/incremental deliveries by the
    STMs will follow steps outlined above.

2.  Changes made by the SSTG programmer will be summarized and
    documented in the prologue. Detailed description of changes will be
    documented within the code itself.

3.  The SSTG programmer tests the program with the STM supplied tests to
    verify that the same results are obtained, and the programmer uses
    the standards checker to verify all standards were followed.

4.  The SSTG programmer modifies the code as necessary as a result of
    these tests.

5.  The SSTG programmer stores the new version in the development
    library for tracking purposes.

6.  The SSTG programmer sends an e-mail message to the STM to inform
    him/her to pick up the latest version of the code from that
    directory.

7.  If no major changes are required (STM accepts the changes performed
    by the SSTG), the SSTG runs the SSTG_IN script which places the
    software package in the /SSTGIN directory and notified the CMO.

If the STM chooses not to accept a particular delivery from the SSTG
programmer, the STM will review the reasons for that with the SSTG
programmer. Some items such as the use of the SDPTK are not negotiable,
other items such as optimization of the code are negotiable. To assist
in code optimization efforts, SSTG can provide outputs of various
profiling tools (e.g., *prof* and *pixie*) which analyze the execution
patterns of the code and can be used to determine processing
bottlenecks.

If the STM and the SSTG programmer can not resolve an issue between
themselves, the SSTG programmer will notify the SSTG lead, and will work
with the STM to resolve it.

The SSTG will attempt to limit the number of different SSTG members with
which a STM has to work; typically it will be a single individual but
occasionally a second may offer assistance due to the number of
algorithms delivered by some STMs. Initial assignments of SSTG
programmers to STMs will occur internally to SSTG prior to the delivery,
but they will be adjusted as the SSTG evaluates the deliveries that are
received and workloads fluctuate.

## Aqua and Terra Specific PGEs

Traditionally MODIS PGEs are intended for use in processing both Aqua
and Terra data. However, the STM may find that an Aqua or Terra specific
version of a process is necessary.

When it becomes necessary to split an existing process into customized
versions for Aqua or Terra data the SCF should proceed as follows:

1.  The SCF should communicate this need to the SSTG lead so that they
    can discuss having separate versions of the algorithm, one for each
    SatelliteInstrument.

2.  The SCF and SSTG lead will establish the versioning of Aqua and
    Terra specific PGE versions. Ideally the Aqua specific version and
    Terra specific version would not carry the same PGEVersion.

3.  The same PGE number will continue to be used for both the Aqua
    specific and Terra specific versions of the Algorithm. However, the
    source code and related files will be stored on separate,
    SatelliteInstrument specific branches within ClearCase for ease of
    update and to prevent Terra specific code from being used on Aqua
    data or Aqua specific code from being used on Terra data.

4.  The ESDTs for Terra and Aqua specific process versions will remain
    as they were when generated by a single algorithm. For example MOD29
    for Terra and MYD29 for Aqua, are generated by PGE08 process
    MOD_PR29, however, the algorithms used to generate these products
    are separate and specific to the SatelliteInstrument.

5.  Delivery of the Aqua or Terra specific algorithms should be made as
    set forth in section 4.1, however the SCF needs to clearly mark
    within the delivery notification which SatelliteInstrument the code
    change is intended for.

If a new PGE is intended for use on only Aqua or Terra data, then the
SCF should establish this during the development of the PGE and
communicate that information to the SSTG Lead. This is the only
difference in preparing a new PGE intended for use on both Aqua and
Terra data and preparing a SatelliteInstrument specific PGE.

## Combined Product Generation

In some cases the SCF may wish to generate combined products. Combined
products are defined as products that contain both Terra and Aqua data.
The process generating the combined product either stages both Terra and
Aqua products as inputs simultaneously, or stages combined products as
input. As described earlier in this document, the ESDTs for combined
products have the leading characters of "MCD".

Addition of a combined product to an existing PGE is similar to the
addition of any product to an existing PGE.

1.  The SCF contacts the SSTG lead to convey this planned addition.

2.  The SCF and SSTG Lead determine the schedule for when the code
    changes will arrive as well as what affects the change will have on
    production rules.

3.  The production rules are revised to clearly state what processing
    approach should be used if Aqua or Terra data is missing for all or
    part of the period to be processed; i.e, does processing take place
    with just Terra or just Aqua data when the other is missing?

4.  The SSTG lead and SCF iterate over the ESDT request for the combined
    product so it is generated properly. The ESDT request is then
    submitted to the Systems Analyst for review who then submits the
    request to ECS for generation of the mcf and ESDT descriptor. Note
    that the metadata requirements for combined products differ from a
    strictly Terra or strictly Aqua product. See Appendix M for metadata
    requirements.

# Programming Guidelines/Recommendations

## Production System Related Items

Processing within a production system requires certain precautions be
taken by the programmers developing software for inclusion in the
production system. Processing within the ECS uses an automated scheduler
to launch jobs which results in certain restrictions in processing
requirements. The following is a list of considerations to be taken into
account by the STM programmers while designing their software.

-   Granule size has not been frozen, so programmers should NOT code to
    an explicit number of scans in a granule but should use a variable
    which can be set outside the code to define the size of the granule.

-   There is no guarantee that the file staged is in fact the file the
    process needs. Programmers should modify their code to perform some
    input file validation such as reading the metadata to confirm the
    file is the correct file or comparing each file's metadata to verify
    the file times/geographic regions coincide and set the exit code to
    non-zero if they do not match.

-   Programmers should not depend on the file names to be the names they
    used while testing their code - therefore, parsing a file name to
    obtain information about the file should NOT be done. Use file
    metadata to find out information about the file content.

-   Programmers should NOT assume any specific order of file staging. If
    you ask for multiple files (say all the files in a day) , they may
    be retrieved "out of order" and therefore a process may need to be
    capable of processing hour 9 before hour 8. Alternatively, the STM
    may want to sort the retrieved files before beginning processing on
    the files.

-   Run time parameters can only be set to fixed values for a specific
    PGE, so multiple values constitute a new PGE!

    1.  **EXCEPTION:** Multiple values for data day for Oceans and Tile
        numbers will NOT constitute a new PGE.

-   Temporary files should be deleted by the process which created them.

-   Since the MODAPS IRIX and Linux processing hosts have limited memory
    resources, developers should carefully consider PGE memory usage.
    It\'s recommended that each PGE limit memory usage to a maximum of
    250 MB.

-   Although MODAPS does not impose a hard limit on product file size,
    SGI and HDF do have file size limits of 2 GB. We strongly suggest
    PGE developers constrain product size to less than 500 MB.

-   MODAPS does not currently specify limits on CPU usage or a maximum
    number of input files to a PGE or process.

## Platform Related Items

-   SGI compilers create code by default whose runtime behavior is to
    continue processing when floating point exceptions are encountered
    (division by zero, domain errors, under/ overflow, etc.).

    It is possible to change this behavior so that ftps can be traced,
    counted, or will cause the code to abort. See "man sigfpe". The
    simple was to do this is to link with "\_lfpe" and setenv TRAP_FPE
    when the code is run. For example: setenv TRAP_FPE "ALL COUNT".

-   Developers should check for these exceptions. If "ALL-ABORT" is used
    for development, these errors can easily be located in the code
    using dbx. For example:

    \> make -f myprogram.mk (compile with "-g -O0", link with -lfpe)

    \> setenv TRAP_FPE "ALL=ABORT"

    \> dbx myprogram

    (dbx) stop in exit (stop at any code exit point including aborts)

    (dbx) run (\...code runs and aborts on an error)

    (dbx) up (repeat until you see your source, then print values of
    suspicious variables)

-   Developers should ensure conformance to the IEEE floating point
    standards, to ensure compatability across different platforms.

    For the GNU C and Fortran compliers on Linux platforms, this
    requires the use of the --ffloat-store compiler option.

    For the Portland Group Fortran 90 compiler on Linux platforms, this
    requires use of the --ieee compiler option.

APPENDIX A: Acronyms

API Application Program Interface

ATBD Algorithm Theoretical Basis Document

CCSDS Consultative Committee for Space Data Systems

CM Configuration Management

CMO Configuration Management Officer

DAAC Distributed Active Archive Center

DSS Data Server Subsystems

DP Data Provider

DPS Data Production Software

ECS EOSDIS Core System

EOS Earth Observing System

EOSDIS Earth Observing System Data and Information System

ESDIS Earth Science Data and Information System

ESDT Earth Science Data Type

FNMOC Fleet Numerical Meteorological Oceanographic Center

GCTP General Carteographic Transformation Package

GCMD Global Climate Modeling Data

GDAAC Goddard Distributed Active Archive Center

GE Gdorigin

GES Goddard Earth Sciences

GSFC Goddard Space Flight Center

HDF Hierarchical Data Format

I/O Input/Output

JPEG Join Photographic Experts Group

L1 Level 1

L2 Level 2

L2G Level 2G

L3 Level 3

L4 Level 4

LUN Logical Unit Number

LUT Look-Up Table

M-API MODIS-Application Program Interface

MCF Metadata Configuration File

MET Metadata

MODAPS MODIS Adaptive Processing System

MODIS Moderate Resolution Imaging Spectroradiometer

MTPE Miissions to Planet Earth

NASA National Aeronautics and Science Administration

NCEP National Centers for Environmental Prediction

NCSA National Center for Supercomputing Applications

NMC National Meteorological Center

NSIDC National Snow and Ice Data Center

ODL Object Description Language

PCF Process Control File

PCR Product Change Request

PGE Product Generation Executive

PSA Product-Specific Attributes

PVL Parameter Value Language

QA Quality Assurance

SCF Science Computing Facility

SDP Science Data Processing

SDPS Science Data Processing Segment

SDPTK Science Data Production Toolkit

SDS Science Data Set

SDST Science Data Support Team

SMF Status Message Facility

SSTG Science Software Transfer Group

STM Science Team Member

TK Toolkit

TLCF Team Leader Computing Facility

UR Universal Reference

URL Universal Resource Locator

WWW World Wide Web

APPENDIX B: PRODUCTION RULE EXAMPLE

MOD_PR35 Production Rules

=======================

Overview

=======================

Run MOD_PR35 night and day on each MODIS L2 granule if, at the time all
required inputs are present, all optional inputs are also present. If
any or all optional inputs are absent, run without them.

Note: MOD_PR35 production rules treat GDAS_0ZF as an optional product,
different from PGE03 where it is a required input (by Profiles).

=======================

Required Input Products

=======================

MODIS Products:

ESDT Name Description

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-- \-\-\-\-\-\-\-\-\-\-\-\-\-\--

MOD021KM MODIS/Terra Calibrated Radiances 5-Min L1B Swath 1km

MOD03 MODIS/Terra Geolocation Fields 5-Min L1A Swath 1km

Static File Inputs:

ESDT Name Description

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-- \-\-\-\-\-\-\-\-\-\-\-\-\-\--

MOD35ANC Olson World Ecosystem Maps at 10 minute and 1 km resolutions
and MOD_PR35 thresholds parameter file.

Ancillary Products:

ESDT Name Description

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-- \-\-\-\-\-\-\-\-\-\-\-\-\-\--

SEA_ICE NCEP Ice Concentration on 1/2 degree lat/lon projection.

NISE NSIDC Near Real-Time SSM/I EASE-Grid Daily Global Ice

> Concentration and Snow Extent product

Selection Rule: SEA_ICE

This product contains ECS SingleDateTime metadata. Search a 14-day time

interval centered on the MODIS collection period midpoint. Choose the

ancillary granule whose SingleDateTime is within the search interval and

nearest the collection midpoint. If no matching SEA_ICE granules are

found, delete the processing request.

Selection Rule: NISE

This product contains ECS RangeDateTime metadata. Search a 7-day time

interval centered twenty-four hours ahead of the MODIS collection period

midpoint. Choose the ancillary granule whose RangeDateTime midpoint is

within the search interval and nearest its midpoint. If after delaying,

no matching NISE granules are found, delete the processing request.

=======================

Optional Input Products

=======================

MODIS Products:

> Time Out

ESDT Name (in sec) Description

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-- \-\-\-\-\-\-\-\-\-\-\-\--
\-\-\-\-\-\-\-\-\-\-\-\-\-\--

MOD02QKM 0 MODIS/Terra Calibrated Radiances 5-Min L1B

> Swath 250m

Ancillary Products:

> Time Out

ESDT Name (in sec) Description

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-- \-\-\-\-\-\-\-\-\-\-\-\--
\-\-\-\-\-\-\-\-\-\-\-\-\-\--

GDAS_0ZF 0 1 degree NCEP GDAS final run

Selection Rule: MOD02QKM

Choose granule whose RangeDateTime metadata matches the MODIS data

collection period.

Selection Rule: GDAS_0ZF

This is a 4-times daily product containing ECS \"SingleDateTime\"
metadata

at GMT times 0Z, 6Z, 12Z or 24Z. Choose the GDAS_0ZF granule whose

SingleDateTime falls within a 6-hour window (exclusive of the end point)

centered on the MODIS data collection period midpoint.

===============

Output Products

===============

ESDT Name Description

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-- \-\-\-\-\-\-\-\-\-\-\-\-\-\--

MOD35_L2 MODIS/Terra Cloud Mask and Spectral Test Results 5-Min

> L2 Swath 250m and 1km

MOD35_QC MODIS/Terra Cloud Mask and Spectral Test Diagnostics

> 5-Min L2 250m and 1km

Appendix C: HDF-EOS and Grid Examples

C.1 HDF-EOS Example 1: Swath with Full Resolution External Geolocation
Data Set

C.1.1 Code

/\* HDF/HDFEOS/exp_2/swath_part_1b/MOD_SW_2b1.c \*/ #include \"mfhdf.h\"

#include \"HdfEosDef.h\"

#define FILENAMEIN \"L1B_2b0a.HDF\"

#define FILENAMEOUT \"MOD_SW_2b1.HDF\"

#define TRACK 100

#define XTRACK 1354

int16 buffer\[TRACK\]\[XTRACK\];

float32 geobuffer\[TRACK\]\[XTRACK\];

int main ()

{

int stat, t, xt;

int32 SWfidin, SWidin, SWfidout, SWidout; int32 rank=2,
start\[2\]={0,0}, edge\[2\]={TRACK,XTRACK}; SWfidout = SWopen
(FILENAMEOUT, DFACC_CREATE);

SWidout = SWcreate (SWfidout, \"MODIS_Swath_Type_1a\"); stat = SWdefdim
(SWidout, \"Track\", TRACK);

stat = SWdefdim (SWidout, \"Xtrack\", XTRACK);

stat = SWdefdatafield (SWidout, \"Band_5\", \"Track,Xtrack\",

DFNT_INT16, HDFE_NOMERGE);

stat = SWdefgeofield (SWidout, \"Latitude\", \"Track,Xtrack\",

DFNT_FLOAT32, HDFE_NOMERGE);

stat = SWdefgeofield (SWidout, \"Longitude\", \"Track,Xtrack\",

DFNT_FLOAT32, HDFE_NOMERGE);

stat = SWdetach(SWidout);

SWfidin = SWopen(FILENAMEIN, DFACC_READ); SWidin = SWattach(SWfidin,
\"MODIS_Swath_Type_1a\"); stat = SWreadfield(SWidin, \"Band_5\", start,
NULL, edge, buffer); stat = SWdetach(SWidin);

stat = SWclose(SWfidin);

SWidout = SWattach(SWfidout, \"MODIS_Swath_Type_1a\"); stat =
SWwritefield (SWidout, \"Band_5\", start, NULL, edge,

buffer);

stat = SWdetach(SWidout);

stat = SWclose(SWfidout);

}

C.1.2 Corresponding Sample File Specification Addendum

SwathStructures

SwathName=\"MODIS_Swath_Type_1a\"

Dimensions

Dimension_1, \"Track\", Size=100

Dimension_2, \"Xtrack\", Size=1354

GeoField

Location: external

GeoField_1, \"Latitude\", DFNT_FLOAT32,

(\"Track\",\"Xtrack\")

GeoField_2, \"Longitude\", DFNT_FLOAT32,

(\"Track\",\"Xtrack\")

DataField

DataField_1, \"Band_5\", DFNT_INT16,

(\"Track\",\"Xtrack\")

C.1.3 Output File

MOD_SW_2b1.HDF

There are 3 datasets and 1 global attribute in this file.

Available Dataset:

Band_5: rank 2, dimensions \[100, 1354\] of signed 16-bit integers.

Latitude: rank 2, dimensions \[100, 1354\] of 32-bit floating point
numbers.

Longitude: rank 2, dimensions \[100, 1354\] of 32-bit floating point
numbers.

Global attributes :

Attribute StructMetadata.0 has the value : GROUP=SwathStructure

GROUP=SWATH_1

SwathName=\"MODIS_Swath_Type_1a\"

GROUP=Dimension

OBJECT=Dimension_1

DimensionName=\"Track\"

Size=100

END_OBJECT=Dimension_1

OBJECT=Dimension_2

DimensionName=\"Xtrack\"

Size=1354

END_OBJECT=Dimension_2

END_GROUP=Dimension

GROUP=DimensionMap

END_GROUP=DimensionMap

GROUP=IndexDimensionMap

END_GROUP=IndexDimensionMap

GROUP=GeoField

OBJECT=GeoField_1

GeoFieldName=\"Latitude\"

DataType=DFNT_FLOAT32

DimList=(\"Track\",\"Xtrack\")

END_OBJECT=GeoField_1

OBJECT=GeoField_2

GeoFieldName=\"Longitude\"

DataType=DFNT_FLOAT32

DimList=(\"Track\",\"Xtrack\")

END_OBJECT=GeoField_2

END_GROUP=GeoField

GROUP=DataField

OBJECT=DataField_1

DataFieldName=\"Band_5\"

DataType=DFNT_INT16

DimList=(\"Track\",\"Xtrack\")

END_OBJECT=DataField_1

END_GROUP=DataField

GROUP=MergedFields

END_GROUP=MergedFields

END_GROUP=SWATH_1

END_GROUP=SwathStructure

GROUP=GridStructure

END_GROUP=GridStructure

GROUP=PointStructure

END_GROUP=PointStructure END

Vgroups:

Vgroup MODIS_Swath_Type_1a of class SWATH has 3 elements. Vgroup
MOD_SW_2b1.HDF of class CDF0.0 has 6 elements.

There are 3 elements in Vgroup MODIS_Swath_Type_1a :

Vgroup Geolocation Fields of class SWATH Vgroup has 2 elements. Vgroup
Data Fields of class SWATH Vgroup has 1 element. Vgroup Swath Attributes
of class SWATH Vgroup is empty.

There are 2 elements in Vgroup Geolocation Fields :

HDF object : Numeric Data Group (Ref = 7) HDF object : Numeric Data
Group (Ref = 8)

There is 1 element in Vgroup Data Fields :

HDF object : Numeric Data Group (Ref = 6)

There are 6 elements in Vgroup MOD_SW_2b1.HDF :

Vgroup Track:MODIS_Swath_Type_1a of class Dim0.0 has 2 elements. Vgroup
Xtrack:MODIS_Swath_Type_1a of class Dim0.0 has 2 elements. Vgroup Band_5
of class Var0.0 has 6 elements. Vgroup Latitude of class Var0.0 has 5
elements. Vgroup Longitude of class Var0.0 has 5 elements. Vdata
StructMetadata.0 of class Attr0.0.

This Vdata contains the field VALUES : {see above}

There are 2 elements in Vgroup Track:MODIS_Swath_Type_1a :

Vdata Track:MODIS_Swath_Type_1a of class DimVal0.1.

This Vdata contains the field Values : 100. Vdata
Track:MODIS_Swath_Type_1a of class DimVal0.0

contains 100 records. This Vdata contains the field Values .

There are 2 elements in Vgroup Xtrack:MODIS_Swath_Type_1a :

Vdata Xtrack:MODIS_Swath_Type_1a of class DimVal0.1.

This Vdata contains the field Values : 1354. Vdata
Xtrack:MODIS_Swath_Type_1a of class DimVal0.0

contains 1354 records. This Vdata contains the field Values .

There are 6 elements in Vgroup Band_5 :

Vgroup Track:MODIS_Swath_Type_1a of class Dim0.0 has 2 elements. Vgroup
Xtrack:MODIS_Swath_Type_1a of class Dim0.0 has 2 elements. HDF object :
Scientific Data (Ref = 9)

HDF object : Number type (Ref = 16)

HDF object : SciData dimension record (Ref = 16) HDF object : Numeric
Data Group (Ref = 6)

There are 5 elements in Vgroup Latitude :

Vgroup Track:MODIS_Swath_Type_1a of class Dim0.0 has 2 elements. Vgroup
Xtrack:MODIS_Swath_Type_1a of class Dim0.0 has 2 elements. HDF object :
Number type (Ref = 18)

HDF object : SciData dimension record (Ref = 18) HDF object : Numeric
Data Group (Ref = 7)

There are 5 elements in Vgroup Longitude :

Vgroup Track:MODIS_Swath_Type_1a of class Dim0.0 has 2 elements. Vgroup
Xtrack:MODIS_Swath_Type_1a of class Dim0.0 has 2 elements. HDF object :
Number type (Ref = 20)

HDF object : SciData dimension record (Ref = 20) HDF object : Numeric
Data Group (Ref = 8)

C.2 HDF-EOS Example 2: Single Swath with High Resolution Data Array

The HDF-EOS Example 2 is a single swath with high resolution (250m) data
array, and a normal (1km) resolution geolocation (Latitude, Longitude)
data set taken from the L1B (simulated) file.

C.2.1 Code

/\* MOD_SW_2b2a.c \*/

#include \"hdf.h\"

#include \"mfhdf.h\"

#include \"HdfEosDef.h\"

#define FILENAMEIN \"L1B_2b0b.HDF\"

#define FILENAMEOUT \"MOD_SW_2b2a.HDF\"

#define NBAND 2

#define TRACK 400

#define XTRACK 5416

#define COARSE 4

#define TRACK_OFFSET 1

#define XTRACK_OFFSET 0

#define COARSE_TRACK 100

#define COARSE_XTRACK 1354

int16 buffer\[TRACK\]\[XTRACK\];

float32 c_geobuffer_lat\[COARSE_TRACK\]\[COARSE_XTRACK\];

float32 c_geobuffer_lon\[COARSE_TRACK\]\[COARSE_XTRACK\];

int main ()

{

int stat;

int32 SWfidin, SWidin, SWfidout, SWidout;

int32 rank=2, start\[2\]={0,0}, edge\[2\]={TRACK,XTRACK};

int32 c_edge\[2\]={COARSE_TRACK,COARSE_XTRACK};

float32 fractional_offset\[2\]={0.5,0.0};

int32 HDFfid, SDid;

SWfidout = SWopen (FILENAMEOUT, DFACC_CREATE);

SWidout = SWcreate (SWfidout, \"MODIS_Swath_Type_1c\");

stat = SWdefdim (SWidout, \"Track\", TRACK);

stat = SWdefdim (SWidout, \"Xtrack\", XTRACK);

stat = SWdefdim (SWidout, \"Coarse_Track\", COARSE_TRACK);

stat = SWdefdim (SWidout, \"Coarse_Xtrack\", COARSE_XTRACK);

stat = SWdefdimmap (SWidout, \"Coarse_Track\", \"Track\", TRACK_OFFSET,
COARSE);

stat = SWdefdimmap (SWidout, \"Coarse_Xtrack\", \"Xtrack\",
XTRACK_OFFSET, COARSE);

stat = SWdefdatafield (SWidout, \"Band_5\", \"Track,Xtrack\",

DFNT_INT16, HDFE_NOMERGE);

stat = SWdefgeofield (SWidout, \"Latitude\",

\"Coarse_Track,Coarse_Xtrack\",

DFNT_FLOAT32, HDFE_NOMERGE);

stat = SWdefgeofield (SWidout, \"Longitude\",

\"Coarse_Track,Coarse_Xtrack\",

DFNT_FLOAT32, HDFE_NOMERGE);

stat = SWdetach(SWidout);

SWidout = SWattach(SWfidout, \"MODIS_Swath_Type_1c\");

SWfidin = SWopen(FILENAMEIN, DFACC_READ);

SWidin = SWattach(SWfidin, \"MODIS_Swath_Type_1b\");

stat = SWreadfield(SWidin, \"Band_5\", start, NULL, edge, buffer);

stat = SWreadfield(SWidin, \"Latitude\", start, NULL, c_edge,
c_geobuffer_lat);

stat = SWreadfield(SWidin, \"Longitude\", start, NULL, c_edge,
c_geobuffer_lon);

stat = SWdetach(SWidin);

stat = SWclose(SWfidin);

stat = SWwritefield (SWidout, \"Band_5\", start, NULL, edge, buffer);

stat = SWwritefield (SWidout, \"Latitude\", start, NULL, c_edge,
c_geobuffer_lat);

stat = SWwritefield (SWidout, \"Longitude\", start, NULL, c_edge,
c_geobuffer_lon);

stat = EHidinfo(SWfidout, &HDFfid, &SDid);

stat = SDsetattr(SDid,
\"HDFEOS_FractionalOffset_Track_MODIS_Swath_Type_1c\", DFNT_FLOAT32, 1,
(char \*)&fractional_offset\[0\]);

stat = SDsetattr(SDid,
\"HDFEOS_FractionalOffset_Xtrack_MODIS_Swath_Type_1c\", DFNT_FLOAT32, 1,
(char \*)&fractional_offset\[1\]);

stat = SWdetach(SWidout);

stat = SWclose(SWfidout);

}

C.2.2 Corresponding Sample File Specification Addendum

SwathStructures

SwathName=\"MODIS_Swath_Type_1c\"

Dimensions

Dimension_1, \"Track\", Size=400

Dimension_2, \"Xtrack\",Size=5416

Dimension_3, \"Coarse_Track\", Size=100

Dimension_4, \"Coarse_Xtrack\", Size=1354

DimensionMaps

DimensionMap_1

GeoDimension=\"Coarse_Track\"

DataDimension=\"Track\"

Offset=1

Increment=4

DimensionMap_2

GeoDimension=\"Coarse_Xtrack\"

DataDimension=\"Xtrack\"

Offset=0

Increment=4

GeoField

Location: internal

GeoField_1: \"Latitude\", DFNT_FLOAT32

(\"Coarse_Track\",\"Coarse_Xtrack\")

GeoField_2: \"Longitude\", DFNT_FLOAT32

(\"Coarse_Track\",\"Coarse_Xtrack\")

DataField

DataField_1: \"Band_5\", DFNT_INT16

(\"Track\",\"Xtrack\")

Global attributes

HDFEOS_FractionalOffset_Track_MODIS_Swath_Type_1c (DFNT_FLOAT32, Count =
1)

HDFEOS_FractionalOffset_Xtrack_MODIS_Swath_Type_1c (DFNT_FLOAT32, Count
= 1)

C.2.3 Output File

MOD_SW_2b2a.HDF

\*\*\*\* from ncdump --h \*\*\*\*

netcdf MOD_SW_2b2a {

dimensions:

Track_MODIS_Swath_Type_1c = 400 ;

Xtrack_MODIS_Swath_Type_1c = 5416 ;

Coarse_Track_MODIS_Swath_Type_1c = 100 ;

Coarse_Xtrack_MODIS_Swath_Type_1c = 1354 ;

variables:

short Band_5(Track_MODIS_Swath_Type_1c, Xtrack_MODIS_Swath_Type_1c) ;

float Latitude(Coarse_Track_MODIS_Swath_Type_1c,
Coarse_Xtrack_MODIS_Swath_Type_1c) ;

float Longitude(Coarse_Track_MODIS_Swath_Type_1c,
Coarse_Xtrack_MODIS_Swath_Type_1c) ;

// global attributes:

:HDFEOSVersion = \"HDFEOS_V2.4\" ;

:StructMetadata_0 = \"GROUP=SwathStructure\\n\",

\" GROUP=SWATH_1\\n\",

\" SwathName="MODIS_Swath_Type_1c"\\n\",

\" GROUP=Dimension\\n\",

\" OBJECT=Dimension_1\\n\",

\" DimensionName="Track"\\n\",

\" Size=400\\n\",

\" END_OBJECT=Dimension_1\\n\",

\" OBJECT=Dimension_2\\n\",

\" DimensionName="Xtrack"\\n\",

\" Size=5416\\n\",

\" END_OBJECT=Dimension_2\\n\",

\" OBJECT=Dimension_3\\n\",

\" DimensionName="Coarse_Track"\\n\",

\" Size=100\\n\",

\" END_OBJECT=Dimension_3\\n\",

\" OBJECT=Dimension_4\\n\",

\" DimensionName="Coarse_Xtrack"\\n\",

\" Size=1354\\n\",

\" END_OBJECT=Dimension_4\\n\",

\" END_GROUP=Dimension\\n\",

\" GROUP=DimensionMap\\n\",

\" OBJECT=DimensionMap_1\\n\",

\" GeoDimension="Coarse_Track"\\n\",

\" DataDimension="Track"\\n\",

\" Offset=1\\n\",

\" Increment=4\\n\",

\" END_OBJECT=DimensionMap_1\\n\",

\" OBJECT=DimensionMap_2\\n\",

\" GeoDimension="Coarse_Xtrack"\\n\",

\" DataDimension="Xtrack"\\n\",

\" Offset=0\\n\",

\" Increment=4\\n\",

\" END_OBJECT=DimensionMap_2\\n\",

\" END_GROUP=DimensionMap\\n\",

\" GROUP=IndexDimensionMap\\n\",

\" END_GROUP=IndexDimensionMap\\n\",

\" GROUP=GeoField\\n\",

\" OBJECT=GeoField_1\\n\",

\" GeoFieldName="Latitude"\\n\",

\" DataType=DFNT_FLOAT32\\n\",

\" DimList=("Coarse_Track","Coarse_Xtrack")\\n\",

\" END_OBJECT=GeoField_1\\n\",

\" OBJECT=GeoField_2\\n\",

\" GeoFieldName="Longitude"\\n\",

\" DataType=DFNT_FLOAT32\\n\",

\" DimList=("Coarse_Track","Coarse_Xtrack")\\n\",

\" END_OBJECT=GeoField_2\\n\",

\" END_GROUP=GeoField\\n\",

\" GROUP=DataField\\n\",

\" OBJECT=DataField_1\\n\",

\" DataFieldName="Band_5"\\n\",

\" DataType=DFNT_INT16\\n\",

\" DimList=("Track","Xtrack")\\n\",

\" END_OBJECT=DataField_1\\n\",

\" END_GROUP=DataField\\n\",

\" GROUP=MergedFields\\n\",

\" END_GROUP=MergedFields\\n\",

\" END_GROUP=SWATH_1\\n\",

\"END_GROUP=SwathStructure\\n\",

\"GROUP=GridStructure\\n\",

\"END_GROUP=GridStructure\\n\",

\"GROUP=PointStructure\\n\",

\"END_GROUP=PointStructure\\n\",

\"END\\n\",

\"\" ;

:HDFEOS_FractionalOffset_Track_MODIS_Swath_Type_1c = 0.5f ;

:HDFEOS_FractionalOffset_Xtrack_MODIS_Swath_Type_1c = 0.f ;

}

\*\*\*\* from hdp dumpvg \*\*\*\*

File name: MOD_SW_2b2a.HDF

Vgroup:0

tag = 1965; reference = 2;

name = MODIS_Swath_Type_1c; class = SWATH;

number of entries = 3;

number of attributes = 0

Entries:-

#0 (Vgroup)

tag = 1965;reference = 3;

number of entries = 2;

name = Geolocation Fields; class = SWATH Vgroup

number of attributes = 0

#1 (Vgroup)

tag = 1965;reference = 4;

number of entries = 1;

name = Data Fields; class = SWATH Vgroup

number of attributes = 0

#2 (Vgroup)

tag = 1965;reference = 5;

number of entries = 0;

name = Swath Attributes; class = SWATH Vgroup

number of attributes = 0

Vgroup:1

tag = 1965; reference = 3;

name = Geolocation Fields; class = SWATH Vgroup;

number of entries = 2;

number of attributes = 0

Entries:-

#0 (Numeric Data Group)

tag = 720; reference = 7;

#1 (Numeric Data Group)

tag = 720; reference = 8;

Vgroup:2

tag = 1965; reference = 4;

name = Data Fields; class = SWATH Vgroup;

number of entries = 1;

number of attributes = 0

Entries:-

#0 (Numeric Data Group)

tag = 720; reference = 6;

Vgroup:3

tag = 1965; reference = 5;

name = Swath Attributes; class = SWATH Vgroup;

number of entries = 0;

number of attributes = 0

Entries:-

None.

Vgroup:4

tag = 1965; reference = 14;

name = Track:MODIS_Swath_Type_1c; class = Dim0.0;

number of entries = 2;

number of attributes = 0

Entries:-

#0 (Vdata)

tag = 1962; reference = 12;

number of records = 1; interlace = 0;

fields = \[Values\];

record size (in bytes) = 4;

name = Track:MODIS_Swath_Type_1c; class = DimVal0.1;

total number of attributes = 0.

#1 (Vdata)

tag = 1962; reference = 13;

number of records = 400; interlace = 0;

fields = \[Values\];

record size (in bytes) = 4;

name = Track:MODIS_Swath_Type_1c; class = DimVal0.0;

total number of attributes = 0.

Vgroup:5

tag = 1965; reference = 17;

name = Xtrack:MODIS_Swath_Type_1c; class = Dim0.0;

number of entries = 2;

number of attributes = 0

Entries:-

#0 (Vdata)

tag = 1962; reference = 15;

number of records = 1; interlace = 0;

fields = \[Values\];

record size (in bytes) = 4;

name = Xtrack:MODIS_Swath_Type_1c; class = DimVal0.1;

total number of attributes = 0.

#1 (Vdata)

tag = 1962; reference = 16;

number of records = 5416; interlace = 0;

fields = \[Values\];

record size (in bytes) = 4;

name = Xtrack:MODIS_Swath_Type_1c; class = DimVal0.0;

total number of attributes = 0.

Vgroup:6

tag = 1965; reference = 20;

name = Coarse_Track:MODIS_Swath_Type_1c; class = Dim0.0;

number of entries = 2;

number of attributes = 0

Entries:-

#0 (Vdata)

tag = 1962; reference = 18;

number of records = 1; interlace = 0;

fields = \[Values\];

record size (in bytes) = 4;

name = Coarse_Track:MODIS_Swath_Type_1c; class = DimVal0.1;

total number of attributes = 0.

#1 (Vdata)

tag = 1962; reference = 19;

number of records = 100; interlace = 0;

fields = \[Values\];

record size (in bytes) = 4;

name = Coarse_Track:MODIS_Swath_Type_1c; class = DimVal0.0;

total number of attributes = 0.

Vgroup:7

tag = 1965; reference = 23;

name = Coarse_Xtrack:MODIS_Swath_Type_1c; class = Dim0.0;

number of entries = 2;

number of attributes = 0

Entries:-

#0 (Vdata)

tag = 1962; reference = 21;

number of records = 1; interlace = 0;

fields = \[Values\];

record size (in bytes) = 4;

name = Coarse_Xtrack:MODIS_Swath_Type_1c; class = DimVal0.1;

total number of attributes = 0.

#1 (Vdata)

tag = 1962; reference = 22;

number of records = 1354; interlace = 0;

fields = \[Values\];

record size (in bytes) = 4;

name = Coarse_Xtrack:MODIS_Swath_Type_1c; class = DimVal0.0;

total number of attributes = 0.

Vgroup:8

tag = 1965; reference = 25;

name = Band_5; class = Var0.0;

number of entries = 6;

number of attributes = 0

Entries:-

#0 (Vgroup)

tag = 1965;reference = 14;

number of entries = 2;

name = Track:MODIS_Swath_Type_1c; class = Dim0.0

number of attributes = 0

#1 (Vgroup)

tag = 1965;reference = 17;

number of entries = 2;

name = Xtrack:MODIS_Swath_Type_1c; class = Dim0.0

number of attributes = 0

#2 (Scientific Data)

tag = 702; reference = 9;

#3 (Number type)

tag = 106; reference = 24;

#4 (SciData dimension record)

tag = 701; reference = 24;

#5 (Numeric Data Group)

tag = 720; reference = 6;

Vgroup:9

tag = 1965; reference = 27;

name = Latitude; class = Var0.0;

number of entries = 6;

number of attributes = 0

Entries:-

#0 (Vgroup)

tag = 1965;reference = 20;

number of entries = 2;

name = Coarse_Track:MODIS_Swath_Type_1c; class = Dim0.0

number of attributes = 0

#1 (Vgroup)

tag = 1965;reference = 23;

number of entries = 2;

name = Coarse_Xtrack:MODIS_Swath_Type_1c; class = Dim0.0

number of attributes = 0

#2 (Scientific Data)

tag = 702; reference = 10;

#3 (Number type)

tag = 106; reference = 26;

#4 (SciData dimension record)

tag = 701; reference = 26;

#5 (Numeric Data Group)

tag = 720; reference = 7;

Vgroup:10

tag = 1965; reference = 29;

name = Longitude; class = Var0.0;

number of entries = 6;

number of attributes = 0

Entries:-

#0 (Vgroup)

tag = 1965;reference = 20;

number of entries = 2;

name = Coarse_Track:MODIS_Swath_Type_1c; class = Dim0.0

number of attributes = 0

#1 (Vgroup)

tag = 1965;reference = 23;

number of entries = 2;

name = Coarse_Xtrack:MODIS_Swath_Type_1c; class = Dim0.0

number of attributes = 0

#2 (Scientific Data)

tag = 702; reference = 11;

#3 (Number type)

tag = 106; reference = 28;

#4 (SciData dimension record)

tag = 701; reference = 28;

#5 (Numeric Data Group)

tag = 720; reference = 8;

Vgroup:11

tag = 1965; reference = 34;

name = MOD_SW_2b2a.HDF; class = CDF0.0;

number of entries = 11;

number of attributes = 0

Entries:-

#0 (Vgroup)

tag = 1965;reference = 14;

number of entries = 2;

name = Track:MODIS_Swath_Type_1c; class = Dim0.0

number of attributes = 0

#1 (Vgroup)

tag = 1965;reference = 17;

number of entries = 2;

name = Xtrack:MODIS_Swath_Type_1c; class = Dim0.0

number of attributes = 0

#2 (Vgroup)

tag = 1965;reference = 20;

number of entries = 2;

name = Coarse_Track:MODIS_Swath_Type_1c; class = Dim0.0

number of attributes = 0

#3 (Vgroup)

tag = 1965;reference = 23;

number of entries = 2;

name = Coarse_Xtrack:MODIS_Swath_Type_1c; class = Dim0.0

number of attributes = 0

#4 (Vgroup)

tag = 1965;reference = 25;

number of entries = 6;

name = Band_5; class = Var0.0

number of attributes = 0

#5 (Vgroup)

tag = 1965;reference = 27;

number of entries = 6;

name = Latitude; class = Var0.0

number of attributes = 0

#6 (Vgroup)

tag = 1965;reference = 29;

number of entries = 6;

name = Longitude; class = Var0.0

number of attributes = 0

#7 (Vdata)

tag = 1962; reference = 30;

number of records = 1; interlace = 0;

fields = \[VALUES\];

record size (in bytes) = 11;

name = HDFEOSVersion; class = Attr0.0;

total number of attributes = 0.

#8 (Vdata)

tag = 1962; reference = 31;

number of records = 1; interlace = 0;

fields = \[VALUES\];

record size (in bytes) = 32000;

name = StructMetadata.0; class = Attr0.0;

total number of attributes = 0.

#9 (Vdata)

tag = 1962; reference = 32;

number of records = 1; interlace = 0;

fields = \[VALUES\];

record size (in bytes) = 4;

name = HDFEOS_FractionalOffset_Track_MODIS_Swath_Type_1c; class =
Attr0.0;

total number of attributes = 0.

#10 (Vdata)

tag = 1962; reference = 33;

number of records = 1; interlace = 0;

fields = \[VALUES\];

record size (in bytes) = 4;

name = HDFEOS_FractionalOffset_Xtrack_MODIS_Swath_Type_1c; class =
Attr0.0;

total number of attributes = 0.

\*\*\*\* from hdp dumpvd \*\*\*\*

File name: MOD_SW_2b2a.HDF

Vdata: 0

tag = 1962; reference = 12;

number of records = 1; interlace = FULL_INTERLACE (0);

fields = \[Values\];

record size (in bytes) = 4;

name = Track:MODIS_Swath_Type_1c; class = DimVal0.1;

number of attributes = 0

\- field index 0: \[Values\], type=24, order=1

number of attributes = 0

Loc. Data

0 400 ;

Vdata: 1

tag = 1962; reference = 13;

number of records = 400; interlace = FULL_INTERLACE (0);

fields = \[Values\];

record size (in bytes) = 4;

name = Track:MODIS_Swath_Type_1c; class = DimVal0.0;

number of attributes = 0

\- field index 0: \[Values\], type=24, order=1

number of attributes = 0

Loc. Data

000 0 ; 1 ; 2 ; 3 ;

004 4 ; 5 ; 6 ; 7 ;

008 8 ; 9 ; 10 ; 11 ;

\...

392 392 ; 393 ; 394 ; 395 ;

396 396 ; 397 ; 398 ; 399 ;

Vdata: 2

tag = 1962; reference = 15;

number of records = 1; interlace = FULL_INTERLACE (0);

fields = \[Values\];

record size (in bytes) = 4;

name = Xtrack:MODIS_Swath_Type_1c; class = DimVal0.1;

number of attributes = 0

\- field index 0: \[Values\], type=24, order=1

number of attributes = 0

Loc. Data

0 5416 ;

Vdata: 3

tag = 1962; reference = 16;

number of records = 5416; interlace = FULL_INTERLACE (0);

fields = \[Values\];

record size (in bytes) = 4;

name = Xtrack:MODIS_Swath_Type_1c; class = DimVal0.0;

number of attributes = 0

\- field index 0: \[Values\], type=24, order=1

number of attributes = 0

Loc. Data

0000 0 ; 1 ; 2 ; 3 ;

0004 4 ; 5 ; 6 ; 7 ;

0008 8 ; 9 ; 10 ; 11 ;

\...

5408 5408 ; 5409 ; 5410 ; 5411 ;

5412 5412 ; 5413 ; 5414 ; 5415 ;

Vdata: 4

tag = 1962; reference = 18;

number of records = 1; interlace = FULL_INTERLACE (0);

fields = \[Values\];

record size (in bytes) = 4;

name = Coarse_Track:MODIS_Swath_Type_1c; class = DimVal0.1;

number of attributes = 0

\- field index 0: \[Values\], type=24, order=1

number of attributes = 0

Loc. Data

0 100 ;

Vdata: 5

tag = 1962; reference = 19;

number of records = 100; interlace = FULL_INTERLACE (0);

fields = \[Values\];

record size (in bytes) = 4;

name = Coarse_Track:MODIS_Swath_Type_1c; class = DimVal0.0;

number of attributes = 0

\- field index 0: \[Values\], type=24, order=1

number of attributes = 0

Loc. Data

00 0 ; 1 ; 2 ; 3 ;

04 4 ; 5 ; 6 ; 7 ;

08 8 ; 9 ; 10 ; 11 ;

\...

92 92 ; 93 ; 94 ; 95 ;

96 96 ; 97 ; 98 ; 99 ;

Vdata: 6

tag = 1962; reference = 21;

number of records = 1; interlace = FULL_INTERLACE (0);

fields = \[Values\];

record size (in bytes) = 4;

name = Coarse_Xtrack:MODIS_Swath_Type_1c; class = DimVal0.1;

number of attributes = 0

\- field index 0: \[Values\], type=24, order=1

number of attributes = 0

Loc. Data

0 1354 ;

Vdata: 7

tag = 1962; reference = 22;

number of records = 1354; interlace = FULL_INTERLACE (0);

fields = \[Values\];

record size (in bytes) = 4;

name = Coarse_Xtrack:MODIS_Swath_Type_1c; class = DimVal0.0;

number of attributes = 0

\- field index 0: \[Values\], type=24, order=1

number of attributes = 0

Loc. Data

000 0 ; 1 ; 2 ; 3 ;

004 4 ; 5 ; 6 ; 7 ;

008 8 ; 9 ; 10 ; 11 ;

\...

1348 1348 ; 1349 ; 1350 ; 1351 ;

1352 1352 ; 1353 ;

Vdata: 8

tag = 1962; reference = 30;

number of records = 1; interlace = FULL_INTERLACE (0);

fields = \[VALUES\];

record size (in bytes) = 11;

name = HDFEOSVersion; class = Attr0.0;

number of attributes = 0

\- field index 0: \[VALUES\], type=4, order=11

number of attributes = 0

Loc. Data

0 H D F E O S \_ V 2 . 4 ;

Vdata: 9

tag = 1962; reference = 31;

number of records = 1; interlace = FULL_INTERLACE (0);

fields = \[VALUES\];

record size (in bytes) = 32000;

name = StructMetadata.0; class = Attr0.0;

number of attributes = 0

\- field index 0: \[VALUES\], type=4, order=32000

number of attributes = 0

Loc. Data

0 G R O U P = S w a t h S t r u c t u r e \\012

\\011 G R O U P = S W A T H \_ 1 \\012

\...

\\000 \\000 \\000 \\000 \\000 \\000 \\000 ;

Vdata: 10

tag = 1962; reference = 32;

number of records = 1; interlace = FULL_INTERLACE (0);

fields = \[VALUES\];

record size (in bytes) = 4;

name = HDFEOS_FractionalOffset_Track_MODIS_Swath_Type_1c; class =
Attr0.0;

number of attributes = 0

\- field index 0: \[VALUES\], type=5, order=1

number of attributes = 0

Loc. Data

0 0.500000 ;

Vdata: 11

tag = 1962; reference = 33;

number of records = 1; interlace = FULL_INTERLACE (0);

fields = \[VALUES\];

record size (in bytes) = 4;

name = HDFEOS_FractionalOffset_Xtrack_MODIS_Swath_Type_1c; class =
Attr0.0;

number of attributes = 0

\- field index 0: \[VALUES\], type=5, order=1

number of attributes = 0

Loc. Data

0 0.000000 ;

C.3 Grid Example 1: Geographic Map Projection

C.3.1 Code

\*\*\* start grid_ge.c \*\*\*

#include\<stdio.h

#include\<stdlib.h

#include\<hdf.h

#include\<mfhdf.h

#include\<HdfEosDef.h

#define XDIM 360 /\* Columns (samples or pixels) \*/

#define YDIM 180 /\* Rows (lines) \*/

#define SPHERE_CODE NULL /\* Not used \*/

void error(const char \*message) {

fprintf(stderr, \" error \[grid_ge.c, main\] : %s\\n\", message);

exit(EXIT_FAILURE);

}

int main(void)

{

int32 gridId;

int32 fileId;

intn hdfReturn;

int16 landseaData\[YDIM\]\[XDIM\] = {1};

int8 qaData\[YDIM\]\[XDIM\] = {2};

float64 ulCornerGrid\[2\] = {-180000000.0, 90000000.0};

float64 lrCornerGrid\[2\] = { 180000000.0, -90000000.0};

float64 projParameters\[13\] = {0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0,

0.0, 0.0, 0.0, 0.0, 0.0, 0.0};

/\* Open the grid file. \*/

fileId = GDopen(\"Grid_ge.hdf\", DFACC_CREATE);

if (fileId == FAIL) error(\"opening file\");

/\* Create the first grid in the file. \*/

gridId = GDcreate(fileId, \"MOD_Grid_mask\", XDIM, YDIM,

ulCornerGrid, lrCornerGrid);

if (gridId == FAIL) error(\"creating grid\");

/\* Define the origin and projetion for this grid. This is the
Geographic

map projection. \*/

hdfReturn = GDdefproj(gridId, GCTP_GEO, (int32) NULL, SPHERE_CODE,

projParameters);

if (hdfReturn == FAIL) error(\"defining projection\");

hdfReturn = GDdeforigin(gridId, HDFE_GD_UL);

if (hdfReturn == FAIL) error(\"defining origin\");

/\* Define each field for the data to be inserted into the first grid
\*/

hdfReturn = GDdeffield(gridId, \"landsea\", \"YDim,XDim\", DFNT_INT16,

HDFE_NOMERGE);

if (hdfReturn == FAIL) error(\"defining field landsea\");

hdfReturn = GDdeffield(gridId, \"qa\", \"YDim,XDim\", DFNT_INT8,

HDFE_NOMERGE);

if (hdfReturn == FAIL) error(\"defining field qa\");

/\* Write the data for the first grid \*/

hdfReturn = GDwritefield(gridId, \"landsea\", (int32 \*) NULL, (int32
\*) NULL,

(int32 \*) NULL, (void \*) landseaData);

if (hdfReturn == FAIL) error(\"writing field landsea\");

hdfReturn = GDwritefield(gridId, \"qa\", (int32 \*) NULL, (int32 \*)
NULL,

(int32 \*) NULL, (void \*) qaData);

if (hdfReturn == FAIL) error(\"writing field qa\");

/\* Detach from the grid \*/

hdfReturn = GDdetach(gridId);

if (hdfReturn == FAIL) error(\"detaching grid\");

/\* Close the file \*/

hdfReturn = GDclose(fileId);

if (hdfReturn == FAIL) error(\"closing file\");

/\* All done \*/

printf(\" normal exit\\n\");

exit(EXIT_SUCCESS);

}

\*\*\* end grid_ge.c \*\*\*

C.3.2 Corresponding Sample File Specification Addendum

GridStructures

GridName=\"MODIS_Grid_mask\"

XDim = 360

YDim = 180

UpperLeftPointMtrs = (-180000000.000000,90000000.000000)

LowerRightPointMtrs = (180000000.000000,-90000000.000000)

Projecton=\"GCTP_GEO\"

ProjParams=(0,0,0,0,0,0,0,0,0,0,0,0,0)

Spherecode=19

GridOrigin=HDFE_GD_UL

DataFields

DataField_1, \"landsea\", DFNT_INT16, (\"YDim\", \"XDim\")

DataField_2, \"qa\", DFNT_INT8, (\"YDim\", \"XDim\")

C.3.3 Output File

\*\*\* start Grid_ge_mosaic.txt \*\*\*

There are 2 datasets and 1 global attribute in this file.

Dataset landsea has rank 2 with dimensions \[180, 360\]. The dataset is

composed

of signed 16-bit integers.

Dataset qa has rank 2 with dimensions \[180, 360\]. The dataset is
composed of

signed 8-bit integers.

Global attributes :

Attribute StructMetadata.0 has the value :

GROUP=SwathStructure

END_GROUP=SwathStructure

GROUP=GridStructure

GROUP=GRID_1

GridName=\"MOD_Grid_mask\"

XDim=360

YDim=180

UpperLeftPointMtrs=(-180000000.000000,90000000.000000)

LowerRightMtrs=(180000000.000000,-90000000.000000)

Projection=GCTP_GEO

GridOrigin=HDFE_GD_UL

GROUP=Dimension

END_GROUP=Dimension

GROUP=DataField

OBJECT=DataField_1

DataFieldName=\"landsea\"

DataType=DFNT_INT16

DimList=(\"YDim\",\"XDim\")

END_OBJECT=DataField_1

OBJECT=DataField_2

DataFieldName=\"qa\"

DataType=DFNT_INT8

DimList=(\"YDim\",\"XDim\")

END_OBJECT=DataField_2

END_GROUP=DataField

GROUP=MergedFields

END_GROUP=MergedFields

END_GROUP=GRID_1

END_GROUP=GridStructure

GROUP=PointStructure

END_GROUP=PointStructure

END

Vgroups

The following Vgroups are visible at this level of the file.

Vgroup MOD_Grid_mask of class GRID has 2 elements.

Vgroup Grid_ge.hdf of class CDF0.0 has 5 elements.

Vgroup MOD_Grid_mask :

Vgroup Data Fields of class GRID Vgroup has 2 elements.

Vgroup Grid Attributes of class GRID Vgroup is empty.

Vgroup Data Fields :

HDF object : Numeric Data Group (Ref = 5)

HDF object : Numeric Data Group (Ref = 6)

Vgroup Grid_ge.hdf :

Vgroup YDim:MOD_Grid_mask of class Dim0.0 has 2 elements.

Vgroup XDim:MOD_Grid_mask of class Dim0.0 has 2 elements.

Vgroup landsea of class Var0.0 has 6 elements.

Vgroup qa of class Var0.0 has 6 elements.

Vdata StructMetadata.0 of class Attr0.0. This Vdata contains the

field VALUES : {see above}

Vgroup YDim:MOD_Grid_mask :

Vdata YDim:MOD_Grid_mask of class DimVal0.1. This Vdata contains the

field Values : 180.

Vdata YDim:MOD_Grid_mask of class DimVal0.0 contains 180 records. This

Vdata contains the field Values .

Vroup XDim:MOD_Grid_mask :

Vdata XDim:MOD_Grid_mask of class DimVal0.1. This Vdata contains the

field Values : 360.

Vdata XDim:MOD_Grid_mask of class DimVal0.0 contains 360 records. This

Vdata contains the field Values .

Vgroup landsea :

Vgroup YDim:MOD_Grid_mask

Vgroup XDim:MOD_Grid_mask

HDF object : Scientific Data (Ref = 7)

HDF object : Number type (Ref = 15)

HDF object : SciData dimension record (Ref = 15)

HDF object : Numeric Data Group (Ref = 5)

Vgroup qa :

Vgroup YDim:MOD_Grid_mask

Vgroup XDim:MOD_Grid_mask

HDF object : Scientific Data (Ref = 8)

HDF object : Number type (Ref = 17)

HDF object : SciData dimension record (Ref = 17)

HDF object : Numeric Data Group (Ref = 6)

\*\*\* end Grid_ge_mosaic.txt \*\*\*

C.4 Grid Example 2: Sinusoidal Map Projection

Note, this example is based on the expected toolkit calls which are
currently being tested by ECS. Once they become available to MODIS any
changes to this example will be distributed.

C.4.1 Code

\*\*\* start grid_sn.c \*\*\*

#include\<stdio.h

#include\<stdlib.h

#include\<hdf.h

#include\<mfhdf.h

#include\<HdfEosDef.h

#define GLGRID_UL_X -20015109.354 /\* Global grid upper left corner \*/

#define GLGRID_UL_Y 10007554.677 /\* Global grid upper left corner \*/

#define GLGRID_SZ 926.62543305 /\* Pixel (grid cell) size \*/

#define TILE_XDIM 1200 /\* Number of columns in a tile \*/

#define TILE_YDIM 1200 /\* Number of rows in a tile \*/

#define ITILE_HORIZ 11 /\* Global grid horizontal tile number \*/

#define ITILE_VERT 5 /\* Global grid ertical tile number \*/

#define XDIM TILE_XDIM /\* Columns (samples or pixels) \*/

#define YDIM TILE_YDIM /\* Rows (lines) \*/

#define SPHERE_CODE -1 /\* User defined spheriod (in parameters 0 and 1)
\*/

void error(const char \*message) {

fprintf(stderr, \" error \[grid_sn.c, main\] : %s\\n\", message);

exit(EXIT_FAILURE);

}

int main(void)

{

int32 gridId;

int32 fileId;

intn hdfReturn;

int16 landseaData\[YDIM\]\[XDIM\] = {1};

int8 qaData\[YDIM\]\[XDIM\] = {2};

float64 ulCornerGrid\[2\];

float64 lrCornerGrid\[2\];

float64 projParameters\[13\] = {0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0,

0.0, 0.0, 0.0, 0.0, 0.0, 0.0};

/\* Open the grid file. \*/

fileId = GDopen(\"Grid_is.hdf\", DFACC_CREATE);

if (fileId == FAIL) error(\"opening file\");

/\* Calculate the tile corners \*/

ulCornerGrid\[0\] = GLGRID_UL_X + (ITILE_HORIZ \* TILE_XDIM \*
GLGRID_SZ);

ulCornerGrid\[1\] = GLGRID_UL_Y - (ITILE_VERT \* TILE_YDIM \*
GLGRID_SZ);

lrCornerGrid\[0\] = ulCornerGrid\[0\] + (TILE_XDIM \* GLGRID_SZ);

lrCornerGrid\[1\] = ulCornerGrid\[1\] - (TILE_YDIM \* GLGRID_SZ);

/\* Create the first grid in the file. \*/

gridId = GDcreate(fileId, \"MOD_Grid_mask\", XDIM, YDIM,

ulCornerGrid, lrCornerGrid);

if (gridId == FAIL) error(\"creating grid\");

/\* Define the origin and projection for this grid. This is the

Sinusoidal map projection. \*/

/\* Sphere radius (sphere with the best surface area fit of WGS84

ellipsoid) \*/

projParameters\[0\] = 6371007.181;

hdfReturn = GDdefproj(gridId, GCTP_SNSOID, (int32) NULL, SPHERE_CODE,

projParameters);

if (hdfReturn == FAIL) error(\"defining projection\");

hdfReturn = GDdeforigin(gridId, HDFE_GD_UL);

if (hdfReturn == FAIL) error(\"defining origin\");

/\* Define each field for the data to be inserted into the first grid
\*/

hdfReturn = GDdeffield(gridId, \"landsea\", \"YDim,XDim\", DFNT_INT16,

HDFE_NOMERGE);

if (hdfReturn == FAIL) error(\"defining field landsea\");

hdfReturn = GDdeffield(gridId, \"qa\", \"YDim,XDim\", DFNT_INT8,

HDFE_NOMERGE);

if (hdfReturn == FAIL) error(\"defining field qa\");

/\* Write the data for the first grid \*/

hdfReturn = GDwritefield(gridId, \"landsea\", (int32 \*) NULL, (int32
\*) NULL,

(int32 \*) NULL, (void \*) landseaData);

if (hdfReturn == FAIL) error(\"writing field landsea\");

hdfReturn = GDwritefield(gridId, \"qa\", (int32 \*) NULL, (int32 \*)
NULL,

(int32 \*) NULL, (void \*) qaData);

if (hdfReturn == FAIL) error(\"writing field qa\");

/\* Detach from the grid \*/

hdfReturn = GDdetach(gridId);

if (hdfReturn == FAIL) error(\"detaching grid\");

/\* Close the file \*/

hdfReturn = GDclose(fileId);

if (hdfReturn == FAIL) error(\"closing file\");

/\* All done \*/

printf(\" normal exit\\n\");

exit(EXIT_SUCCESS);

}

\*\*\* end grid_is.c \*\*\*

C.4.2 Corresponding Sample File Specificaton Addendum

GridStructures

GridName=\"MODIS_Grid_mask\"

XDim = 1200

YDim = 1200

UpperLeftPointMtrs = (-7783653.638, 4447802.079)

LowerRightMtrs = (-6671703.118, 3335851.559)

Projecton=\"GCTP\_ SNSOID\"

ProjParams=(6371007.181,0,0,0,0,0,0,0, 0,0,0,0,0)

Spherecode=-1

GridOrigin=HDFE_GD_UL

DataFields

DataField_1, \"landsea\", DFNT_INT16, (\"YDim\", \"XDim\")

DataField_2, \"qa\", DFNT_INT8, (\"YDim\", \"XDim\")

C.4.3 Output File

\*\*\* start Grid_is_ncdump.txt \*\*\*

There are 2 datasets and 1 global attribute in this file.

Dataset landsea has rank 2 with dimensions \[1200, 1200\]. The dataset
is

composed of signed 16-bit integers.

Dataset qa has rank 2 with dimensions \[1200, 1200\]. The dataset is
composed of

signed 8-bit integers.

Global attributes :

Attribute StructMetadata.0 has the value :

GROUP=SwathStructure

END_GROUP=SwathStructure

GROUP=GridStructure

GROUP=GRID_1

GridName=\"MOD_Grid_mask\"

XDim=1200

YDim=1200

UpperLeftPointMtrs=(-7783653.638, 4447802.079)

LowerRightMtrs=(-6671703.118, 3335851.559)

Projection=GCTP_SNSOID

ProjParams=(6371007.181,0,0,0,0,0,0,0, 0,0,0,0,0)

SphereCode=-1

GridOrigin=HDFE_GD_UL

GROUP=Dimension

END_GROUP=Dimension

GROUP=DataField

OBJECT=DataField_1

DataFieldName=\"landsea\"

DataType=DFNT_INT16

DimList=(\"YDim\",\"XDim\")

END_OBJECT=DataField_1

OBJECT=DataField_2

DataFieldName=\"qa\"

DataType=DFNT_INT8

DimList=(\"YDim\",\"XDim\")

END_OBJECT=DataField_2

END_GROUP=DataField

GROUP=MergedFields

END_GROUP=MergedFields

END_GROUP=GRID_1

END_GROUP=GridStructure

GROUP=PointStructure

END_GROUP=PointStructure

END

Vgroups

The following Vgroups are visible at this level of the file.

Vgroup MOD_Grid_mask of class GRID has 2 elements.

Vgroup Grid_gh.hdf of class CDF0.0 has 5 elements.

Vgroup MOD_Grid_mask :

Vgroup Data Fields of class GRID Vgroup has 2 elements.

Vgroup Grid Attributes of class GRID Vgroup is empty.

Vgroup Data Fields :

HDF object : Numeric Data Group (Ref = 5)

HDF object : Numeric Data Group (Ref = 6)

Vgroup Grid_ge.hdf :

Vgroup YDim:MOD_Grid_mask of class Dim0.0 has 2 elements.

Vgroup XDim:MOD_Grid_mask of class Dim0.0 has 2 elements.

Vgroup landsea of class Var0.0 has 6 elements.

Vgroup qa of class Var0.0 has 6 elements.

Vdata StructMetadata.0 of class Attr0.0. This Vdata contains the

field VALUES : {see above}

Vgroup YDim:MOD_Grid_mask :

Vdata YDim:MOD_Grid_mask of class DimVal0.1. This Vdata contains the

field Values : 1200.

Vdata YDim:MOD_Grid_mask of class DimVal0.0 contains 1200 records. This

Vdata contains the field Values .

Vroup XDim:MOD_Grid_mask :

Vdata XDim:MOD_Grid_mask of class DimVal0.1. This Vdata contains the

field Values : 1200.

Vdata XDim:MOD_Grid_mask of class DimVal0.0 contains 1200 records. This

Vdata contains the field Values .

Vgroup landsea :

Vgroup YDim:MOD_Grid_mask

Vgroup XDim:MOD_Grid_mask

HDF object : Scientific Data (Ref = 7)

HDF object : Number type (Ref = 15)

HDF object : SciData dimension record (Ref = 15)

HDF object : Numeric Data Group (Ref = 5)

Vgroup qa :

Vgroup YDim:MOD_Grid_mask

Vgroup XDim:MOD_Grid_mask

HDF object : Scientific Data (Ref = 8)

HDF object : Number type (Ref = 17)

HDF object : SciData dimension record (Ref = 17)

HDF object : Numeric Data Group (Ref = 6)

\*\*\* end Grid_is_ncdump.txt \*\*\*

APPENDIX D: PACKING LIST contents

A delivery package consists of new and changed files delivered to SDST
for integration into a new or existing science algorithm package . An
algorithm package typically consists of a MODIS process (e.g., the Land
L2 Surface Reflectance algorithm, MOD_PR11) with accompanying Look-up
tables, coefficient files and shared code libraries. Files unchanged
from the previous algorithm version are usually not delivered, but may
be, for example, to verify the consistency of files at the SCF with
those at the TLCF.

A MODIS packing list contains the following seven items arranged in the
order shown below. Items 1 and 2 specify process name and science team
contacts, respectively. Items 3 through 7 identify the composition of
the new algorithm package in terms of new, removed, changed and
unchanged files in a science algorithm package. In each of sections 3-7,
identify files in table format by name, file type and description as
illustrated in the example table. Groupings within tables are useful to
distinguish the logical components of a science algorithm package
(MOD_PRxx files, shared code, coefficient files, test data). File types
to be provided in the delivery package include documents, source code,
build and run scripts, look-up tables and coefficient files, test data,
Process Control File (PCF), production rules and others listed
completely in Section 4.2. Verify that no object or executable files are
included in the delivery package.

For example:

  ------------------------- ------------ ---------------------------------
  **File Name**             **Format**   **Description**

  ML1-soo.c                 ASCII        Main program for algorithm

  ML1-abc.c                 ASCII        Subroutine to ML1-soo

  ABC-test.in1              HDF          Test input data set

  ABC-test.out1             HDF          Test output data set
  ------------------------- ------------ ---------------------------------

1\. PACKING LIST for (process_ID).

2\. The STM name, mailing address, and e-mail address to contact in case
of problems \[free format\].

3\. New files in MOD_PRxx science algorithm package. (A file with a
unique name relative to the previous science algorithm package.)

4\. Files removed from MOD_PRxx science algorithm package.

5\. Changed files in MOD_PRxx science algorithm package. (Test data, for
example, with the same name but different content).

6\. Unchanged and undelivered files in MOD_PRxx science algorithm
package.

7\. Unchanged but delivered files in MOD_PRxx science algorithm package.
(This category is typically not used, but may be to verify the
consistencies of files at the SCF with those at the TLCF.

**APPENDIX E: README FILE CONTENTS**

The following is a listing of all items identified in the README files.
Please provide a single README with all of these items in the order
specified. The CAPITALIZED words should be used to help delineate the
information.

1.  README for (process_ID).

2.  The STM name, mailing address, and e-mail address to contact in case
    of problems. \[Free format\]

3.  BUILD: Instruction on how to Build/Run the code.

4.  ENVIRONMENT VARIABLE: Names of all environment variables used by the
    Makefile.

5.  MAPI: Which version of M-API was used . If M-API was not used, enter
    "No M-API used."

6.  HDF: Which version of HDF was used.

7.  SDP TOOLKIT: Which version of SDP Toolkit was used.

8.  Identify what vendor's hardware (including model), operating system
    (e.g., Silicon Graphics Indigo/IRIX6.1), and compiler version
    ("version-b" should be used on SGI) were used to develop the code.
    \[Free format\]

9.  ANCILLARY DATA: Identify ancillary data sets used in processing.
    (Here, "ancillary data" refers to data produced outside of the
    production system such as NCEP or NOAA.)

10. MODIS INPUT PRODUCTS: Identify what MODIS products are inputs,
    including bands used.

11. OTHER: Identify other types of input (such as Look Up Tables).

12. MODIS OUTPUT PRODUCTS: Identify what MODIS products are output from
    the process.

13. PROBLEMS: Identify known software problems/defects (e.g., memory
    leaks).

14. DELIVERY SIZE: Total size of untarred delivery in Mbytes).

15. OUTPUT FILE SIZE: Size of expected output files.

16. TESTS PERFORMED: Description of tests performed at the SCF,
    including I/O data sets and test results. If the file specification
    does not provide sufficient details in the definition of the values
    of quality flags in the product, then provide a description of the
    conditions necessary to force the process to generate the various
    values of the flags. \[Free format\]

17. EXIT CODES: Definitions for all possible exit codes.

18. ERROR LIST: A table of all error messages that can be written to the
    LogStatus or LogReport files, the meaning of each, what action to
    perform and which code module generated the error message.

Appendix F: Makefile Standards AND Examples

F.1 Makefile Standards

Makefiles shall not use compiler options such as -woff to turn off
warning messages.

1\. All makefiles shall use the following environmental variables which
will be defined externally to the makefile, and shall not be redefined
within the makefile. Additional externally defined environment variables
shall be identified in the makefile prologue.

> [Variable]{.underline} [Meaning]{.underline}
>
> API_INC API Include
>
> API_LIB API Library
>
> CC Compiler definition for C code
>
> CFLAGS MODIS common C compiler flags
>
> F77 Compiler definition for FORTRAN 77
>
> F77FLAGS MODIS common F77 compiler flags.
>
> HDFEOS_INC HDFEOS Include
>
> HDFEOS_LIB HDFEOS Library
>
> HDFINC HDF Include
>
> HDFLIB HDF Library
>
> HDFSYS HDF System type
>
> LD_LIBRARY_PATH System Linked Library
>
> MODIS_STORE Top directory for source code
>
> PGSINC PGS Include
>
> PGSLIB PGS Library
>
> NOTE: The DAAC does NOT have F90 Flags. You need to explicitly define
> F90 in the makefiles.

2\. The following prefixes shall be used for internally defined
variables:

> [Prefix]{.underline} [Meaning]{.underline}
>
> INC Include directories
>
> LIB Library directories
>
> OBJ Object files
>
> TARGET Target executable

3\. If additional compiler options, flags, or specific include files are
needed, the following naming convention shall be used. Platform specific
options (e.g., improve performance) and flags may be included and will
be clearly documented as to which platform they apply.

> [Name]{.underline} [Meaning]{.underline}
>
> ADD_CFLAGS PGE- or process-specific C compiler flags

ADD_F77FLAGS PGE- or process-specific FORTRAN 77 compiler flags

F90 Compiler definition for Fortran 90

F90FLAGS MODIS common F90 compiler flags

ADD_F90FLAGS PGE- or process-specific F90 compiler flags

INC_FILES Specific include files

4\. Relative path names shall not be used in makefiles.

> DON'T: INC = ../include
>
> DO : INC = \$MODIS_STORE/pge11G/include
>
> OR INC = \$(PGSINC)

5\. Platform specific definitions are not encouraged. If they are used,
they shall be clearly documented as being platform specific and provide
information as to which platform(s) they apply.

6\. Makefiles shall not include "run" commands or shell definitions.

> DON'T: #/bin/csh

7\. Settings in externally defined environmental variables (e.g.,
compiler options which are defined in MODIS_setup) shall not be
overridden within makefiles.

8\. All modifications that must be made to the makefile for the current
environment (such as modifying a path name) shall be described in the
README. A comment describing the required modification shall be placed
in the makefile above the line that must be changed. EXAMPLE:

> \# The following line must be changed for the target environment
>
> INC = \$MODIS_STORE/pge11G/include

9\. All makefiles shall have the standard ESDIS prolog format at the top
of the makefile.

F.2 Example of C MAKEFILE

\###########################################################################

\# !make

\#

\# !Makefile Name: MOD_PR10.mk

\#

\# !Description: Makefile for MOD_PR10 L2 snow code.

\# This makefile used to generate MOD_PR10.exe

\#

\# !Variables:

\#

\# VARIABLES DESCRIPTION

\# \~\~\~\~\~\~\~\~\~ \~\~\~\~\~\~\~\~\~\~\~

\# TARGET Program executable name

\# ADD_CFLAGS Additional compiler options

\# LIB Libraries

\# MATH Math Libraries

\# SRCS Source files

\# OBJ Object files

\# OBJ1 Additional Object files

\# INC Include files

\# INC_FILES Additional include files

\# SYSTEM System

\#

\# !Env Variables

\#

\# ENV VARIABLES DESCRIPTION

\# \~\~\~\~\~\~\~\~\~\~\~\~\~ \~\~\~\~\~\~\~\~\~\~\~

\# CFLAGS Compiler flags which are set by the script

\# (e.g. n32_f77)

\# CC The compiler set by the script

\# API_INC Include directory of MODIS Appl Prog Interface set

\# by the script

\# PGSINC Include directory of PGS toolkit set by the script

\# HDFINC Include directory of HDF set by the script

\# HDFEOS_INC Include directory of HDFEOS set by the script

\# API_LIB Library of MODIS API set the the script

\# PGSLIB Library of PGS toolkit set by the script

\# HDFLIB Library of HDF set by the script

\# HDFEOS_LIB Library of HDFEOS set by the script

\#

\# !Team-Unique Header:

\# This software was developed by MODIS Science Data Support Team

\# for the National Aeronautics and Space Administration,

\# Goddard Space Flight Center, under contract NAS5-32373.

\#

\# !Revision History:

\# \$Log: MOD_PR10.mk,v \$

\#

\# Revision 1.4 1997/10/14 Gang Ye

\# Change to comply with GDAAC/SDST makefile standards

\#

\# Revision 1.3 1997/07/20 11:55:53 powell

\# Change \"make clean\".

\#

\# Revision 1.2 1997/07/20 11:32:13 powell

\# Misc. changes for latest input files.

\#

\# Revision 1.1 1997/05/30 14:55:38 powell

\# Initial revision

\#

\# !Note:

\# 1) must follow MAPI, SDP TK, HDF, and other header/libs order

\# 2) HDFLIB must be explicit and in order of -lmfhdf, -ldf,-ljpeg, -lz.

\# 3) system environments, such as APIINC, PGSINC, HDFINC, PGSLIB,

\# API_LIB etc. should be defined befor execute this makefile.

\#

\# !END

\##############################################################################

\# Define executable name

TARGET = MOD_PR10.exe

\# Combine the includes using pre-defined includes and your includes

INC = -I\$(PGSINC) -I\$(HDFINC) -I\$(HDFEOS_INC)

\# Combine the libraries using pre-defined libraries and your library

LIB = -L\$(PGSLIB) -lPGSTK -L\$(HDFLIB) -lmfhdf -ldf -lz \\

-L\$(HDFEOS_LIB) -lhdfeos -lm

\# Define system

SYSTEM = DIRIS4

\# Define additional C flags

\# Flags for optimization run

ADD_CFLAGS = -O3 -\$(SYSTEM)

\# Flags for standards checking when PRQA is not available.

\# However, these flags can only be used in -32 mode.

#ADD_CFLAGS = -O -\$(SYSTEM) -wlint -fullwarn -prototypes

\# Flags for memory leaks checking

#ADD_CFLAGS = -g -lmalloc_cv -\$(SYSTEM)

\# Define object files

OBJ = MOD_PR10_AAmain.o \\

MOD_PR10_Compute_Snow.o \\

MOD_PR10_CopyL1BmetaToSnow.o \\

MOD_PR10_CopyGEOmetaToSnow.o \\

MOD_PR10_MakeMeta.o \\

MOD_PR10_Process_Cloud.o

OBJ1= MOD_PR10_Process_GEO.o \\

MOD_PR10_Process_L1B.o \\

MOD_PR10_Process_SnowFile.o

\# Additional include files

INC_FILES = MOD_PR10.h \$(PGSINC)/PGS_PC.h

\# Make the process

\$(TARGET) : \$(OBJ) \$(OBJ1)

\$(CC) \$(CFLAGS) \$(ADD_CFLAGS) \$(OBJ) \$(OBJ1)\$(LIB) -o \$(TARGET)

.c.o : \$(INC_FILES)

\$(CC) \$(CFLAGS) \$(ADD_CFLAGS) \$(INC) -c \$\< -o \$@

\# Delete object files

clean:

/bin/rm \$(OBJ)

/bin/rm \$(OBJ1)

\# Delete the executable file \$TARGET

clean_exe:

/bin/rm \$(TARGET)

#\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* End of make file
\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*

F.3 Example of FORTRAN MAKEFILE

#\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*

\# !make

\#

\# !Makfile Name: MOD_PR04LA.mk

\#

\# !Description: Makefile for L3 gridded orbital land aerosol product

\# (MOD_PR04LA)

\#

\# !Variables:

\#

\# Internal

\# Macros Definition

\# \~\~\~\~\~\~\~\~ \~\~\~\~\~\~\~\~\~\~

\# ADD_CFLAGS Process specific C compiler options

\# ADD_F77FLAGS Process specific FORTRAN 77 compiler options

\# F90 FORTRAN 90 compiler definition

\# F90FLAGS FORTRAN 90 compiler options

\# INC\* Accumlated include file search path

\# OBJ\* Accumulated set of object files

\# LIB\* Accumulated library search path

\# TARGET\* Executable file name

\# INC_FILES\* Accumulated include files

\#

\# System

\# Environment

\# Variables Definition

\# \~\~\~\~\~\~\~\~\~\~\~ \~\~\~\~\~\~\~\~\~\~

\# API_INC Directory path to M-API include files

\# API_LIB Directory path to M-API library

\# CC C compiler definition

\# CFLAGS C compiler options

\# F77 FORTRAN 77 compiler definition

\# F77FLAGS FORTRAN 77 compiler options

\# HDFEOS_INC Directory path to HDFEOS include files

\# HDFEOS_LIB Directory path to HDFEOS library

\# HDFINC Directory path to HDF include files

\# HDFLIB Directory path to HDF library

\# HDFSYS Name of operating system as used by HDF

\# PGSINC Directory path to SDPTK include files

\# PGSLIB Directory path to SDPTK library

\# SEEDINC Directory path to include files generated from

\# SDPTK \"seed\" files

\#

\# User

\# Environment

\# Variables Definition

\# \~\~\~\~\~\~\~\~\~\~\~ \~\~\~\~\~\~\~\~\~\~

\#

\# !Revision History:

\# \$Log\$

\#

\# !Team-Unique Header:

\# This software was developed by MODIS Science Data Support Team

\# for the National Aeronautics and Space Administration,

\# Goddard Space Flight Center, under contract NAS5-32373.

\#

\# !Note:

\# 1) Libraries must be listed in the following order: MAPI, SDPTK,

\# HDF-EOS, HDF and other header/libs

\# 2) HDFLIB must be explicit and listed in the order:

\# -lmfhdf, -ldf, jpeg, -lz.

\# 3) system environment variables such as API_INC, PGSINC, HDFINC,

\# PGSLIB, API_LIB etc. should be defined prior to execution of this

\# makefile.

\#

\# !End

#\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*

\*\*

\# Define internal macros

#\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

OBJ1 = MOD_PR04LA.o msg.0

OBJ2 = Read_version.o Interim.o msg.o

OBJ3 = Inter.o msg.o

TARGET1 = MOD_PR04LA.exe1

TARGET3 = MOD_PR04LA.exe3

TARGET3 = MOD_PR04LA.exe3

INC_FILES1 = \$(SEEDINC)/PGS_MODIS_39500.f \$(API_INC)/mapi_inc

INC_FILES2 = \$(SEEDINC)/PGS_MODIS_39500.f

ADD_CFLAGS = -O3 -c

ADD_F77FLAGS = -O3 -bytereclen -c

\# Include file search path

#\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

INC = -I\$(PGSINC) \\

-I\$(HDFEOS_INC) \\

-I\$(API_INC) \\

-I\$(HDFINC)

\# Library search path

#\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

LIBS = -L\$(API_LIB) -lmapi \\

-L\$(HDFEOS_LIB) -lhdfeos \\

-L\$(PGSLIB) -lPGSTK \\

-L\$(HDFLIB) -lmfhdf -ldf -ljpeg -lz

\# Make executables

#\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

\$(TARGET1) : \$(OBJ1)

\$(F77) \$(F77FLAGS) \$(ADD_F77FLAGS) \$(OBJ1) \$(LIB) -o \$(TARGET1)

\$(TARGET2) : \$(OBJ2)

\$(F77) \$(F77FLAGS) \$(ADD_F77FLAGS) \$(OBJ2) \$(LIB) -o \$(TARGET2)

\$(TARGET3) : \$(OBJ3)

\$(F77) \$(F77FLAGS) \$(ADD_F77FLAGS) \$(OBJ3) \$(LIB) -o \$(TARGET3)

#Make objects

\-\-\-\-\-\-\-\-\-\-\-\--

MOD_PR04LA.o: MOD_PR04LA.f \$(INC_FILES1)

\$(F77) \$(F77FLAGS) \$(ADD_F77FLAGS) MOD_PR04LA.f \$(INC)

msg.o: msg.f \$(INC_FILES2)

\$(F77) \$(F77FLAGS) \$(ADD_F77FLAGS) msg.f \$(INC)

Inter.o: Inter.f \$(INC_FILES2)

\$(F77) \$(F77FLAGS) \$(ADD_F77FLAGS) Inter.f \$(INC)

Read_version.o: Read_version.c

\$(CC) \$(CFLAGS) \$(ADD_CFLAGS) Read_version.c \$(INC)

#\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* End of make file
\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*

APPENDIX G: Processing FILE FORMAT DESCRIPTION

Below is a sample template listing the items to be included in the
Processing File Format Description document. There must be one completed
template for each unique processing file format occurring in a code
delivery. However, a completed processing file format description
template is not required for HDF and HDF-EOS files, only a reference to
the HDF or HDF-EOS file specification (filespec) for the file is
required. All HDF and HDF-EOS processing files must have a filespec,
even files which are not MODIS product files.

All processing files (including LUTs, I/O files, and ancillary data
files) in the delivery must be covered by a template except the HDF and
HDF-EOS files. However, more than one file may be covered by the same
completed template. Information in a completed template must include the
detailed layout of records, lines and parameters/variables. Below is an
example of a detailed file format description.

Delivered files containing completed processing file format description
templates must be named according to the convention
"\<filename\>.pff.doc" and be located in a sub-directory named "doc."
This sub-directory must branch off of the root sub-directory associated
with the code delivery to SDST. The process ID must correspond to one of
those in the SDSP Requirements Specification for V2 and Beyond. A
delivered "pff.doc" file containing more than one completed template
must have each template separated by a page break.

Each "pff.doc" file must contain completed templates from only one
process ID. If a processing file (which is not an HDF or HDF-EOS file)
is used in more than one process, a reference to the delivered "pff.doc"
file where the processing file is described in detail (i.e., the file
which contains the completed template ) may be used.

G.1 Processing File Format Description Template

Processing File Format Description

File Name(s) (wildcard if appropriate):

MODIS Product:

File Type (ASCII, Binary):

File Source (Specify provider if applicable):

File Content Description:

File Structure Description^1^:

Record/Line Format^2^:

Notes:

1.  Includes, but is not limited to information like processing file
    size (approximate), block and line structure, and file type (e.g.,
    Direct Access, Sequential, etc.) for a FORTRAN file.

2.  Specific processing file structure to the bit level. Must include
    enough information to allow the user to be able to read each record,
    line, and parameter/variable in the processing file. Information
    about the file must include items such as: language used to write
    the file; the type, size, name, description, and order of each
    variable/ parameter in each record/line of the file. If code is used
    to illustrate how to read a specific part of the processing file,
    specific source language must be used (FORTRAN and C have different
    underlying implementations for reading the same data).

G.2 Processing File Format Description Example

> **File Format Description**
>
> **File Name(s) (wildcard if appropriate):**
>
> coef_quad_19\_\*.dat
>
> where \* = solar zenith angle in degrees
>
> **MODIS Product:** MOD18
>
> **File Type (ASCII,Binary):** ASCII
>
> **File Source (Specify provider if applicable):**
>
> Dr.Howard Gordon,
>
> University of Miami
>
> Physics Department
>
> Coral Gables, FL
>
> 33124
>
> **File Content Description:**
>
> Coefficients for linear transform of aerosol contribution fitted as a
> quadratic function. These coefficients are read by the subroutine
> linear_a_b_c which linearly transforms the azimuthal coefficients.
>
> **File Structure Description:**
>
> Each file contains the coefficients for a single solar zenith angle.
>
> Block progression:
>
> The blocks progress first through azimuthal angle, then model, and
> finally wavelength. The blocks are structured so that the first block
> represents data for azimuthal angle 1, phase function model 1, and
> wavelength 1. The last block is for last azimuth angle, 12th phase
> function model, and 8th wavelength.
>
> **Record/Line Format:**
>
> For each block:
>
> Line 1: Header for a given block, contains values for the parameters;
> Jsun, Jph, Jmodels, J1, Jmphi.
>
> Line 2-8: contain the first order coefficients , coef_acost for the
> satellite zenith angles specified in the data statement of the
> subroutine.
>
> Line 9-15: contains the 2nd order coefficients, coef_bcost for the
> satellite zenith angles specified in the data statement of the
> subroutine.
>
> Line 16-22: contains the 3rd order coefficients, coef_ccost for the
> satellite zenith angles specified in the data statement of the
> subroutine.

**Parameter Description Start byte Length**

Jsun(integer) sun angle index 2 6

Jph(integer) phase function index 9 6

Jmodels(integer) total number of phase function models 166 6

J1(integer) Azimuthal angle 23 6

Jmphi(integer) total number of azimuthal angles 30 6

Jwavelength(integer) wavelength 37 6

coef_acost(real,8) 1st order coefficient 46 14

coef_bcost(real,8) 2nd order coefficient 578 14

coef_ccost(real,8) 3rd order coefficient 1034 14

APPENDIX H: Process Control File Standards and Example

H.1 Process Control File Standards

The following are MODIS PCF Standards:

1.  All PCFs shall be generated using the SDPTK template corresponding
    to the software compiler mode (n32, etc.). No portion of the PCF may
    be deleted.

2.  All MODIS process-specific input and output file entries (including
    MODIS products, ancillary data, and static input files) shall be
    placed in the PRODUCT INPUT and PRODUCT OUTPUT sections of the PCF.
    All such entries shall be accompanied by a comment which identifies
    the file type.

3.  PCFs delivered to CMO shall contain no temporary or intermediate
    file entries; entries which are generated during testing will be
    deleted prior to delivery.

4.  All PRODUCT INPUT entries shall include full path names. PRODUCT
    OUTPUT entries may use a combination of individual path names and a
    default path.

5.  The default paths for the PRODUCT INPUT, INTERMEDIATE INPUT, and
    SUPPORT INPUT sections of the PCF shall not be modified from the
    template.

6.  The default paths for the SUPPORT OUTPUT and TEMPORARY I/O sections
    of the PCF shall be set to local paths. If INTERMEDIATE OUTPUT files
    are produced by the code, the default path for this section shall
    also be set to a local path. No modifications shall be made to the
    individual entries for SUPPORT OUTPUT.

7.  All MODIS process-specific input and output file entries in the PCFs
    shall correspond to files which are actually used by the delivered
    version of the code. Any unused entries (e.g., included for future
    versions) shall be commented out and identified as such with a
    comment.

8.  All PCFs shall be verified by the pccheck.sh program in the SDPTK,
    using the SDPTK template file for comparison. The syntax for
    performing this check is as follows:

\$PGSBIN/pccheck.sh -i input.pcf -c template.pcf

H.2 Process Control File Examples

The following example PCF is the current version of PGE03.pcf.

\#

\# filename:

\# pge03_f1.1_pcf

\#

\# description:

\# Process Control File for the cloud mask product (MOD_PR35).

\#

\# notes:

\#

\# This file supports the Release B version of the toolkit.

\# It is intended for use with toolkit version \"SCF B.0 TK5.2.1\".

\#

\# The logical IDs 10000-10999 (inclusive) are reserved for internal

\# Toolkit/ECS usage, DO NOT add logical IDs with these values.

\#

\# Please treat this file as a master template and make copies of it

\# for your own testing. Note that the Toolkit installation script

\# sets PGS_PC_INFO_FILE to point to this master file by default.

\# Remember to reset the environment variable PGS_PC_INFO_FILE to

\# point to the instance of your PCF.

\#

\# The toolkit will not interpret environment variables specified

\# in this file (e.g. \~/database/\$OSTYPE/TD is not a valid reference).

\# The \'\~\' character, however, when appearing in a reference WILL be

\# replaced with the value of the environment variable PGSHOME.

\#

\# The PCF file delivered with the toolkit should be taken as a

\# template. User entries should be added as necessary to this

\# template. Existing entries may (in some cases should) be altered

\# but generally should not be commented out or deleted. A few

\# entries may not be needed by all users and can in some cases

\# be commented out or deleted. Such entries should be clearly

\# identified in the comment(s) preceding the entry/entries.

\#

\# Entries preceded by the comment: (DO NOT REMOVE THIS ENTRY)

\# are deemed especially critical and should not be removed for

\# any reason (although the values of the various fields of such an

\# entry may be configurable).

\#

\#
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

? SYSTEM RUNTIME PARAMETERS

\#
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--
\#########################################################################

\# This section contains unique identifiers used to track instances of

\# a PGE run, versions of science software, etc. This section must

\# contain exactly two entries. These values will be inserted by

\# ECS just before a PGE is executed. At the SCF the values may be set

\# to anything but these values are not normally user definable and user

\# values will be ignored/overwritten at the DAAC.

\#########################################################################

\#

\# Production Run ID - unique production instance identifier

\# (DO NOT REMOVE THIS ENTRY)

\#
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--
1

\#
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

\# Software ID - unique software configuration identifier

\# (DO NOT REMOVE THIS ENTRY)

\#
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--
1

\#

? PRODUCT INPUT FILES

\#########################################################################

\# This section is intended for standard product inputs, i.e., major

\# input files such as Level 0 data files.

\#

\# Each logical ID may have several file instances, as given by the

\# version number in the last field.

\#########################################################################

\#

\# Next non-comment line is the default location for PRODUCT INPUT FILES

\# WARNING! DO NOT MODIFY THIS LINE unless you have relocated these

\# data set files to the location specified by the new setting. !
\~/runtime

\#

\# geolocation

600000\|MOD03.A1997217.1725.002.hdf\|/modsimdata/V2/2_orbit/gran_16_to_20\|\|/modsimdata/V2/2_orbit/gran_16_to_20/MOD03.A1997217.1725.002.hdf\|MOD03.A1997217.1725.002.hdf\|1

\# Logical Reference Number (LRN) 700000 is associated with MODIS L1B
product. \#

\# the 250 m

700000\|MOD02QKM.A1997217.1725.002.hdf\|/modsimdata/V2/2_orbit/gran_16_to_20\|\|/modsimdata/V2/2_orbit/gran_16_to_20/MOD02QKM.A1997217.1725.002.hdf\|MOD02QKM.A1997217.1725.002.hdf\|1

\#

\# the 1km

700002\|MOD021KM.A1997217.1725.002.hdf\|/modsimdata/V2/2_orbit/gran_16_to_20\|\|/modsimdata/V2/2_orbit/gran_16_to_20/MOD021KM.A1997217.1725.002.hdf\|MOD021KM.A1997217.1725.002.hdf\|1

\#

\#

\# Cloud Mask - mod35 \-- This file is the output for MOD_PR35 and input
for MOD_PR07
422500\|MOD35_L2.Af1.1-new\|/sdst/temptest/PGE03/Function1/1/run_time\|\|/sdst/temptest/PGE03/Function1/1/run_time/MOD35_L2.Af1.1-new\|MOD35_L2.Af1.1-new\|1

\#

\# LRN 420011 is temperature regression coefficients file
420011\|modisges.trc\|/sdst/tempcm/MOD_PR07/input\|\|\|\|1

\#

\# LRN 420012 is water vapor regression coefficients file
420012\|modisges.wrc\|/sdst/tempcm/MOD_PR07/input\|\|\|\|1

\#

\# EDC Land/Sea Mask

900602\|lst1km.v3\|/test/TestData/V2/TestInput/MOD_PR35/input\|\|lst1km.v3\|\|1

\#

\# Olson World Ecosystem Map (Global 10 minute)
900600\|ecosystem.img\|/test/TestData/V2/TestInput/MOD_PR35/input\|\|ecosystem.img\|\|1

\#

\# Olson World Ecosystem Map (North American 1 km)
900601\|naoge1_01g.img\|/test/TestData/V2/TestInput/MOD_PR35/input\|\|naoge1_01g.img\|\|1

\#

\# Grib input files

\# Ancillary Files from External Providers

\# NCEP 1 degree GDAS Final Run

900000\|gdas1.PGrbF00.970805.18z\|/test/TestData/V2/TestInput/ancdata/dynamic/1_Degree_NCEP_GDAS\|\|gdas1.PGrbF00.970805.18z\|\|1

\# NCEP TOVS total column ozone (1 x time daily)
900020\|970805.grb\|/test/TestData/V2/TestInput/ancdata/dynamic/TOVS_Column_Ozone_Daily\|\|970805.grb\|\|1

\# LRN 1000030 is the NCEP SST ancillary data file
900030\|oi.mean.bias.970806\|/test/TestData/V2/TestInput/ancdata/dynamic/Reynolds_Weekly_SST\|\|oi.mean.bias.970806\|\|1

\# NCEP 0.5 degree ice concentration

900040\|eng.970805\|/test/TestData/V2/TestInput/ancdata/dynamic/NCEP_ICE_CONC\|\|eng.971002\|\|1

\#

\#

\# MCFs

422506\|MOD_PR35.mcf\|/cc/cc_vob/ATMOS/PGE03/MOD_PR35\|\|\|\|1
422507\|MOD_PR35_QC.mcf\|/cc/cc_vob/ATMOS/PGE03/MOD_PR35\|\|\|\|1
402503\|MODVOLC.mcf\|/cc/cc_vob/ATMOS/PGE03/MOD_PRVOLC\|\|\|\|1
420001\|MOD_PR07.mcf\|/cc/cc_vob/ATMOS/PGE03/MOD_PR07\|\|\|\|1
420003\|MOD_PR07_QC.mcf\|/cc/cc_vob/ATMOS/PGE03/MOD_PR07\|\|\|\|1

\#

\#
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

\# These are actual ancillary data set files - supplied by ECS or the

\# user. The following are supplied for purposes of tests and as a
useful

\# set of ancillary data. These entries may be removed IF the AA tools

\# are not being used.

\#
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--
10780\|usatile12\|AA_DATA_INSTALL_DIR\|\|\|10751\|12
10780\|usatile11\|AA_DATA_INSTALL_DIR\|\|\|10750\|11
10780\|usatile10\|AA_DATA_INSTALL_DIR\|\|\|10749\|10
10780\|usatile9\|AA_DATA_INSTALL_DIR\|\|\|10748\|9
10780\|usatile8\|AA_DATA_INSTALL_DIR\|\|\|10747\|8
10780\|usatile7\|AA_DATA_INSTALL_DIR\|\|\|10746\|7
10780\|usatile6\|AA_DATA_INSTALL_DIR\|\|\|10745\|6
10780\|usatile5\|AA_DATA_INSTALL_DIR\|\|\|10744\|5
10780\|usatile4\|AA_DATA_INSTALL_DIR\|\|\|10743\|4
10780\|usatile3\|AA_DATA_INSTALL_DIR\|\|\|10742\|3
10780\|usatile2\|AA_DATA_INSTALL_DIR\|\|\|10741\|2
10780\|usatile1\|AA_DATA_INSTALL_DIR\|\|\|10740\|1
10951\|mowe13a.img\|AA_DATA_INSTALL_DIR\|\|\|\|1
10952\|owe13a.img\|AA_DATA_INSTALL_DIR\|\|\|\|1
10953\|owe14d.img\|AA_DATA_INSTALL_DIR\|\|\|\|1
10954\|owe14dr.img\|AA_DATA_INSTALL_DIR\|\|\|\|1
10955\|etop05.dat\|AA_DATA_INSTALL_DIR\|\|\|\|1
10956\|fnocazm.img\|AA_DATA_INSTALL_DIR\|\|\|\|1
10957\|fnococm.img\|AA_DATA_INSTALL_DIR\|\|\|\|1
10958\|fnocpt.img\|AA_DATA_INSTALL_DIR\|\|\|\|1
10959\|fnocrdg.img\|AA_DATA_INSTALL_DIR\|\|\|\|1
10960\|fnocst.img\|AA_DATA_INSTALL_DIR\|\|\|\|1
10961\|fnocurb.img\|AA_DATA_INSTALL_DIR\|\|\|\|1
10962\|fnocwat.img\|AA_DATA_INSTALL_DIR\|\|\|\|1
10963\|fnocmax.imgs\|AA_DATA_INSTALL_DIR\|\|\|\|1
10964\|fnocmin.imgs\|AA_DATA_INSTALL_DIR\|\|\|\|1
10965\|fnocmod.imgs\|AA_DATA_INSTALL_DIR\|\|\|\|1
10966\|srzarea.img\|AA_DATA_INSTALL_DIR\|\|\|\|1
10967\|srzcode.img\|AA_DATA_INSTALL_DIR\|\|\|\|1
10968\|srzphas.img\|AA_DATA_INSTALL_DIR\|\|\|\|1
10969\|srzslop.img\|AA_DATA_INSTALL_DIR\|\|\|\|1
10970\|srzsoil.img\|AA_DATA_INSTALL_DIR\|\|\|\|1
10971\|srztext.img\|AA_DATA_INSTALL_DIR\|\|\|\|1
10972\|nmcRucPotPres.datrepack\|AA_DATA_INSTALL_DIR\|\|\|\|1
10973\|tbase.bin\|AA_DATA_INSTALL_DIR\|\|\|10915\|1
10974\|tbase.br\|AA_DATA_INSTALL_DIR\|\|\|10919\|4
10974\|tbase.bl\|AA_DATA_INSTALL_DIR\|\|\|10918\|3
10974\|tbase.tr\|AA_DATA_INSTALL_DIR\|\|\|10917\|2
10974\|tbase.tl\|AA_DATA_INSTALL_DIR\|\|\|10916\|1
10975\|geoid.dat\|AA_DATA_INSTALL_DIR\|\|\|\|1

\#

\#
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

\# The following are for the PGS_GCT tool only. The IDs are defined in

\# the PGS_GCT.h file. These entries are essential for the State Plane

\# Projection but can otherwise be deleted or commented out.

\#
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--
10200\|nad27sp\|\~/database/common/GCT\|\|\|\|1
10201\|nad83sp\|\~/database/common/GCT\|\|\|\|1

\#
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

\# The following are for the PGS_AA_DCW tool only.

\# The IDs are #defined in the PGS_AA_DCW.h file.

\# These entries may be deleted or commented out IF the AA tools are not

\# being used.

\#
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--
10990\|eurnasia/\|AA_DATA_INSTALL_DIR\|\|\|\|1
10991\|noamer/\|AA_DATA_INSTALL_DIR\|\|\|\|1

10992\|soamafr/\|AA_DATA_INSTALL_DIR\|\|\|\|1

10993\|sasaus/\|AA_DATA_INSTALL_DIR\|\|\|\|1

\#

\#
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

\# file for Constant & Unit Conversion (CUC) tools

\# IMPORTANT NOTE: THIS FILE WILL BE SUPPLIED AFTER TK4 DELIVERY!

\#
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--
10999\|PGS_CUC_maths_parameters\|\~/database/common/CUC\|\|\|\|1

\#

#\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

\# Metadata Configuration File (MCF) is a template to be filled in by
the

\# Instrument teams. MCFWrite.temp is a scratch file used to dump the
MCF

\# prior to writing to the hdf file. GetAttr.temp is similarly used to

\# dump metadata from the hdf attributes and is used by
PGS_MET_GetPCAttr.

\# (DO NOT REMOVE THESE ENTRIES)

#\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--
10250\|MCF\|\|\|\|\|1

10252\|GetAttr.temp\|/sdst/temptest/PGE03/Function1/1/tmp\|\|\|GetAttr.temp\|1
10254\|MCFWrite.temp\|/sdst/temptest/PGE03/Function1/1/tmp\|\|\|MCFWrite.temp\|1

\#

\#
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

\# Ephemeris and Attitude files logical IDs.

\# Emphemeris files will be accessed via the logical ID 10501.

\# Attitude files will be accessed via the logical ID 10502.

\# Use file versions to allow for multiple physical ephemeris

\# or attitude files.

\#
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

\#

10501\|INSERT_EPHEMERIS_FILES_HERE\|\|\|\|\|1

10502\|INSERT_ATTITUDE_FILES_HERE\|\|\|\|\|1

\#

#\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

\# Datasets for PGS_DEM tools.

\# A dataset of a given resolution is accessed via a single logical ID,

\# therefore all physical files comprising a data set must be accessed

\# via the same logical ID. Use file versions to allow for multiple

\# physical files within a single data set.

\# Data files of 30 arc-sec resolution will be accessed via the

\# logical ID 10650.

\# Data files of 3 arc-sec resolution will be accessed via the

\# logical ID 10653.

\# NOTE: The file names in each entry must also appear in the attribute

\# column of the entry (this is a requirement of the metadata tools).

\# The entries given below are \"template\" entries and should be

\# replaced with actual file name/location data before attempting

\# to use the DEM tools.

#\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

\#

10650\|DEM30ARC_NAME.hdf\|DEM_LOCATION\|\|\|DEM30ARC_NAME.hdf\|1
10653\|DEM3ARC_NAME.hdf\|DEM_LOCATION\|\|\|DEM3ARC_NAME.hdf\|1

\#

? PRODUCT OUTPUT FILES

\#########################################################################

\# This section is intended for standard product outputs, i.e., HDF-EOS

\# files generated by this PGE.

\#

\# Each logical ID may have several file instances, as given by the

\# version number in the last field.

\#########################################################################

\# Next line is the default location for PRODUCT OUTPUT FILES

#! /cc/cc_vob/ATMOS/PGE03/MOD_PR35

! /sdst/temptest/PGE03/Function1/1/run_time \#

\#

\# LRN 422551 is the runtime qc file (debug ascii)

422551\|MOD35_QC.Af1.1-new\|/sdst/temptest/PGE03/Function1/1/run_time\|\|\|\|1

\#

\# LRN 420000 is MOD07_L2 product output file

420000\|MOD07_L2.Af1.1-new\|/sdst/temptest/PGE03/Function1/1/run_time\|\|\|\|3

\# LRN 420002 is MOD07_QC (runtime ascii qc/debug file)

420002\|MOD07_QC.Af1.1-new\|/sdst/temptest/PGE03/Function1/1/run_time\|\|\|\|1

\#

402500\|MODVOLC.Af1.1-new\|/sdst/temptest/PGE03/Function1/1/run_time\|\|\|\|1

\#

#\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

\# This file is created when PGS_MET_Write is used with an intention

\# to write an ASCII representation of the MCF in memory. The user is

\# allowed to change the name and path if required.

\#

\# NOTE: THIS IS OBSOLETE, THIS ENTRY IS ONLY HERE FOR BACKWARD

\# COMPATIBILITY WITH PREVIOUS VERSIONS OF THE TOOLKIT.

\# THE LOGICAL ID 10255 SHOULD BE MOVED DOWN TO THE RUNTIME

\# PARAMETERS SECTION OF THIS FILE AND GIVEN A VALUE OF:

\# \<logical_id\>:\<version_number\> WHERE THOSE VALUES REFLECT THE

\# ACTUAL VALUES FOR THE NON-HDF OUTPUT PRODUCT FOR WHICH THE

\# ASCII METADATA IS BEING WRITTEN. e.g.:

\# 10255\|reference output product\|100:2

#\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--
10255\|asciidump\|\|\|\|\|1

\#
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

\#

? SUPPORT INPUT FILES

\#########################################################################

\# This section is intended for minor input files, e.g., calibration

\# files.

\#

\# Each logical ID may have several file instances, as given by the

\# version number in the last field.

\#########################################################################

\#

\# Next line is the default location for SUPPORT INPUT FILES !
\~/runtime

\#

\#
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

\# This ID is #defined in PGS_AA_Tools.h

\# This file contains the IDs for all support and format files (listed

\# below). This entry may be deleted or commented out if the AA tools
are

\# not being used.

\#
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--
10900\|indexFile\|\~/database/common/AA\|\|\|\|1

\#

\#
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

\# These are support files for the data set files - to be created by
user

\# (not necessarily a one-to-one relationship).

\# The IDs must correspond to the logical IDs in the index file (above).

\# These entries may be deleted or commented out if the AA tools are not

\# being used.

\#
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--
10901\|mowe13aSupport\|\~/database/common/AA\|\|\|\|1
10902\|owe13aSupport\|\~/database/common/AA\|\|\|\|1
10903\|owe14Support\|\~/database/common/AA\|\|\|\|1
10904\|etop05Support\|\~/database/common/AA\|\|\|\|1
10905\|fnoc1Support\|\~/database/common/AA\|\|\|\|1
10906\|fnoc2Support\|\~/database/common/AA\|\|\|\|1
10907\|zobler1Support\|\~/database/common/AA\|\|\|\|1
10908\|zobler2Support\|\~/database/common/AA\|\|\|\|1
10909\|nmcRucSupport\|\~/database/common/AA\|\|\|\|1
10915\|tbaseSupport\|\~/database/common/AA\|\|\|\|1
10916\|tbase1Support\|\~/database/common/AA\|\|\|\|1
10917\|tbase2Support\|\~/database/common/AA\|\|\|\|1
10918\|tbase3Support\|\~/database/common/AA\|\|\|\|1
10919\|tbase4Support\|\~/database/common/AA\|\|\|\|1
10740\|usatile1Support\|\~/database/common/AA\|\|\|\|1
10741\|usatile2Support\|\~/database/common/AA\|\|\|\|1
10742\|usatile3Support\|\~/database/common/AA\|\|\|\|1
10743\|usatile4Support\|\~/database/common/AA\|\|\|\|1
10744\|usatile5Support\|\~/database/common/AA\|\|\|\|1
10745\|usatile6Support\|\~/database/common/AA\|\|\|\|1
10746\|usatile7Support\|\~/database/common/AA\|\|\|\|1
10747\|usatile8Support\|\~/database/common/AA\|\|\|\|1
10748\|usatile9Support\|\~/database/common/AA\|\|\|\|1
10749\|usatile10Support\|\~/database/common/AA\|\|\|\|1
10750\|usatile11Support\|\~/database/common/AA\|\|\|\|1
10751\|usatile12Support\|\~/database/common/AA\|\|\|\|1
10948\|geoidSupport\|\~/database/common/AA\|\|\|\|1

\#

\#
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

\# The following are format files for each data set file (not
necessarily

\# a one-to-one relationship).

\# The IDs must correspond to the logical

\# IDs in the index file (10900, above).

\# These entries may be deleted or commented out if the AA tools are not

\# being used.

\#
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--
10920\|mowe13a.bfm\|\~/database/common/AA\|\|\|\|1
10921\|owe13a.bfm\|\~/database/common/AA\|\|\|\|1
10922\|owe14d.bfm\|\~/database/common/AA\|\|\|\|1
10923\|owe14dr.bfm\|\~/database/common/AA\|\|\|\|1
10924\|etop05.bfm\|\~/database/common/AA\|\|\|\|1
10925\|fnocAzm.bfm\|\~/database/common/AA\|\|\|\|1
10926\|fnocOcm.bfm\|\~/database/common/AA\|\|\|\|1
10927\|fnocPt.bfm\|\~/database/common/AA\|\|\|\|1
10928\|fnocRdg.bfm\|\~/database/common/AA\|\|\|\|1
10929\|fnocSt.bfm\|\~/database/common/AA\|\|\|\|1
10930\|fnocUrb.bfm\|\~/database/common/AA\|\|\|\|1
10931\|fnocWat.bfm\|\~/database/common/AA\|\|\|\|1
10932\|fnocMax.bfm\|\~/database/common/AA\|\|\|\|1
10933\|fnocMin.bfm\|\~/database/common/AA\|\|\|\|1
10934\|fnocMod.bfm\|\~/database/common/AA\|\|\|\|1
10935\|srzArea.bfm\|\~/database/common/AA\|\|\|\|1
10936\|srzCode.bfm\|\~/database/common/AA\|\|\|\|1
10937\|srzPhas.bfm\|\~/database/common/AA\|\|\|\|1
10938\|srzSlop.bfm\|\~/database/common/AA\|\|\|\|1
10939\|srzSoil.bfm\|\~/database/common/AA\|\|\|\|1
10940\|srzText.bfm\|\~/database/common/AA\|\|\|\|1
10941\|nmcRucSigPotPres.bfm\|\~/database/common/AA\|\|\|\|1
10942\|tbase.bfm\|\~/database/common/AA\|\|\|\|1
10943\|tbase1.bfm\|\~/database/common/AA\|\|\|\|1
10944\|tbase2.bfm\|\~/database/common/AA\|\|\|\|1
10945\|tbase3.bfm\|\~/database/common/AA\|\|\|\|1
10946\|tbase4.bfm\|\~/database/common/AA\|\|\|\|1
10700\|usatile1.bfm\|\~/database/common/AA\|\|\|\|1
10701\|usatile2.bfm\|\~/database/common/AA\|\|\|\|1
10702\|usatile3.bfm\|\~/database/common/AA\|\|\|\|1
10703\|usatile4.bfm\|\~/database/common/AA\|\|\|\|1
10704\|usatile5.bfm\|\~/database/common/AA\|\|\|\|1
10705\|usatile6.bfm\|\~/database/common/AA\|\|\|\|1
10706\|usatile7.bfm\|\~/database/common/AA\|\|\|\|1
10707\|usatile8.bfm\|\~/database/common/AA\|\|\|\|1
10708\|usatile9.bfm\|\~/database/common/AA\|\|\|\|1
10709\|usatile10.bfm\|\~/database/common/AA\|\|\|\|1
10710\|usatile11.bfm\|\~/database/common/AA\|\|\|\|1
10711\|usatile12.bfm\|\~/database/common/AA\|\|\|\|1
10947\|geoid.bfm\|\~/database/common/AA\|\|\|\|1

\#

\#

\#
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

\# leap seconds (TAI-UTC) file (DO NOT REMOVE THIS ENTRY)

\#
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--
10301\|leapsec.dat\|\~/database/common/TD\|\|\|\|1

\#

\#
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

\# polar motion and UTC-UT1 file (DO NOT REMOVE THIS ENTRY)

\#
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--
10401\|utcpole.dat\|\~/database/common/CSC\|\|\|\|1

\#

\#
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

\# earth model tags file (DO NOT REMOVE THIS ENTRY)

\#
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--
10402\|earthfigure.dat\|\~/database/common/CSC\|\|\|\|1

\#

\#
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

\# JPL planetary ephemeris file (binary form) (DO NOT REMOVE THIS ENTRY)

\#
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--
10601\|de200.eos\|\~/database/sgi32/CBP\|\|\|\|1

\#

\#
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

\# spacecraft tag definition file (DO NOT REMOVE THIS ENTRY)

\#
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--
10801\|sc_tags.dat\|\~/database/common/EPH\|\|\|\|1

\#

\#
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

\# units conversion definition file (DO NOT REMOVE THIS ENTRY)

\#
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--
10302\|udunits.dat\|\~/database/common/CUC\|\|\|\|1

\#

\#

? SUPPORT OUTPUT FILES

\#########################################################################

\# This section is intended for minor output files, e.g., log files.

\#

\# Each logical ID may have several file instances, as given by the

\# version number in the last field.

\#

\#########################################################################

\# Next line is default location for SUPPORT OUTPUT FILES

#! /cc/cc_vob/ATMOS/PGE03/MOD_PR35

! /sdst/temptest/PGE03/Function1/1/log

\#

\#

\#
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

\# These files support the SMF log functionality. Each run will cause

\# status information to be written to 1 or more of the Log files. To

\# simulate DAAC operations, remove the 3 Logfiles between test runs.

\# Remember: all executables within a PGE will contribute status data to

\# the same batch of log files. (DO NOT REMOVE THESE ENTRIES)

\#
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--
10100\|LogStatus\|\|\|\|\|1

10101\|LogReport\|\|\|\|\|1

10102\|LogUser\|\|\|\|\|1

10103\|TmpStatus\|\|\|\|\|1

10104\|TmpReport\|\|\|\|\|1

10105\|TmpUser\|\|\|\|\|1

10110\|MailFile\|\|\|\|\|1

\#

\#
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

\# ASCII file which stores pointers to runtime SMF files in lieu of

\# loading them to shared memory, which is a TK5 enhancement.

\# (DO NOT REMOVE THIS ENTRY)

\#
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--
10111\|ShmMem\|\|\|\|\|1

\#

\#

? USER DEFINED RUNTIME PARAMETERS

\#########################################################################

\# This section is intended for parameters used as PGE input.

\#

\# Note: these parameters may NOT be changed dynamically.

\#########################################################################

\#

#Inventory RP specifications

10258\|Collection Start Time (UTC) \|1997-08-05T17:25:00

10259\|Collection Stop Time (UTC) \|1997-08-05T17:30:00

\#

424000\|REPROCESSINGACTUAL\|processed once

424001\|REPROCESSINGPLANNED\|further update is anticipated
424002\|LOCALVERSIONID\|002

424003\|PGEVERSION\|2

424004\|ASSOCIATEDPLATFORMSHORTNAME.1\|AM-1
424005\|ASSOCIATEDINSTRUMENTSHORTNAME.1\|MODIS
424006\|ASSOCIATEDSENSORSHORTNAME.1\|CCD

\#

#Archive RP specifications

424100\|Number_Of_Archive_RP\|7

424101\|Archive RP_Name_1\|ALGORITHMPACKAGEACCEPTANCEDATE

424102\|Archive RP_Name_2\|ALGORITHMPACKAGEMATURITYCODE

424103\|Archive RP_Name_3\|ALGORITHMPACKAGENAME

424104\|Archive RP_Name_4\|ALGORITHMPACKAGEVERSION

424105\|Archive RP_Name_5\|LONGNAME

424106\|Archive RP_Name_6\|INSTRUMENTNAME

424107\|Archive RP_Name_7\|LOCALINPUTGRANULEID

424108\|Archive_RP_Value_1\|June 1997

424109\|Archive_RP_Value_2\|at-launch

424110\|Archive_RP_Value_3\|ATBD-MOD-06

424111\|Archive_RP_Value_4\|2

424112\|Archive_RP_Value_5\|MODIS Cloud Mask and Spectral Test Results
424113\|Archive_RP_Value_6\|Moderate Resolution Imaging
Spectroradiometer 424114\|Archive_RP_Value_7\|2

\#

#Runtime parameter referring back to non-HDF file (output debug)
422508\|MOD_PR35.qc\|422551:1

\#

#Runtime parameter referring back to mod07 QC file (Output debug)
420004\|MOD_PR07.qc\|420002:1

\#

#mod07 Inventory RP specifications

421000\|REPROCESSINGACTUAL\|processed once

421001\|REPROCESSINGPLANNED\|further update is anticipated
421002\|LOCALVERSIONID\|002

421003\|PGEVERSION\|2

421004\|ASSOCIATEDPLATFORMSHORTNAME.1\|AM-1
421005\|ASSOCIATEDINSTRUMENTSHORTNAME.1\|MODIS
421006\|ASSOCIATEDSENSORSHORTNAME.1\|CCD

\#

#mod07 Archive RP specifications

421100\|Number_Of_Archive_RP\|9

421101\|Archive RP_Name_1\|ALGORITHMPACKAGEACCEPTANCEDATE

421102\|Archive RP_Name_2\|ALGORITHMPACKAGEMATURITYCODE

421103\|Archive RP_Name_3\|ALGORITHMPACKAGENAME

421104\|Archive RP_Name_4\|ALGORITHMPACKAGEVERSION

421105\|Archive RP_Name_5\|LONGNAME

421106\|Archive RP_Name_6\|INSTRUMENTNAME

421107\|Archive RP_Name_7\|Profiles_Algorithm_Version_Number

421108\|Archive RP_Name_8\|Total_Ozone_Algorithm_Version_Number

421109\|Archive RP_Name_9\|Stability_Indices_Algorithm_Version_Number

421110\|Archive_RP_Value_1\|June 1997

421111\|Archive_RP_Value_2\|at-launch

421112\|Archive_RP_Value_3\|ATBD-MOD-07

421113\|Archive_RP_Value_4\|2

421114\|Archive_RP_Value_5\|MODIS Level 2 Profiles
421115\|Archive_RP_Value_6\|Moderate Resolution Imaging
Spectroradiometer 421116\|Archive_RP_Value_7\|1

421117\|Archive_RP_Value_8\|1

421118\|Archive_RP_Value_9\|1

\#

#modprvolc

402502\|RP Reference to VOLCALERT\|402500:1

\#
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

\# These parameters are required to support the PGS_SMF_Send\...()
tools.

\# If the first parameter (TransmitFlag) is disabled, then none of the

\# other parameters need to be set. By default, this functionality has
been

\# disabled. To enable, set TransmitFlag to 1 and supply the other 3

\# parameters with local information. (DO NOT REMOVE THESE ENTRIES)

\#
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--
10109\|TransmitFlag; 1=transmit,0=disable\|0 10106\|RemoteHost\|sandcrab

10107\|RemotePath\|/usr/kwan/test/PC/data

10108\|EmailAddresses\|kwan@eos.hitc.com

\#

\#
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

\# The following runtime parameters define various logging options.

\# Parameters described as lists should be space (i.e. \' \') separated.

\# The logical IDs 10117, 10118, 10119 listed below are for OPTIONAL

\# control of SMF logging. Any of these logical IDs which is unused by a

\# PGE may be safely commented out (e.g. if logging is not disabled for

\# any status level, then the line beginning 10117 may be commented
out).

\#
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--
10114\|Logging Control; 0=disable logging, 1=enable logging\|1

10115\|Trace Control; 0=no trace, 1=error trace, 2=full trace\|0

10116\|Process ID logging; 0=don\'t log PID, 1=log PID\|0

\#

10117\|Disabled status level list (e.g. W S F)\|

10118\|Disabled seed list\|0

10119\|Disabled status code list\|0

\#

\#
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

\# Toolkit version for which this PCF was intended.

\# DO NOT REMOVE THIS VERSION ENTRY!

\#
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--
10220\|Toolkit version string\|SCF B.0 TK5.2.1

\#

\#
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

\# The following parameters define the ADEOS-II TMDF values (all values

\# are assumed to be floating point types). The ground reference time

\# should be in TAI93 format (SI seconds since 12 AM UTC 1993-01-01).

\# These formats are only prototypes and are subject to change when

\# the ADEOS-II TMDF values are clearly defined. PGEs that do not access

\# ADEOS-II L0 data files do not require these parameters. In this case

\# they may be safely commented out, otherwise appropriate values should

\# be supplied.

\#
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--
10120\|ADEOS-II s/c reference time\|0

10121\|ADEOS-II ground reference time\|0

10122\|ADEOS-II s/c clock period\|0

\#

\#
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

\# The following parameter defines the TRMM UTCF value (the value is

\# assumed to be a floating point type). PGEs that do not access TRMM

\# data of any sort do not require this parameter. In this case it may
be

\# safely commented out, otherwise an appropriate value should be

\# supplied.

\#
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--
10123\|TRMM UTCF value\|0

\#

\#
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

\# The following parameter defines the Epoch date to be used for the

\# interpretation (conversion) of NASA PB5C times (the Epoch date should

\# be specified here in CCSDS ASCII format\--A or B) (reserved for
future

\# use\--this quantity is not referenced in TK 5.2). This entry may be

\# safely commented out or deleted.

\#
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--
10124\|NASA PB5C time Epoch date (ASCII UTC)\|0

\#

\#
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

\# The following parameter is a \"mask\" for the ephemeris data quality

\# flag. The value should be specified as an unsigned integer

\# specifying those bits of the ephemeris data quality flag that

\# should be considered fatal (i.e. the ephemeris data associated

\# with the quality flag should be REJECTED/IGNORED).

\#
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--
10507\|ephemeris data quality flag mask\|65536

\#

\#
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

\# The following parameter is a \"mask\" for the attitude data quality

\# flag. The value should be specified as an unsigned integer

\# specifying those bits of the attitude data quality flag that

\# should be considered fatal (i.e. the attitude data associated

\# with the quality flag should be REJECTED/IGNORED).

\#
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--
10508\|attitude data quality flag mask\|65536

\#

\#
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

\# ECS DPS trigger for PGE debug runs

\#

\# NOTICE TO PGE DEVELOPERS: PGEs which have a debug mode

\# need to examine this parameter to evaluate activation rule

\# (DO NOT REMOVE THIS ENTRY)

\#
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--
10911\|ECS DEBUG; 0=normal, 1=debug\|0 \#

\#
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

\# This entry defines the IP address of the processing host and is used

\# by the Toolkit when generating unique Intermediate and Temporary file

\# names. The Toolkit no longer relies on the PGS_HOST_PATH environment

\# variable to otain this information. (DO NOT REMOVE THIS ENTRY)

\#
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

10099\|Local IP Address of \'ether\'\|155.157.31.87

\#

? INTERMEDIATE INPUT

\#########################################################################

\# This section is intended for intermediate input files, i.e., files

\# which are output by an earlier PGE but which are not standard

\# products.

\#

\# Each logical ID may have only one file instance.

\# Last field on the line is ignored.

\#########################################################################

\# Next line is default location for INTERMEDIATE INPUT FILES !
\~/runtime

\#

\#

? INTERMEDIATE OUTPUT

\#########################################################################

\# This section is intended for intermediate output files, i.e., files

\# which are to be input to later PGEs, but which are not standard

\# products.

\#

\# Each logical ID may have only one file instance.

\# Last field on the line is ignored.

\#########################################################################

\# Next line is default location for INTERMEDIATE OUTPUT FILES

#! /cc/cc_vob/ATMOS/PGE03/MOD_PR35

! /sdst/temptest/PGE03/Function1/1/tmp

\#

\#

? TEMPORARY I/O

\#########################################################################

\# This section is intended for temporary files, i.e., files

\# which are generated during a PGE run and deleted at PGE termination.

\#

\# Entries in this section are generated internally by the Toolkit.

\# DO NOT MAKE MANUAL ENTRIES IN THIS SECTION.

\#

\#########################################################################

\# Next line is default location for TEMPORARY FILES

#! /cc/cc_vob/ATMOS/PGE03/MOD_PR35

! /sdst/temptest/PGE03/Function1/1/tmp

\#

\#

? END

APPENDIX I: Metadata Configuration File ExampleS

The following example MCF is the current version of MOD06_L2.mcf.

GROUP = INVENTORYMETADATA

GROUPTYPE = MASTERGROUP

GROUP = ECSDataGranule

OBJECT = LocalGranuleID

Mandatory = \"TRUE\"

Data_Location = \"PGE\"

NUM_VAL = 1

TYPE = \"STRING\"

END_OBJECT = LocalGranuleID

OBJECT = SizeMBECSDataGranule

Mandatory = \"FALSE\"

Data_Location = \"DSS\"

NUM_VAL = 1

TYPE = \"DOUBLE\"

END_OBJECT = SizeMBECSDataGranule

OBJECT = ProductionDateTime

Mandatory = \"TRUE\"

Data_Location = \"TK\"

NUM_VAL = 1

TYPE = \"DATETIME\"

END_OBJECT = ProductionDateTime

OBJECT = DayNightFlag

Mandatory = \"TRUE\"

Data_Location = \"PGE\"

NUM_VAL = 1

TYPE = \"STRING\"

END_OBJECT = DayNightFlag

OBJECT = ReprocessingActual

Mandatory = \"TRUE\"

Data_Location = \"PGE\"

NUM_VAL = 1

TYPE = \"STRING\"

END_OBJECT = ReprocessingActual

OBJECT = LocalVersionID

Mandatory = \"TRUE\"

Data_Location = \"PGE\"

NUM_VAL = 1

TYPE = \"STRING\"

END_OBJECT = LocalVersionID

OBJECT = ReprocessingPlanned

Mandatory = \"TRUE\"

Data_Location = \"PGE\"

NUM_VAL = 1

TYPE = \"STRING\"

END_OBJECT = ReprocessingPlanned

END_GROUP = ECSDataGranule

GROUP = MeasuredParameter

OBJECT = MeasuredParameterContainer

Data_Location = \"NONE\"

Mandatory = \"TRUE\"

CLASS = \"M\"

GROUP = QAFlags

CLASS = \"M\"

OBJECT = ScienceQualityFlag

Mandatory = \"FALSE\"

Data_Location = \"DP\"

NUM_VAL = 1

TYPE = \"STRING\"

Value = \"Not Investigated\"

END_OBJECT = ScienceQualityFlag

OBJECT = AutomaticQualityFlagExplanation

Mandatory = \"TRUE\"

Data_Location = \"PGE\"

NUM_VAL = 1

TYPE = \"STRING\"

END_OBJECT = AutomaticQualityFlagExplanation

OBJECT = AutomaticQualityFlag

Mandatory = \"TRUE\"

Data_Location = \"PGE\"

NUM_VAL = 1

TYPE = \"STRING\"

END_OBJECT = AutomaticQualityFlag

OBJECT = OperationalQualityFlagExplanation

Mandatory = \"FALSE\"

Data_Location = \"PGE\"

NUM_VAL = 1

TYPE = \"STRING\"

END_OBJECT = OperationalQualityFlagExplanation

OBJECT = OperationalQualityFlag

Mandatory = \"FALSE\"

Data_Location = \"PGE\"

NUM_VAL = 1

TYPE = \"STRING\"

END_OBJECT = OperationalQualityFlag

OBJECT = ScienceQualityFlagExplanation

Mandatory = \"FALSE\"

Data_Location = \"DP\"

NUM_VAL = 1

TYPE = \"STRING\"

Value = \"See http://modis-atmos.gsfc.nasa.gov/validation.html for more
details on MODIS Atmosphere data quality.\"

END_OBJECT = ScienceQualityFlagExplanation

END_GROUP = QAFlags

GROUP = QAStats

CLASS = \"M\"

OBJECT = QAPercentMissingData

Mandatory = \"FALSE\"

Data_Location = \"PGE\"

NUM_VAL = 1

TYPE = \"INTEGER\"

END_OBJECT = QAPercentMissingData

END_GROUP = QAStats

OBJECT = ParameterName

Mandatory = \"FALSE\"

CLASS = \"M\"

Data_Location = \"PGE\"

NUM_VAL = 1

TYPE = \"STRING\"

END_OBJECT = ParameterName

END_OBJECT = MeasuredParameterContainer

END_GROUP = MeasuredParameter

GROUP = OrbitCalculatedSpatialDomain

OBJECT = OrbitCalculatedSpatialDomainContainer

Data_Location = \"NONE\"

Mandatory = \"TRUE\"

CLASS = \"M\"

OBJECT = EquatorCrossingDate

Mandatory = \"TRUE\"

CLASS = \"M\"

Data_Location = \"PGE\"

NUM_VAL = 1

TYPE = \"DATE\"

END_OBJECT = EquatorCrossingDate

OBJECT = EquatorCrossingTime

Mandatory = \"TRUE\"

CLASS = \"M\"

Data_Location = \"PGE\"

NUM_VAL = 1

TYPE = \"TIME\"

END_OBJECT = EquatorCrossingTime

OBJECT = OrbitNumber

Mandatory = \"TRUE\"

CLASS = \"M\"

Data_Location = \"PGE\"

NUM_VAL = 1

TYPE = \"INTEGER\"

END_OBJECT = OrbitNumber

OBJECT = EquatorCrossingLongitude

Mandatory = \"TRUE\"

CLASS = \"M\"

Data_Location = \"PGE\"

NUM_VAL = 1

TYPE = \"DOUBLE\"

END_OBJECT = EquatorCrossingLongitude

END_OBJECT = OrbitCalculatedSpatialDomainContainer

END_GROUP = OrbitCalculatedSpatialDomain

GROUP = CollectionDescriptionClass

OBJECT = VersionID

Mandatory = \"TRUE\"

Data_Location = \"MCF\"

NUM_VAL = 1

TYPE = \"INTEGER\"

Value = 4

END_OBJECT = VersionID

OBJECT = ShortName

Mandatory = \"TRUE\"

Data_Location = \"MCF\"

NUM_VAL = 1

TYPE = \"STRING\"

Value = \"MOD06_L2\"

END_OBJECT = ShortName

END_GROUP = CollectionDescriptionClass

GROUP = InputGranule

OBJECT = InputPointer

Mandatory = \"TRUE\"

Data_Location = \"PGE\"

NUM_VAL = 50

TYPE = \"STRING\"

END_OBJECT = InputPointer

END_GROUP = InputGranule

GROUP = SpatialDomainContainer

GROUP = HorizontalSpatialDomainContainer

GROUP = BoundingRectangle

OBJECT = EastBoundingCoordinate

Mandatory = \"TRUE\"

Data_Location = \"PGE\"

NUM_VAL = 1

TYPE = \"DOUBLE\"

END_OBJECT = EastBoundingCoordinate

OBJECT = WestBoundingCoordinate

Mandatory = \"TRUE\"

Data_Location = \"PGE\"

NUM_VAL = 1

TYPE = \"DOUBLE\"

END_OBJECT = WestBoundingCoordinate

OBJECT = SouthBoundingCoordinate

Mandatory = \"TRUE\"

Data_Location = \"PGE\"

NUM_VAL = 1

TYPE = \"DOUBLE\"

END_OBJECT = SouthBoundingCoordinate

OBJECT = NorthBoundingCoordinate

Mandatory = \"TRUE\"

Data_Location = \"PGE\"

NUM_VAL = 1

TYPE = \"DOUBLE\"

END_OBJECT = NorthBoundingCoordinate

END_GROUP = BoundingRectangle

END_GROUP = HorizontalSpatialDomainContainer

END_GROUP = SpatialDomainContainer

GROUP = RangeDateTime

OBJECT = RangeEndingDate

Mandatory = \"TRUE\"

Data_Location = \"PGE\"

NUM_VAL = 1

TYPE = \"DATE\"

END_OBJECT = RangeEndingDate

OBJECT = RangeEndingTime

Mandatory = \"TRUE\"

Data_Location = \"PGE\"

NUM_VAL = 1

TYPE = \"TIME\"

END_OBJECT = RangeEndingTime

OBJECT = RangeBeginningDate

Mandatory = \"TRUE\"

Data_Location = \"PGE\"

NUM_VAL = 1

TYPE = \"DATE\"

END_OBJECT = RangeBeginningDate

OBJECT = RangeBeginningTime

Mandatory = \"TRUE\"

Data_Location = \"PGE\"

NUM_VAL = 1

TYPE = \"TIME\"

END_OBJECT = RangeBeginningTime

END_GROUP = RangeDateTime

GROUP = PGEVersionClass

OBJECT = PGEVersion

Mandatory = \"TRUE\"

Data_Location = \"PGE\"

NUM_VAL = 1

TYPE = \"STRING\"

END_OBJECT = PGEVersion

END_GROUP = PGEVersionClass

GROUP = AncillaryInputGranule

OBJECT = AncillaryInputGranuleContainer

Data_Location = \"NONE\"

Mandatory = \"TRUE\"

CLASS = \"M\"

OBJECT = AncillaryInputPointer

Mandatory = \"FALSE\"

CLASS = \"M\"

Data_Location = \"PGE\"

NUM_VAL = 1

TYPE = \"STRING\"

END_OBJECT = AncillaryInputPointer

OBJECT = AncillaryInputType

Mandatory = \"FALSE\"

CLASS = \"M\"

Data_Location = \"PGE\"

NUM_VAL = 1

TYPE = \"STRING\"

END_OBJECT = AncillaryInputType

END_OBJECT = AncillaryInputGranuleContainer

END_GROUP = AncillaryInputGranule

GROUP = AssociatedPlatformInstrumentSensor

OBJECT = AssociatedPlatformInstrumentSensorContainer

Data_Location = \"NONE\"

Mandatory = \"TRUE\"

CLASS = \"1\"

OBJECT = AssociatedSensorShortName

Mandatory = \"TRUE\"

CLASS = \"1\"

Data_Location = \"MCF\"

NUM_VAL = 1

TYPE = \"STRING\"

Value = \"MODIS\"

END_OBJECT = AssociatedSensorShortName

OBJECT = AssociatedPlatformShortName

Mandatory = \"TRUE\"

CLASS = \"1\"

Data_Location = \"MCF\"

NUM_VAL = 1

TYPE = \"STRING\"

Value = \"Terra\"

END_OBJECT = AssociatedPlatformShortName

OBJECT = AssociatedInstrumentShortName

Mandatory = \"TRUE\"

CLASS = \"1\"

Data_Location = \"MCF\"

NUM_VAL = 1

TYPE = \"STRING\"

Value = \"MODIS\"

END_OBJECT = AssociatedInstrumentShortName

END_OBJECT = AssociatedPlatformInstrumentSensorContainer

END_GROUP = AssociatedPlatformInstrumentSensor

GROUP = AdditionalAttributes

OBJECT = AdditionalAttributesContainer

Data_Location = \"NONE\"

Mandatory = \"FALSE\"

CLASS = \"M\"

OBJECT = AdditionalAttributeName

Mandatory = \"FALSE\"

CLASS = \"M\"

Data_Location = \"PGE\"

NUM_VAL = 1

TYPE = \"STRING\"

END_OBJECT = AdditionalAttributeName

GROUP = InformationContent

CLASS = \"M\"

OBJECT = ParameterValue

Mandatory = \"FALSE\"

Data_Location = \"PGE\"

NUM_VAL = 1

TYPE = \"STRING\"

END_OBJECT = ParameterValue

END_GROUP = InformationContent

END_OBJECT = AdditionalAttributesContainer

END_GROUP = AdditionalAttributes

END_GROUP = INVENTORYMETADATA

GROUP = ARCHIVEDMETADATA

GROUPTYPE = MASTERGROUP

OBJECT = ProcessingEnvironment

Data_Location = \"PGE\"

Mandatory = \"FALSE\"

TYPE = \"STRING\"

NUM_VAL = 1

END_OBJECT = ProcessingEnvironment

GROUP = AlgorithmPackage

OBJECT = AlgorithmPackageAcceptanceDate

Data_Location = \"PGE\"

Mandatory = \"TRUE\"

TYPE = \"STRING\"

NUM_VAL = 1

END_OBJECT = AlgorithmPackageAcceptanceDate

OBJECT = AlgorithmPackageMaturityCode

Data_Location = \"PGE\"

Mandatory = \"TRUE\"

TYPE = \"STRING\"

NUM_VAL = 1

END_OBJECT = AlgorithmPackageMaturityCode

OBJECT = AlgorithmPackageName

Data_Location = \"PGE\"

Mandatory = \"TRUE\"

TYPE = \"STRING\"

NUM_VAL = 1

END_OBJECT = AlgorithmPackageName

OBJECT = AlgorithmPackageVersion

Data_Location = \"PGE\"

Mandatory = \"TRUE\"

TYPE = \"STRING\"

NUM_VAL = 1

END_OBJECT = AlgorithmPackageVersion

OBJECT = InstrumentName

Data_Location = \"PGE\"

Mandatory = \"TRUE\"

TYPE = \"STRING\"

NUM_VAL = 1

END_OBJECT = InstrumentName

OBJECT = LongName

Data_Location = \"MCF\"

Mandatory = \"TRUE\"

TYPE = \"STRING\"

NUM_VAL = 1

Value = \"MODIS/Terra Clouds 5-Min L2 Swath 1km and 5km\"

END_OBJECT = LongName

OBJECT = LocalInputGranuleID

Data_Location = \"PGE\"

Mandatory = \"TRUE\"

TYPE = \"STRING\"

NUM_VAL = 20

END_OBJECT = LocalInputGranuleID

END_GROUP = AlgorithmPackage

GROUP = GPolygon

OBJECT = GPolygonContainer

Data_Location = \"NONE\"

Mandatory = \"TRUE\"

CLASS = \"M\"

GROUP = GRing

CLASS = \"M\"

OBJECT = ExclusionGRingFlag

Mandatory = \"TRUE\"

Data_Location = \"PGE\"

NUM_VAL = 1

TYPE = \"STRING\"

END_OBJECT = ExclusionGRingFlag

END_GROUP = GRing

GROUP = GRingPoint

CLASS = \"M\"

OBJECT = GRingPointLongitude

Mandatory = \"TRUE\"

Data_Location = \"PGE\"

NUM_VAL = 4

TYPE = \"DOUBLE\"

END_OBJECT = GRingPointLongitude

OBJECT = GRingPointLatitude

Mandatory = \"TRUE\"

Data_Location = \"PGE\"

NUM_VAL = 4

TYPE = \"DOUBLE\"

END_OBJECT = GRingPointLatitude

OBJECT = GRingPointSequenceNo

Mandatory = \"TRUE\"

Data_Location = \"PGE\"

NUM_VAL = 4

TYPE = \"INTEGER\"

END_OBJECT = GRingPointSequenceNo

END_GROUP = GRingPoint

END_OBJECT = GPolygonContainer

END_GROUP = GPolygon

OBJECT = Algorithm_Version_Cloud_Top_Property_IR

Data_Location = \"PGE\"

Mandatory = \"TRUE\"

TYPE = \"STRING\"

NUM_VAL = 1

END_OBJECT = Algorithm_Version_Cloud_Top_Property_IR

OBJECT = Algorithm_Version_Cloud_Phase_IR

Data_Location = \"PGE\"

Mandatory = \"TRUE\"

TYPE = \"STRING\"

NUM_VAL = 1

END_OBJECT = Algorithm_Version_Cloud_Phase_IR

OBJECT = Algorithm_Version_Cloud_Property_VIS

Data_Location = \"PGE\"

Mandatory = \"TRUE\"

TYPE = \"STRING\"

NUM_VAL = 1

END_OBJECT = Algorithm_Version_Cloud_Property_VIS

OBJECT = DESCRrevision

Data_Location = \"MCF\"

Mandatory = \"FALSE\"

NUM_VAL = 1

TYPE = \"STRING\"

VALUE = \"4.0\"

END_OBJECT = DESCRrevision

OBJECT = ProductionHistory

Data_Location = \"PGE\"

Mandatory = \"FALSE\"

NUM_VAL = 1

TYPE = \"STRING\"

END_OBJECT = ProductionHistory

END_GROUP = ARCHIVEDMETADATA

END

The following example MCF is the current version of MOD10A1.MCF.

GROUP = INVENTORYMETADATA

GROUPTYPE = MASTERGROUP

GROUP = ECSDataGranule

OBJECT = LocalGranuleID

Mandatory = \"TRUE\"

Data_Location = \"PGE\"

NUM_VAL = 1

TYPE = \"STRING\"

END_OBJECT = LocalGranuleID

OBJECT = SizeMBECSDataGranule

Mandatory = \"FALSE\"

Data_Location = \"DSS\"

NUM_VAL = 1

TYPE = \"DOUBLE\"

END_OBJECT = SizeMBECSDataGranule

OBJECT = ProductionDateTime

Mandatory = \"TRUE\"

Data_Location = \"TK\"

NUM_VAL = 1

TYPE = \"DATETIME\"

END_OBJECT = ProductionDateTime

OBJECT = DayNightFlag

Mandatory = \"TRUE\"

Data_Location = \"PGE\"

NUM_VAL = 1

TYPE = \"STRING\"

END_OBJECT = DayNightFlag

OBJECT = ReprocessingActual

Mandatory = \"TRUE\"

Data_Location = \"PGE\"

NUM_VAL = 1

TYPE = \"STRING\"

END_OBJECT = ReprocessingActual

OBJECT = LocalVersionID

Mandatory = \"FALSE\"

Data_Location = \"PGE\"

NUM_VAL = 1

TYPE = \"STRING\"

END_OBJECT = LocalVersionID

OBJECT = ReprocessingPlanned

Mandatory = \"TRUE\"

Data_Location = \"PGE\"

NUM_VAL = 1

TYPE = \"STRING\"

END_OBJECT = ReprocessingPlanned

END_GROUP = ECSDataGranule

GROUP = MeasuredParameter

OBJECT = MeasuredParameterContainer

Data_Location = \"NONE\"

Mandatory = \"TRUE\"

CLASS = \"M\"

GROUP = QAFlags

CLASS = \"M\"

OBJECT = ScienceQualityFlag

Mandatory = \"FALSE\"

Data_Location = \"DP\"

NUM_VAL = 1

TYPE = \"STRING\"

Value = \"Not Investigated\"

END_OBJECT = ScienceQualityFlag

OBJECT = AutomaticQualityFlagExplanation

Mandatory = \"TRUE\"

Data_Location = \"PGE\"

NUM_VAL = 1

TYPE = \"STRING\"

END_OBJECT = AutomaticQualityFlagExplanation

OBJECT = AutomaticQualityFlag

Mandatory = \"TRUE\"

Data_Location = \"PGE\"

NUM_VAL = 1

TYPE = \"STRING\"

END_OBJECT = AutomaticQualityFlag

OBJECT = OperationalQualityFlagExplanation

Mandatory = \"FALSE\"

Data_Location = \"PGE\"

NUM_VAL = 1

TYPE = \"STRING\"

END_OBJECT = OperationalQualityFlagExplanation

OBJECT = OperationalQualityFlag

Mandatory = \"FALSE\"

Data_Location = \"PGE\"

NUM_VAL = 1

TYPE = \"STRING\"

END_OBJECT = OperationalQualityFlag

OBJECT = ScienceQualityFlagExplanation

Mandatory = \"FALSE\"

Data_Location = \"DP\"

NUM_VAL = 1

TYPE = \"STRING\"

Value = \"See
http://landweb.nascom.nasa.gov/cgi-bin/QA_WWW/qaFlagPage.cgi?sat=terra
for the Science QA status of this product.\"

END_OBJECT = ScienceQualityFlagExplanation

END_GROUP = QAFlags

GROUP = QAStats

CLASS = \"M\"

OBJECT = QAPercentMissingData

Mandatory = \"TRUE\"

Data_Location = \"PGE\"

NUM_VAL = 1

TYPE = \"INTEGER\"

END_OBJECT = QAPercentMissingData

OBJECT = QAPercentCloudCover

Mandatory = \"TRUE\"

Data_Location = \"PGE\"

NUM_VAL = 1

TYPE = \"INTEGER\"

END_OBJECT = QAPercentCloudCover

END_GROUP = QAStats

OBJECT = ParameterName

Mandatory = \"TRUE\"

CLASS = \"M\"

Data_Location = \"PGE\"

NUM_VAL = 1

TYPE = \"STRING\"

END_OBJECT = ParameterName

END_OBJECT = MeasuredParameterContainer

END_GROUP = MeasuredParameter

GROUP = OrbitCalculatedSpatialDomain

OBJECT = OrbitCalculatedSpatialDomainContainer

Data_Location = \"NONE\"

Mandatory = \"TRUE\"

CLASS = \"M\"

OBJECT = EquatorCrossingDate

Mandatory = \"TRUE\"

CLASS = \"M\"

Data_Location = \"PGE\"

NUM_VAL = 1

TYPE = \"DATE\"

END_OBJECT = EquatorCrossingDate

OBJECT = EquatorCrossingTime

Mandatory = \"TRUE\"

CLASS = \"M\"

Data_Location = \"PGE\"

NUM_VAL = 1

TYPE = \"TIME\"

END_OBJECT = EquatorCrossingTime

OBJECT = OrbitNumber

Mandatory = \"TRUE\"

CLASS = \"M\"

Data_Location = \"PGE\"

NUM_VAL = 1

TYPE = \"INTEGER\"

END_OBJECT = OrbitNumber

OBJECT = EquatorCrossingLongitude

Mandatory = \"TRUE\"

CLASS = \"M\"

Data_Location = \"PGE\"

NUM_VAL = 1

TYPE = \"DOUBLE\"

END_OBJECT = EquatorCrossingLongitude

END_OBJECT = OrbitCalculatedSpatialDomainContainer

END_GROUP = OrbitCalculatedSpatialDomain

GROUP = CollectionDescriptionClass

OBJECT = VersionID

Mandatory = \"TRUE\"

Data_Location = \"MCF\"

NUM_VAL = 1

TYPE = \"INTEGER\"

Value = 4

END_OBJECT = VersionID

OBJECT = ShortName

Mandatory = \"TRUE\"

Data_Location = \"MCF\"

NUM_VAL = 1

TYPE = \"STRING\"

Value = \"MOD10A1\"

END_OBJECT = ShortName

END_GROUP = CollectionDescriptionClass

GROUP = InputGranule

OBJECT = InputPointer

Mandatory = \"TRUE\"

Data_Location = \"PGE\"

NUM_VAL = 1

TYPE = \"STRING\"

END_OBJECT = InputPointer

END_GROUP = InputGranule

GROUP = SpatialDomainContainer

GROUP = HorizontalSpatialDomainContainer

GROUP = GPolygon

OBJECT = GPolygonContainer

Data_Location = \"NONE\"

Mandatory = \"TRUE\"

CLASS = \"M\"

GROUP = GRingPoint

CLASS = \"M\"

OBJECT = GRingPointLongitude

Mandatory = \"TRUE\"

Data_Location = \"PGE\"

NUM_VAL = 4

TYPE = \"DOUBLE\"

END_OBJECT = GRingPointLongitude

OBJECT = GRingPointLatitude

Mandatory = \"TRUE\"

Data_Location = \"PGE\"

NUM_VAL = 4

TYPE = \"DOUBLE\"

END_OBJECT = GRingPointLatitude

OBJECT = GRingPointSequenceNo

Mandatory = \"TRUE\"

Data_Location = \"PGE\"

NUM_VAL = 4

TYPE = \"INTEGER\"

END_OBJECT = GRingPointSequenceNo

END_GROUP = GRingPoint

GROUP = GRing

CLASS = \"M\"

OBJECT = ExclusionGRingFlag

Mandatory = \"TRUE\"

Data_Location = \"PGE\"

NUM_VAL = 1

TYPE = \"STRING\"

END_OBJECT = ExclusionGRingFlag

END_GROUP = GRing

END_OBJECT = GPolygonContainer

END_GROUP = GPolygon

END_GROUP = HorizontalSpatialDomainContainer

END_GROUP = SpatialDomainContainer

GROUP = RangeDateTime

OBJECT = RangeEndingDate

Mandatory = \"TRUE\"

Data_Location = \"PGE\"

NUM_VAL = 1

TYPE = \"DATE\"

END_OBJECT = RangeEndingDate

OBJECT = RangeEndingTime

Mandatory = \"TRUE\"

Data_Location = \"PGE\"

NUM_VAL = 1

TYPE = \"TIME\"

END_OBJECT = RangeEndingTime

OBJECT = RangeBeginningDate

Mandatory = \"TRUE\"

Data_Location = \"PGE\"

NUM_VAL = 1

TYPE = \"DATE\"

END_OBJECT = RangeBeginningDate

OBJECT = RangeBeginningTime

Mandatory = \"TRUE\"

Data_Location = \"PGE\"

NUM_VAL = 1

TYPE = \"TIME\"

END_OBJECT = RangeBeginningTime

END_GROUP = RangeDateTime

GROUP = PGEVersionClass

OBJECT = PGEVersion

Mandatory = \"TRUE\"

Data_Location = \"PGE\"

NUM_VAL = 1

TYPE = \"STRING\"

END_OBJECT = PGEVersion

END_GROUP = PGEVersionClass

GROUP = AssociatedPlatformInstrumentSensor

OBJECT = AssociatedPlatformInstrumentSensorContainer

Data_Location = \"NONE\"

Mandatory = \"TRUE\"

CLASS = \"1\"

OBJECT = AssociatedSensorShortName

Mandatory = \"TRUE\"

CLASS = \"1\"

Data_Location = \"MCF\"

NUM_VAL = 1

TYPE = \"STRING\"

Value = \"MODIS\"

END_OBJECT = AssociatedSensorShortName

OBJECT = AssociatedPlatformShortName

Mandatory = \"TRUE\"

CLASS = \"1\"

Data_Location = \"MCF\"

NUM_VAL = 1

TYPE = \"STRING\"

Value = \"Terra\"

END_OBJECT = AssociatedPlatformShortName

OBJECT = AssociatedInstrumentShortName

Mandatory = \"TRUE\"

CLASS = \"1\"

Data_Location = \"MCF\"

NUM_VAL = 1

TYPE = \"STRING\"

Value = \"MODIS\"

END_OBJECT = AssociatedInstrumentShortName

END_OBJECT = AssociatedPlatformInstrumentSensorContainer

END_GROUP = AssociatedPlatformInstrumentSensor

GROUP = AdditionalAttributes

OBJECT = AdditionalAttributesContainer

Data_Location = \"NONE\"

Mandatory = \"FALSE\"

CLASS = \"M\"

OBJECT = AdditionalAttributeName

Mandatory = \"FALSE\"

CLASS = \"M\"

Data_Location = \"PGE\"

NUM_VAL = 1

TYPE = \"STRING\"

END_OBJECT = AdditionalAttributeName

GROUP = InformationContent

CLASS = \"M\"

OBJECT = ParameterValue

Mandatory = \"FALSE\"

Data_Location = \"PGE\"

NUM_VAL = 1

TYPE = \"STRING\"

END_OBJECT = ParameterValue

END_GROUP = InformationContent

END_OBJECT = AdditionalAttributesContainer

END_GROUP = AdditionalAttributes

END_GROUP = INVENTORYMETADATA

GROUP = ARCHIVEDMETADATA

GROUPTYPE = MASTERGROUP

OBJECT = CharacteristicBinAngularSize

Data_Location = \"PGE\"

Type = \"DOUBLE\"

Num_Val = 1

Mandatory = \"TRUE\"

END_OBJECT = CharacteristicBinAngularSize

OBJECT = CharacteristicBinSize

Data_Location = \"PGE\"

Type = \"DOUBLE\"

Num_Val = 1

Mandatory = \"TRUE\"

END_OBJECT = CharacteristicBinSize

OBJECT = GeoAnyAbnormal

Data_Location = \"PGE\"

Type = \"STRING\"

Num_Val = 1

Mandatory = \"TRUE\"

END_OBJECT = GeoAnyAbnormal

OBJECT = GeoEstMaxRMSError

Data_Location = \"PGE\"

Type = \"DOUBLE\"

Num_Val = 1

Mandatory = \"TRUE\"

END_OBJECT = GeoEstMaxRMSError

OBJECT = DataColumns

Data_Location = \"PGE\"

Type = \"INTEGER\"

Num_Val = 1

Mandatory = \"TRUE\"

END_OBJECT = DataColumns

OBJECT = DataRows

Data_Location = \"PGE\"

Type = \"INTEGER\"

Num_Val = 1

Mandatory = \"TRUE\"

END_OBJECT = DataRows

OBJECT = GlobalGridColumns

Data_Location = \"PGE\"

Type = \"INTEGER\"

Num_Val = 1

Mandatory = \"TRUE\"

END_OBJECT = GlobalGridColumns

OBJECT = GlobalGridRows

Data_Location = \"PGE\"

Type = \"INTEGER\"

Num_Val = 1

Mandatory = \"TRUE\"

END_OBJECT = GlobalGridRows

OBJECT = AlgorithmPackageAcceptanceDate

Data_Location = \"PGE\"

Type = \"STRING\"

Num_Val = 1

Mandatory = \"FALSE\"

END_OBJECT = AlgorithmPackageAcceptanceDate

OBJECT = AlgorithmPackageMaturityCode

Data_Location = \"PGE\"

Type = \"STRING\"

Num_Val = 1

Mandatory = \"FALSE\"

END_OBJECT = AlgorithmPackageMaturityCode

OBJECT = AlgorithmPackageName

Data_Location = \"PGE\"

Type = \"STRING\"

Num_Val = 1

Mandatory = \"FALSE\"

END_OBJECT = AlgorithmPackageName

OBJECT = AlgorithmPackageVersion

Data_Location = \"PGE\"

Type = \"STRING\"

Num_Val = 1

Mandatory = \"FALSE\"

END_OBJECT = AlgorithmPackageVersion

OBJECT = LongName

Data_Location = \"MCF\"

Type = \"STRING\"

Num_Val = 1

Mandatory = \"TRUE\"

Value = \"MODIS/Terra Snow Cover Daily L3 Global 500m SIN Grid\"

END_OBJECT = LongName

OBJECT = InstrumentName

Data_Location = \"MCF\"

Type = \"STRING\"

Num_Val = 1

Mandatory = \"TRUE\"

Value = \"Moderate Resolution Imaging Spectroradiometer\"

END_OBJECT = InstrumentName

OBJECT = PlatformShortName

Data_Location = \"MCF\"

Type = \"STRING\"

Num_Val = 1

Value = \"Terra\"

Mandatory = \"TRUE\"

END_OBJECT = PlatformShortName

OBJECT = LocalInputGranuleID

Data_Location = \"PGE\"

Type = \"STRING\"

Num_Val = 1

Mandatory = \"TRUE\"

END_OBJECT = LocalInputGranuleID

OBJECT = ProcessingCenter

Data_Location = \"MCF\"

Type = \"STRING\"

Num_Val = 1

Value = \"MODAPS\"

Mandatory = \"TRUE\"

END_OBJECT = ProcessingCenter

OBJECT = ProcessingDateTime

Data_Location = \"PGE\"

Type = \"DATETIME\"

Num_Val = 1

Mandatory = \"TRUE\"

END_OBJECT = ProcessingDateTime

OBJECT = SPSOParameters

Data_Location = \"PGE\"

Type = \"STRING\"

Num_Val = 1

Mandatory = \"TRUE\"

END_OBJECT = SPSOParameters

GROUP = BOUNDINGRECTANGLE

OBJECT = NORTHBOUNDINGCOORDINATE

Data_Location = \"PGE\"

Type = \"DOUBLE\"

Num_Val = 1

Mandatory = \"TRUE\"

END_OBJECT = NORTHBOUNDINGCOORDINATE

OBJECT = SOUTHBOUNDINGCOORDINATE

Data_Location = \"PGE\"

Type = \"DOUBLE\"

Num_Val = 1

Mandatory = \"TRUE\"

END_OBJECT = SOUTHBOUNDINGCOORDINATE

OBJECT = EASTBOUNDINGCOORDINATE

Data_Location = \"PGE\"

Type = \"DOUBLE\"

Num_Val = 1

Mandatory = \"TRUE\"

END_OBJECT = EASTBOUNDINGCOORDINATE

OBJECT = WESTBOUNDINGCOORDINATE

Data_Location = \"PGE\"

Type = \"DOUBLE\"

Num_Val = 1

Mandatory = \"TRUE\"

END_OBJECT = WESTBOUNDINGCOORDINATE

END_GROUP = BOUNDINGRECTANGLE

OBJECT = ProcessingEnvironment

Data_Location = \"PGE\"

Mandatory = \"FALSE\"

TYPE = \"STRING\"

NUM_VAL = 1

END_OBJECT = ProcessingEnvironment

OBJECT = DESCRrevision

Data_Location = \"MCF\"

Mandatory = \"TRUE\"

NUM_VAL = 1

TYPE = \"STRING\"

VALUE = \"4.1\"

END_OBJECT = DESCRrevision

OBJECT = ProductionHistory

Data_Location = \"PGE\"

Mandatory = \"FALSE\"

NUM_VAL = 1

TYPE = \"STRING\"

END_OBJECT = ProductionHistory

END_GROUP = ARCHIVEDMETADATA

END

APPENDIX J: CHECKLIST FOR items to accompany delivery

The following is a checklist for the items to accompany code delivery:

1\. HDF file specification delivered using the established naming
convention.

2\. Deliver process-specific seed files (with initial delivery to SDST).

3\. Delivery includes all required elements of a README file and packing
list, as specified in this document. The README and packing list must
each be delivered as a single ASCII text file separate from the other
(with initial delivery to SDST).

4\. Bit-level description of all data files, using SDST-developed
template (prior to final delivery to SDST). These descriptions must be
delivered as ASCII files.

5\. Tolerances, binary information files if DAAC determines they are
needed (with final delivery to SDST).

6\. Data sets used as input to and output from significant SCF tests
(with initial delivery to SDST).

APPENDIX K: checklist for the coding requirements:

1\. All mandatory functions in SDPTK (includes metadata and ancillary
data routines).

2\. Notify SSTG when major algorithm changes are anticipated which could
significantly increase volumes and loads.

3\. Use PCF Logical Unit Numbers (LUNs) falling within a range assigned
to each discipline, and for the particular process. Processes reading
ancillary data files or products written by other processes use exact
LUNs assigned to those files by SDST.

4\. Use SMF seed numbers falling within a range assigned to each
discipline, and for the particular process.

5\. Use HDF 4.1r5, or M-API 2.3. 4, or more current versions.

6\. Code adheres to all ESDIS/MODIS standards, subject to any waivers
granted. New waivers to be requested through SSTG lead for your
discipline (Atmosphere, Land, Ocean)

7\. All messages are sent to SMF log files, none to the screen.

8\. Use standard naming convention for product file, PCF, and makefile.

9\. Final HDF output products include ECS core metadata with standard
MODIS definitions, and product-specific metadata. Developer provides
information needed for MCF.

10\. Final HDF output products include QA flags.

11\. Code uses SDST-developed makefile template provided in Appendix F.

13\. All memory leaks are resolved.

14\. Description of all tests performed at the SCF in developing the
code.

15\. Physical delivery follows procedure established by CM for initial
acceptance - copy to DEV/IN, notification sent to CM, all required
elements provided.

APPENDIX L: C Language Examples of Metadata Tool Usage

L.1 PGS_MET_Init

/\* Example of using PGS_MET_Init to initialize metadata structure \*/

/\* Include file for MET tools \*/

#include \"PGS_MET.h\"

/\* Define logical ID for MCF (should be unique for each process) \*/

#define MCF_FILE 410250

int main()

{

/\* Declare variables \*/

PGSt_MET_all_handles mdhandles; /\* Metadata handles \*/

PGSt_SMF_Status ret_val; /\* Status return code \*/

/\* Call PGS_MET_Init to initialize metadata structure in memory \*/

ret_val = PGS_MET_Init(MCF_FILE, mdhandles);

L.2 PGS_PC_GetConfigData

/\* Example of using PGS_PC_GetConfigData to retrieve a value from the
PCF \*/

/\* Include file for PC tools \*/

#include \"PGS_PC.h\"

/\* Define logical ID for PCF parameter \*/

#define MODIS_META_ID_1 201010

int main()

/\* Declare variables \*/

char \*attrval; /\* Character variable for metadata field \*/

PGSt_PC_logical metID;

/\* Allocate memory for character attribute

PGSt_SMF_Status ret_val; /\* Status return code \*/

attrval = (char \*) malloc(PGSd_PC_VALUE_LENGTH_MAX);

/\* Call PGS_PC_GetConfigData to retrieve value of field from PCF \*/

metID = MODIS_META_ID_1;

ret_val = PGS_PC_GetConfigData(metID, attrval);

L.3 getMODISECSinfo

/\* Example of using getMODISECSinfo to retrieve ECS metadata from an
input

file which has been previously opened by openMODISfile \*/

/\* Include file for M-API \*/

#include \"mapi.h\"

/\* definition in M-API include file

#define MECS_CORE \"coremetadata.0\"

#define MCORE_NORTH_BOUND \"NORTHBOUNDINGCOORDINATE\" \*/

int main()

{

/\* Declare variables \*/

MODFILE \*modID; /\* M-API file handle for input file \*/

char \*dtype = R32; /\* Metadata type \*/

long n_elements = 1; /\* Number of elements in metadata \*/

float bounding_north = 0.; /\* Variable to receive metadata \*/

PGSt_SMF_Status ret_val; /\* Status return code \*/

/\* Call getMODISECSinfo to retrieve the value of
NORTHBOUNDINGCOORDINATE \*/

ret_val = getMODISECSinfo(modID, MECS_CORE, MCORE_NORTH_BOUND, dtype,

&n_elements, &bounding_north);

L.4 PGS_MET_GetPCAttr

/\* Example of using PGS_Met_GetPCAttr to retrieve a value from an input
file \*/

/\* Include files \*/

#include \"PGS_MET.h\"

#include \"PGS_PC.h\"

/\* definitions borrowed from M-API include file \*/

#define MECS_CORE \"coremetadata.0\"

#define MCORE_SIZE_OF_GRANULE \"SIZEMBECSDATAGRANULE\"

int main()

{

/\* Declare variables \*/

PGSt_PC_Logical fileID = 201000; /\* PCF logical ID for input file \*/

PGSt_integer version = 1; /\* PCF version number for input file \*/

PGSt_SMF_Status ret_val; /\* Status return code \*/

PGSt_integer size; /\* Variable to receive metadata \*/

/\* Call PGS_MET_GetPCAttr to retrieve the value of SIZEMBECSDATAGRANULE
\*/

ret_val = PGS_MET_GetPCAttr(fileID, version, MECS_CORE,

MCORE_SIZE_OF_GRANULE, &size);

L.5 PGS_MET_SetAttr

/\* Example of using PGS_MET_SetAttr to set a metadata value in memory
\*/

/\* Include files \*/

#include \"PGS_MET.h\"

/\* definition borrowed from M-API include file \*/

#define MCORE_GRING_POINT_LAT \"GRINGPOINTLATITUDE\"

int main()

{

/\* Declare variables \*/

PGSt_MET_all_handles mdhandles; /\* Metadata handles \*/

PGSt_SMF_Status ret_val; /\* Status return code \*/

float glats\[4\] = {0}; /\* Variable containing metadata \*/

/\* Call PGS_MET_SetAttr to store values of GRINGPOINTLATITUDE in
structure \*/

ret_val = PGS_MET_SetAttr(mdhandles\[GRANULEDATA\],
MCORE_GRING_POINT_LAT,

glats);

L.6 completeMODISfile

/\* Example of calling completeMODISfile to write metadata to a product
\*/

/\* Note: this example shows only one attribute being written, but the

routine will write up to the maximum number (20) of metadata

attribute in a single call \*/

/\* Include file for M-API \*/

#include \"mapi.h\"

int main()

{

/\* Declare variables \*/

MODFILE \*modID; /\* M-API file handle for input file \*/

PGSt_MET_all_handles mdhandles; /\* Metadata handles \*/

ECSattr_names_for_all_handles HDF_attr_names /\* Metadata attribute
names \*/

int n_handles = 1; /\* Number of metadata attributes to write \*/

PGSt_SMF_Status ret_val; /\* Status return code \*/

/\* Set metadata attribute names \*/

HDF_attr_names\[0\] = MECS_CORE; /\* defined in mapi.h to
\"CoreMetadata.0\" \*/

/\* Write metadata and close file using completeMODISfile \*/

ret_val = completeMODISfile(&modID, mdhandles, HDF_attr_names,
n_handles);

L.7 PGS_MET_Write

/\* Example of calling PGS_MET_Write to write metadata to a product \*/

/\* Include files \*/

#include \"PGS_MET.h\"

/\* definition borrowed from M-API include file \*/

#define MECS_CORE \"coremetadata.0\"

int main()

{

/\* Declare variables \*/

int outfile; /\* HDF ID for output product file \*/

PGSt_MET_all_handles mdhandles; /\* Metadata handles \*/

PGSt_SMF_Status ret_val; /\* Status return code \*/

/\* Write metadata to one attribute of output file using PGS_MET_Write
\*/

ret_val = PGS_MET_Write(mdhandles\[GRANULEDATA\], MECS_CORE, outfile);

APPENDIX M: SCF TEMPLATE FOR REQUIRED METADATA

**MODIS PGE INFORMATION and ESDT/MCF METADATA REQUIRED for NEW MODIS
PGES**

**Contact MODIS SDST Systems Analyst for Help with Metadata**

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

INFORMATION REQUIRED to ORDER ESDTS and MCFS from ECS

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

The following information is needed for MODIS SDST to order the ESDTs
for new products. ESDTs from ECS are needed only for products that
MODAPS will export to one of the DAACs.

SCF Name: \_\_\_\_\_\_\_\_\_\_\_\_\_

SCF Software Developer's Name:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

PGE Assigned by MODIS SDST: \_\_\_\_\_\_\_\_

Name of MODIS Process that Generates the Products: (Format: MOD_PRxxx)

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Satellite Data Types for MODIS Products: (Valids: Terra, Aqua,
Terra+Aqua)

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Frequency of Update for Product: (Valids: 5-Min, Daily, Weekly, 8-Day,
16-Day,

Monthly, 32-Day, 96-Day, Yearly)

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

First Version of the PGE to be Making the Products:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Approximate Date when the PGE is Expected to Go into MODAPS or GES DAAC
Operations:

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

ESDT DESCRIPTOR and MCF TEMPLATE for the SCF

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

The following template provides information on the metadata for the
MODIS ESDT products to be exported to the DAAC and archived for
distribution to science data users. For all attributes with blank value
fields, please fill in the appropriate values or check the suggested
values provided. Use the valids provided for attributes requiring them
and use free text for the others. All data types and maximum lengths are
indicated when applicable. The attributes are marked as **Required** or
**Optional** as described in the MODIS Software Delivery Guide. Remove
any optional attributes and replace any values that you do not want.
Please contact the MODIS SDST Systems Analyst if you have questions.

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Column Headers

Name Value DataLocation Mandatory NUM_VAL Class TYPE

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

COLLECTION LEVEL - These attributes are in the ESDT Descriptor and are
loaded into the ECS Database at the DAACs. Many of the Collection level
attributes are not shown here. They have standard values for various
types of ESDTs and are used by ECS only. The values for the attributes
listed below must be supplied by the SCF or by MODIS SDST with the
concurrence of the SCF.

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

\*\*\* SpatialSearchType is **Required.** If a product granule is a L2
swath or an individual L3 or L4 tile, SpatialSearchType is \"GPolygon\";
if the content of a product granule is global data, such as a CMG
product, SpatialSearchType is \"Rectangle\".

**SpatialSearchType** \_\_\_\_\_\_\_\_\_\_\_\_\_\_ \"MCF\" \"TRUE\" 1

\*\*\* ShortName is **Required** and has a maximum of 8 characters. It
is part of the key to the ECS Database at the DAACs. The first 3
characters for MODIS ESDTs are the following: Terra -- MOD, Aqua -- MYD,
Terra + Aqua Combined - MCD

**ShortName** \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ \"MCF\" \"TRUE\" 1

\*\*\* LongName is **Required** and has a maximum of 80 characters.
MODIS has a required standard LongName convention of the following
fields; most fields have valids:

-   Instrument/Platform (MODIS/Terra or MODIS/Aqua or MODIS Terra+Aqua)

-   Brief Product Description ( Free text provided by SCF)

-   Temporal Data Coverage Period in File (5-Min, Daily, 8-Day, 16-Day,
    Monthly, 32-Day, 96-Day, Yearly)

-   Processing Level (L0, L1A, L1B, L2, L2G, L3, L4)

-   Spatial Data Coverage (Swath, Global, Point)

-   Data Resolution (250m, 500m, 1km, 4km, 5km, 0.05Deg, ...)

-   Grid Type or Map Projection ( SIN Grid, EASE-Grid, CMG, Equal Area,
    ISEAG, CylEqDis, ...)

-   Day or Night Product Only (Specified when day and night products are
    made separately or optionally if product made only in one mode: Day,
    Night)

**LongName**

**\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_**

**\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_**

\"MCF\" \"TRUE\" 1

\*\*\* CollectionDescription is **Required** and has a maximum of 255
characters. It allows the SCF to provide a more detailed description of
the product. Many products use the same description as the LongName.

**CollectionDescription**

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

\"MCF\" \"TRUE\" 1

\*\*\* VersionID and VersionDescription are **Required**. The VersionID
is the ESDT Collection number into which the product granules are to be
archived at the DAAC. It is also part of the key to the ECS Database at
the DAACs. It is an integer value. It usually matches the value for
other products being made by the MODIS Discipline Group. It usually
matches the first number of the PGE Version, but it does not have to
match. VersionDescription is a brief description to identify the ESDT
Collection; it is usually determined by the MODIS Discipline Group when
a reprocessing into a new set of ESDT Collections is planned.

**VersionID** \_\_\_\_\_\_\_\_ \"MCF\" \"TRUE\" 1

**VersionDescription**

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

\"MCF\" \"TRUE\" 1

\*\*\* ProcessingCenter is **Required**. It is the facility that
generates the product.

Valids are: (MODAPS, GSFC).

**ProcessingCenter** \_\_\_\_\_\_\_\_\_\_\_\_ "MCF" "TRUE" 1

\*\*\* Archive Center is **Required**. It is the DAAC to which the
product is exported.

Valids are: (GSFC, LPDAAC, NSIDC).

**ArchiveCenter** \_\_\_\_\_\_\_\_\_\_\_\_ \"MCF\" \"TRUE\" 1

\*\*\* DisciplineTopicParameters Group is **Required**. ECS requires an
ESDT to have at least one GCMD keyword. Many products have more. An
example is shown below. It may or may not be relevant to your ESDT
product in this ESDT Descriptor. Since GCMD frequently changes the
keywords, it is best to select your GCMD keywords from their web site.
ECS updates their list to match GCMD\'s list on a regular schedule.
There are four attributes in the DisciplineTopicParameters Group. Please
fill in the GCMD keywords that describe your product.

**ECSDisciplineKeyword** \"Earth Science\" \"MCF\" \"TRUE\" 1 \"1\"

**ECSTopicKeyword** \"Land Surface\" \"MCF\" \"TRUE\" 1 \"1\"

**ECSTermKeyword** \"Surface Radiative Properties\" \"MCF\" \"TRUE\" 1
\"1\"

**ECSVariableKeyword** \"Reflectance\" \"MCF\" \"TRUE\" 1 \"1\"

\*\*\* ProcessingLevelID is **Required**.

Valids are: (L0, L1A, L1B, L2, L2G, L3, L4).

**ProcessingLevelID** \_\_\_\_\_\_\_\_ \"MCF\" \"TRUE\" 1

\*\*\* ProcessingLevelDescription is **Required**.

Valids are: RAW, CNTS, RADCORR, GEOQUANT, GEOLOC, GRID, Sensor
Measurements, Radiometric Counts, Telemetery Data, Level 1B Radiances,
Geophysical Quantities at the sensor resolution, or geolocated.

**ProcessingLevelDescription**
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

\"MCF\" \"TRUE\" 1

\*\*\* Platform Group is **Required**. Below is a condensed version of
the Platform, Instrument, Sensor Group and Container metadata required
by ECS. The valids for the PlatformShortName are Terra and Aqua. Use a
single Platform for either a Terra or Aqua ESDT along with the
Instrument and Sensor as shown below. For multi-platform ESDTs, the
whole container is repeated for the additional platforms.

**PlatformShortName** \"Terra\" \"MCF\" \"TRUE\" 1 \"1\"

**InstrumentShortName** \"MODIS\" \"MCF\" \"TRUE\" 1 \"1\"

**SensorShortName** \"MODIS\" \"MCF\" \"TRUE\" 1 \"1\"

**PlatformShortName** \"Aqua\" \"MCF\" \"TRUE\" 1 \"2\"

**InstrumentShortName** \"MODIS\" \"MCF\" \"TRUE\" 1 \"2\"

**SensorShortName** \"MODIS\" \"MCF\" \"TRUE\" 1 \"2\"

\*\*\* AdditionalAttributes/PSAs are **Optional** in the ECS Data Model.
MODIS requires a few. The required AdditionalAttributes shown below may
be used as examples. There is a limit of 255 characters for the
description and 40 characters for the name.

Valids for data type are: \"int\", \"float\", \"varchar\". See the MODIS
Science Software Delivery Guide for relevant fields to include.

Please add others that you want. If the PSA is new, send an email
message with the information listed for PSAs in the MODIS Software
Delivery Guide. Land SCFs should remove the specific required attributes
for Land tiles if they are not applicable to your product. ECS will take
care of the Class fields. Once an ESDT Collection is operational, PSAs
may be added to the ESDT Descriptor and MCF, but they may not be
deleted. However, any addition requires a new version of the ESDT
Descriptor and MCF.

\*\*\* The following AdditionalAttribute/PSA is **Required** by MODIS.

**AdditionalAttributeDatatyp**e \"varchar\" \"MCF\" \"FALSE\" 1 \"1\"

**AdditionalAttributeDescription** \"Version of the process software
that generated the

product.\" \"MCF\" \"FALSE\" 1 \"1\"

**AdditionalAttributeName** \"PROCESSVERSION\" \"MCF\" \"FALSE\" 1 \"1\"

\*\*\* The following AdditionalAttribute/PSA is **Required** by the
MODIS Land Discipline Group for tiled products.

**AdditionalAttributeDatatype** \"int\" \"MCF\" \"FALSE\" 1 \"2\"

**AdditionalAttributeDescription** \"MODIS Land tile identification
number which represents a geographical area on the surface of the Earth
bounded by latitude and longitude coordinates.\" \"MCF\" \"FALSE\" 1
\"2\"

**AdditionalAttributeName** \"TileID\" \"MCF\" \"FALSE\" 1 \"2\"

\*\*\* The following AdditionalAttributes/PSAs are frequently included
in MODIS Land tiled product ESDTs.

**AdditionalAttributeDatatype** \"int\" \"MCF\" \"FALSE\" 1 \"3\"

**AdditionalAttributeDescription** \"Horizontal tile number of a grid,
which increases from left to right.\" \"MCF\" \"FALSE\" 1 \"3\"

**AdditionalAttributeName** \"HORIZONTALTILENUMBER\" \"MCF\" \"FALSE\" 1
\"3\"

**AdditionalAttributeDatatype** \"int\" \"MCF\" \"FALSE\" 1 \"4\"

**AdditionalAttributeDescription** \"Vertical tile number of a grid,
which increases from top to bottom.\" \"MCF\" \"FALSE\" 1 \"4\"

**AdditionalAttributeName** \"VERTICALTILENUMBER\" \"MCF\" \"FALSE\" 1
\"4\"

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

INVENTORY LEVEL - Core Attributes that are either required in the MCF or
are optional but frequently included in MODIS MCFs. Many attributes,
some with values, have been included in the template so that the PGE
code can be written accordingly. If the DataLocation is "PGE", "DSS", or
"TK", there is no value for the SCF to select or to add to this
template.

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

\*\*\* The following attributes in the MCF are **Required.**

Valids for ReprocessingPlanned are: ("no further update anticipated",
"further update is anticipated", "further update anticipated using
enhanced PGE").

Valids for ReprocessingActual are: ("processed once", "reprocessed
once", "reprocessed twice", "reprocessed").

Values recommended by MODIS are "further update is anticipated"for
ReprocessingPlanned and "processed once" for ReprocessingActual on the
first processing of the data and "reprocessed" for all subsequent
reprocessings.

Valids for DayNightFlag are: ("Day", "Night", "Both", "NA").

**SizeMBECSDataGranule** \"DSS\" \"FALSE\" 1 \"DOUBLE\"

**ReprocessingPlanned** \"PGE\" \"TRUE\" 1 \"STRING\"

**ReprocessingActual** \"PGE\" \"TRUE\" 1 \"STRING\"

**LocalGranuleID** \"PGE\" \"TRUE\" 1 \"STRING\"

**DayNightFlag** \"PGE\" \"TRUE\" 1 \"STRING\"

**ProductionDateTime** \"TK\" \"TRUE\" 1 \"DATETIME\"

\*\*\* LocalVersionID is **Optional**. This attribute is recommended for
inclusion by MODIS even if you have no current plan to use it. In the
past some SCFs have needed to include an Inventory Level, version-type
attribute for a specific ESDT Collection after this Collection was being
populated in operations. If LocalVersionID was included, it was
available for this purpose. Mandatory can be TRUE or FALSE.

**LocalVersionID** \"PGE\" \"FALSE\" 1 \"STRING\"

\*\*\* At least one MeasuredParameter is **Required** for all MODIS
Standard Products. The ParameterNames are written by the PGE and do not
appear in the ESDT Descriptor or MCF. If you have a MeasuredParameter,
the QAPercentMissingData is **Required** to be included, but the other
QAPercents are **Optiona**l for inclusion.

The MODIS convention for initialization of the ScienceQualityFlag is to
set the value to the valid of "Not Investigated" when the ESDT is
created. The MODIS Science Team members will update this flag as various
stages of validation of the products are completed.

The initialization values for the ScienceQualityFlagExplanation are QA
web sites that are different for each MODIS Science Discipline. In
addition the Land Discipline has different QA web site for Terra and
Aqua. The values should be selected to match your science discipline\'s
web site and to match the Terra or Aqua web site if applicable. For
future collections of ESDTs, the Land Discipline plans to have the PGE
write the ScienceQualityFlagExplanation. See the alternate format below.
The values are the following:

Atmosphere Discipline:

\"See http://modis-atmos.gsfc.nasa.gov/validation.html for more details
on MODIS Atmosphere data quality.\"

Land Discipline:

\"See
http://landweb.nascom.nasa.gov/cgi-bin/QA_WWW/qaFlagPage.cgi?sat=terra
for the Science QA status of this product.\"

\"See
http://landweb.nascom.nasa.gov/cgi-bin/QA_WWW/qaFlagPage.cgi?sat=aqua
for the Science QA status of this product.\"

Oceans Discipline:

\"See http://modis-ocean.gsfc.nasa.gov/qa/knownprobs.html for more
details on MODIS Ocean data quality.\"

An example of the MeasuredParameter attributes is given below.
ScienceQualityFlagExplanation and have either format:

**ParameterName** \"PGE\" \"TRUE\" 1 \"M\" \"STRING\"

**AutomaticQualityFlag** \"PGE\" \"TRUE\" 1 \"M\" \"STRING\"

**AutomaticQualityFlagExplanation** \"PGE\" \"TRUE\" 1 \"M\" \"STRING\"

**OperationalQualityFlag** \"PGE\" \"FALSE\" 1 \"M\" \"STRING\"

**OperationalQualityFlagExplanation** \"PGE\" \"FALSE\" 1 \"M\"
\"STRING\"

**ScienceQualityFlag** \"Not Investigated\" \"DP\" \"FALSE\" 1 \"M\"
\"STRING\"

**ScienceQualityFlagExplanation**

\"See http://modis-atmos.gsfc.nasa.gov/validation.html for more details
on MODIS Atmosphere data quality.\" \"DP\" \"FALSE\" 1 \"M\" \"STRING\"

or

**ScienceQualityFlagExplanation** \"PGE\" \"TRUE\" 1 \"M\" \"STRING\"

**QAPercentInterpolatedData** \"PGE\" \"TRUE\" 1 \"M\" \"INTEGER\"

**QAPercentMissingData** \"PGE\" \"TRUE\" 1 \"M\" \"INTEGER\"

**QAPercentOutofBoundsDat**a \"PGE\" \"TRUE\" 1 \"M\" \"INTEGER\"

\*\*\* The following OrbitCalculatedSpatialDomain group of attributes is
**Optional**. These attributes are included in most Level 2 or orbital
products. Only some higher level products include this group. SDST
recommends that you do not include this group for higher level products
unless you have specific reasons for the inclusion. If the group is
included, either OrbitNumber or the pair of Start and Stop OrbitNumber
must be included. In either case the other three attributes must be
included.

\-\-\-\-\-\-- For Products with data from only one orbit.

**OrbitNumber** \"PGE\" \"TRUE\" 1 \"M\" \"INTEGER\"

\-\-\-\-\-\-- For Products with data from multiple orbits.

**StartOrbitNumber** \"PGE\" \"TRUE\" 1 \"M\" \"INTEGER\"

**StopOrbitNumber** \"PGE\" \"TRUE\" 1 \"M\" \"INTEGER\"

\-\-\-\-\-\-- For both cases:

**EquatorCrossingLongitude \"PGE\" \"TRUE\" 1 \"M\" \"DOUBLE\"**

**EquatorCrossingTime \"PGE\" \"TRUE\" 1 \"M\" \"TIME\"**

**EquatorCrossingDate \"PGE\" \"TRUE\" 1 \"M\" \"DATE\"**

\*\*\* The following **Required** attributes must have the same values
as in the Collection Level.

**ShortName \_\_\_\_\_\_\_\_ \"MCF\" \"TRUE\" 1 \"STRING\"**

**VersionID \_\_\_\_ \"MCF\" \"TRUE\" 1 \"INTEGER\"**

\*\*\* InputPointer **is Required**. The value is the maximum number of
input files expected. If more than the maximum number are written by the
PGE, the InputPointer will be truncated and those files over the maximum
will not appear in the product metadata.

**InputPointer** \"PGE" \"TRUE\" \## \_\_\_\_\_ \"STRING"

\*\*\* The Spatial attributes group is **Required**. Either GRing or
Bounding Rectangle must be selected for MODIS products.

\-\-\-\-\-\-\-\-- ZoneIdentifier is **Optional**. There is a 64
character limit. Description is provided in the ECS Data Model. See SDST
for help if needed.

**ZoneIdentifier** \"PGE\" \"TRUE\" 1

\-\-\-\-\-\-\-- For products that are swaths or tiles, the GRing is
used.

**ExclusionGRingFlag** \"PGE\" \"TRUE\" 1 \"M\" \"STRING\"

**GringPointLongitude** \"PGE\" \"TRUE\" 4 \"M\" \"DOUBLE\"

**GringPointLatitude** \"PGE\" \"TRUE\" 4 \"M\" \"DOUBLE\"

**GringPointSequenceNo** \"PGE\" \"TRUE\" 4 \"M\" \"INTEGER\"

\-\-\-\-\-\-\-- For products that have global granules, the Bounding
Rectangle is used.

**WestBoundingCoordinate** \"PGE\" \"TRUE\" 1 "DOUBLE"

**NorthBoundingCoordinate** \"PGE\" \"TRUE\" 1 "DOUBLE"

**EastBoundingCoordinate** \"PGE\" \"TRUE\" 1 "DOUBLE"

**SouthBoundingCoordinate** \"PGE\" \"TRUE\" 1 "DOUBLE"

\*\*\* The temporal attributes are **Required**. All current MODIS
products have the RangeDateTime group.

**RangeBeginningTime \"PGE\" \"TRUE\" 1 \"TIME\"**

**RangeEndingTime \"PGE\" \"TRUE\" 1 \"TIME\"**

**RangeBeginningDate \"PGE\" \"TRUE\" 1 \"DATE\"**

**RangeEndingDate \"PGE\" \"TRUE\" 1 \"DATE\"**

\*\*\* PGEVersion is **Required** for all MODIS Products.

**PGEVersion** \"PGE\" \"TRUE\" 1 \"STRING\"

\*\*\* AncillaryInput Type and Pointer was designed to specify input
files that are necessary in order to interpret the data in the output
product. ECS is discouraging the use of these attributes. SDST
recommends that they not be included and that all input files be
included in the InputPointer attribute instead.

**AncillaryInputType \"PGE\" \"TRUE\" 1 \"M\" \"STRING\"**

**AncillaryInputPointer \"PGE\" \"TRUE\" 1 \"M\" \"STRING\"**

\*\*\* AssociatedPlatformInstrumentSensor attributes are **Required** by
MODIS. They are hard-coded in the MCFs. The attributes valids for
Platform are Terra and Aqua. These are shown below. For Combined
products the whole group is repeated, one for Terra and one for Aqua.

**AssociatedSensorShortName \"MODIS\" \"MCF\" \"TRUE\" 1 \"1\"
\"STRING\"**

**AssociatedPlatformShortName \"Terra\" \"MCF\" \"TRUE\" 1 \"1\"
\"STRING\"**

**AssociatedInstrumentShortName \"MODIS\" \"MCF\" \"TRUE\" 1 \"1\"
\"STRING\"**

**AssociatedSensorShortName \"MODIS\" \"MCF\" \"TRUE\" 1 \"1\"
\"STRING\"**

**AssociatedPlatformShortName \"Aqua\" \"MCF\" \"TRUE\" 1 \"1\"
\"STRING\"**

**AssociatedInstrumentShortName \"MODIS\" \"MCF\" \"TRUE\" 1** \"1\"
\"STRING\"

\*\*\* ProductSpecificAttributes (PSA) Metadata are **Optional**. --
These PSAs must match the AdditionalAttributes above in the Collection
Level. Ranges are optional. If the PSA has a range of values, the range
is indicated as in the examples below.

If the data type is "STRING', the PSA may have a set of valid values.
These must be indicated by the VALIDRULE field as follows:

VALIDRULE = Match(\<value1, value2...\>).

If more than one value is allowed for a data granule, the maximum number
of values allowed is indicated by the following:

MAXOCCURRENCES = \<"digit value\>.

If needed, these additional fields may be entered in the template on the
line after the PSA is defined. See the MODIS Science Software Delivery
Guide for relevant fields to include.

PROCESSVERSION is **Required** by MODIS to be included even if it not
currently used. TileID is **Required** by MODIS Land Discipline for its
tiled products. With the exception of PROCESSVERSION, the other
attributes in the list below should be removed from the template if they
are not applicable to the product.

**PROCESSVERSION \"MCF\" \"FALSE\" STRING**

**TileID \"RANGE(0,4294967295)\" \"MCF\" \"FALSE\" INTEGER**

HORIZONTALTILENUMBER \"RANGE(0,143)\" \"MCF\" \"FALSE\" INTEGER

**VERTICALTILENUMBER \"RANGE(0,71)\" \"MCF\" \"FALSE\" INTEGER**

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

ARCHIVEDMETADATA - Primarily Metadata requested by the SCF. You may add
as many attributes about the products as desired. Once an ESDT
Collection is operational, Archived Metadata attributes may be added or
deleted to the ESDT Descriptor and MCF, but any such change requires a
new version of the ESDT Descriptor and MCF.

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

\*\*\* The following attributes are **Required** by MODIS. The LongName
matches the Collection Level LongName.

**LongName**

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

\"MCF\" \"TRUE\" 1 \"STRING\"

**ProcessingEnvironment \"PGE\" \"FALSE\" 1 \"STRING\"**

**ProductionHistory \"PGE\" \"FALSE\" 1 \"STRING\"**

\-\-\-\-\-\-\-- The first number in the DESCRrevison usually matches the
VersionID and/or the first digit in the PGEVersion number. The
DESCRrevison has two digital character fields and starts with #.0. The
last digit is incremented with a new version of the basic Collection,
i.e., some ECS-allowed changes have been made to the metadata.

**DESCRrevision** \_\_\_\_\_\_\_ \"MCF\" \"TRUE\" 1 \"STRING\"

\*\*\* The Spatial Bounding Rectangle is **Required** by MODAPS if the
primary coordinates are GRings.

**NorthBoundingCoordinate** \"PGE\" \"TRUE\" 1 \"DOUBLE\"

**SouthBoundingCoordinate** \"PGE\" \"TRUE\" 1 \"DOUBLE\"

**EastBoundingCoordinate** \"PGE\" \"TRUE\" 1 \"DOUBLE\"

**WestBoundingCoordinate** \"PGE\" \"TRUE\" 1 \"DOUBLE\"

\*\*\* The following attributes are **Optional** but recommended if
applicable. The Mandatory field can be TRUE or FALSE. The SPSOParameters
can also be written by the PGE.

**SPSOParameters** \_\_\_\_\_\_ \"MCF\" \"TRUE\" 1 \"STRING\"

**AlgorithmPackageAcceptanceDate** \"PGE\" \"FALSE\" 1 \"STRING\"

**AlgorithmPackageMaturityCode** \"PGE\" \"FALSE\" 1 \"STRING\"

**AlgorithmPackageName** \"PGE\" \"FALSE\" 1 \"STRING\"

**AlgorithmPackageVersion** \"PGE\" \"FALSE\" 1 \"STRING\"

APPENDIX N: Browse Format example

The following is an example of the browse data format.

Typical browse product ECS Inventory metadata (stored in the hdf file
under the attribute name \"CoreMetadata.0\") is shown below in this
example using the ncdump utility on the Land L3 500m Surface Reflectance
browse product (MOD09A1).

ncdump -h BROWSE.MOD09A1.A2003265.h10v04.004.2003284080235.hdf

global attributes:

:CoreMetadata.0 =

GROUP = INVENTORYMETADATA

GROUPTYPE = MASTERGROUP

> GROUP = ECSDataGranule
>
> OBJECT = LOCALGRANULEID
>
> NUM_VAL = 1
>
> VALUE = BROWSE.MOD09A1.A2003265.h10v04.004.2003284080235.hdf
>
> END_OBJECT = LOCALGRANULEID
>
> OBJECT = BROWSEDESCRIPTION
>
> NUM_VAL = 1
>
> VALUE = MOD09A1.A2003265.h10v04.004.2003284080235.hdf
>
> END_OBJECT = BROWSEDESCRIPTION
>
> OBJECT = PRODUCTIONDATETIME
>
> NUM_VAL = 1
>
> VALUE = 2003-10-11T08:02:59.000Z
>
> END_OBJECT = PRODUCTIONDATETIME
>
> END_GROUP = ECSDataGranule
>
> GROUP = COLLECTIONDESCRIPTIONCLASS
>
> OBJECT = VERSIONID
>
> NUM_VAL = 1
>
> VALUE = 1
>
> END_OBJECT = VERSIONID
>
> OBJECT = SHORTNAME
>
> NUM_VAL = 1
>
> VALUE = BROWSE
>
> END_OBJECT = SHORTNAME

END_GROUP = COLLECTIONDESCRIPTIONCLASS

END_GROUP = INVENTORYMETADATA

END

global attributes:

:CoreMetadata.0 =

GROUP = INVENTORYMETADATA

GROUPTYPE = MASTERGROUP

> GROUP = ECSDataGranule
>
> OBJECT = LOCALGRANULEID
>
> NUM_VAL = 1
>
> VALUE = BROWSE.MOD09A1.A2003265.h10v04.004.2003284080235.hdf
>
> END_OBJECT = LOCALGRANULEID
>
> OBJECT = BROWSEDESCRIPTION
>
> NUM_VAL = 1
>
> VALUE = MOD09A1.A2003265.h10v04.004.2003284080235.hdf
>
> END_OBJECT = BROWSEDESCRIPTION
>
> OBJECT = PRODUCTIONDATETIME
>
> NUM_VAL = 1
>
> VALUE = 2003-10-11T08:02:59.000Z
>
> END_OBJECT = PRODUCTIONDATETIME
>
> END_GROUP = ECSDataGranule
>
> GROUP = COLLECTIONDESCRIPTIONCLASS
>
> OBJECT = VERSIONID
>
> NUM_VAL = 1
>
> VALUE = 1
>
> END_OBJECT = VERSIONID
>
> OBJECT = SHORTNAME
>
> NUM_VAL = 1
>
> VALUE = BROWSE
>
> END_OBJECT = SHORTNAME

END_GROUP = COLLECTIONDESCRIPTIONCLASS

END_GROUP = INVENTORYMETADATA

END

The following results from the hdfls command below provide a quick
listing of the tags, reference numbers and length of each of the data
objects in the sample MOD09A1 browse product.

hdfls -v BROWSE.MOD09A1.A2003265.h10v04.004.2003284080235.hdf

BROWSE.MOD09A1.A2003265.h10v04.004.2003284080235.hdf:

File library version: Major= 4 Minor=1 Release=1

String=NCSA HDF Version 4.1 Release 1 February 21 1997

24-bit JPEG Encoding : (tag 15)

Ref no 1 0 bytes

Version Descriptor : (tag 30)

Ref no 1 92 bytes

Number type : (tag 106)

Ref no 1 4 bytes

Image Dimensions : (tag 300)

Ref no 1 20 bytes

Compressed Image : (tag 303)

Ref no 1 56663 bytes

Raster Image Group : (tag 306)

Ref no 1 8 bytes

Vdata : (tag 1962)

Ref no 2 64 bytes

Vdata Storage : (tag 1963)

Ref no 2 1094 bytes

Vgroup : (tag 1965)

Ref no 3 78 bytes

The \"hdp dumprig\" command without options dumps all RIGs in the file,

shown here for the sample MOD09A1 browse product containing just one

image.

hdp dumprig BROWSE.MOD09A1.A2003265.h10v04.004.2003284080235.hdf

File name: BROWSE.MOD09A1.A2003265.h10v04.004.2003284080235.hdf

ndsets=1 dumpall=1 num_chosen=-1

Data model: 24-bit raster image with palette.

width=240; height=240

reference=1

\*data is compressed and the compression scheme is

Data :

4 40 0 0 30 0 10 39 0 40 68 7 39 68 10 23 52 0 12 42 0 21 50

0 32 56 0 55 73 15 70 80 27 89 97 50 159 167 126 53 66 23 54

68 17 177 194 140 110 128 78 40 59 13 43 69 22 24 45 4 64 74

40 94 99 69 82 86 59 33 39 11 81 85 58 161 166 136 189 193 160

136 144 103 63 81 33 22 42 0 47 61 8 43 55 7 129 135 101 141

147 111 58 64 16 83 92 37 69 80 22 75 86 28 73 81 22 60 68 11

49 58 3 35 45 0 33 41 0 34 43 0 49 65 16 34 52 2 26 39 0 43 56

12 54 66 20 51 63 13 42 51 0 40 48 0 51 56 0 78 82 23 62 62 8

47 46 0 61 58 5 78 72 20 96 89 37 123 117 65 120 117 66 92 92

\<listing truncated\>

APPENDIX O: PCR Form

<table style="width:100%;">
<colgroup>
<col style="width: 17%" />
<col style="width: 2%" />
<col style="width: 8%" />
<col style="width: 8%" />
<col style="width: 2%" />
<col style="width: 1%" />
<col style="width: 2%" />
<col style="width: 5%" />
<col style="width: 9%" />
<col style="width: 2%" />
<col style="width: 7%" />
<col style="width: 3%" />
<col style="width: 9%" />
<col style="width: 0%" />
<col style="width: 8%" />
<col style="width: 11%" />
</colgroup>
<tbody>
<tr class="odd">
<td colspan="2"><p><strong>NASA</strong></p>
<p><strong>National Aeronautics</strong></p></td>
<td colspan="8"><strong>MODIS PRODUCT CHANGE REQUEST</strong></td>
<td colspan="4"><strong>1. PCR Number</strong></td>
<td colspan="2"><p><strong>2. Date</strong></p>
<p> / /</p></td>
</tr>
<tr class="even">
<td colspan="2"><p><strong>and</strong></p>
<p><strong>Space Administration</strong></p></td>
<td colspan="5"><strong>3. Mission:</strong></td>
<td colspan="4"><strong>4. Operational Approval Needed by:</strong></td>
<td colspan="5"><p><strong>5. Change Type (see below)</strong></p>
<p> <strong>1</strong> <strong>2</strong></p>
<p> <strong>3</strong> <strong>4</strong></p></td>
</tr>
<tr class="odd">
<td colspan="16"><p><strong>6. Initiated by:</strong></p>
<p><strong>Name:</strong></p>
<p><strong>Organization:</strong></p>
<p><strong>Phone:</strong></p>
<p><strong>MODIS Science Discipline Lead:</strong></p></td>
</tr>
<tr class="even">
<td colspan="16"><strong>7. Problem Statement:</strong> (max 500
characters)</td>
</tr>
<tr class="odd">
<td colspan="16"></td>
</tr>
<tr class="even">
<td colspan="16"><strong>8. Description of Change:</strong> (max 500
characters)</td>
</tr>
<tr class="odd">
<td colspan="16"></td>
</tr>
<tr class="even">
<td colspan="16"><strong>9. Products and Software Affected:</strong>
(max 500 characters)</td>
</tr>
<tr class="odd">
<td colspan="16"></td>
</tr>
<tr class="even">
<td colspan="5"> PGE:</td>
<td colspan="7"> LUT:</td>
<td colspan="4"> Loader:</td>
</tr>
<tr class="odd">
<td colspan="5"> Process:</td>
<td colspan="7"> Recipe:</td>
<td colspan="4"> Input File:</td>
</tr>
<tr class="even">
<td colspan="5"> Production Rule:</td>
<td colspan="7"> DAAC Ingest:</td>
<td colspan="4"> Other (DB):</td>
</tr>
<tr class="odd">
<td colspan="16"><strong>10. Processing String to Receive the
Change</strong></td>
</tr>
<tr class="even">
<td> Terra Forward</td>
<td colspan="5"> Terra Reprocessing</td>
<td colspan="3"> Aqua Forward</td>
<td colspan="4"> Aqua Reprocessing</td>
<td colspan="3"> GDAAC</td>
</tr>
<tr class="odd">
<td colspan="16"><strong>11. Downstream Product Effects:</strong> (max
500 characters)</td>
</tr>
<tr class="even">
<td colspan="16"></td>
</tr>
<tr class="odd">
<td colspan="16"> Science Testing Required</td>
</tr>
<tr class="even">
<td colspan="16">Data Granules to be used for Science Testing:</td>
</tr>
<tr class="odd">
<td colspan="16"><strong>12. Justification/Product Improvement:</strong>
(max 500 characters/provide attachments if needed)</td>
</tr>
<tr class="even">
<td colspan="16"></td>
</tr>
<tr class="odd">
<td colspan="16"><strong>13. Amount of Effort Required to Make Change
(estimate):</strong> (max 500 characters)</td>
</tr>
<tr class="even">
<td colspan="16"></td>
</tr>
<tr class="odd">
<td colspan="16"><strong>14. Effective Date for Implementation of
Change:</strong> (max 250 characters)</td>
</tr>
<tr class="even">
<td colspan="16"></td>
</tr>
<tr class="odd">
<td colspan="16"><strong>15. Systems Engineering Comments:</strong> (max
250 characters)</td>
</tr>
<tr class="even">
<td colspan="16"></td>
</tr>
<tr class="odd">
<td colspan="3"><strong>16. Downstream Products Affected:</strong></td>
<td colspan="13"><strong>Concurrence:</strong> (science discipline lead
initials and date)</td>
</tr>
<tr class="even">
<td colspan="3"> Level 1B</td>
<td colspan="13"></td>
</tr>
<tr class="odd">
<td colspan="3"> Geolocation</td>
<td colspan="13"></td>
</tr>
<tr class="even">
<td colspan="3"> Atmosphere Level 2</td>
<td colspan="13"></td>
</tr>
<tr class="odd">
<td colspan="3"> Atmosphere Level 3</td>
<td colspan="13"></td>
</tr>
<tr class="even">
<td colspan="3"> Land Level 2</td>
<td colspan="13"></td>
</tr>
<tr class="odd">
<td colspan="3"> Land Level 3+</td>
<td colspan="13"></td>
</tr>
<tr class="even">
<td colspan="3"> Ocean Level 2</td>
<td colspan="13"></td>
</tr>
<tr class="odd">
<td colspan="3"> Ocean Level 3+</td>
<td colspan="13"></td>
</tr>
<tr class="even">
<td colspan="3"> Direct Broadcast Users</td>
<td colspan="13"></td>
</tr>
<tr class="odd">
<td colspan="3"> Rapid Fire Products</td>
<td colspan="13"></td>
</tr>
<tr class="even">
<td colspan="3"> NOAA RTPS</td>
<td colspan="13"></td>
</tr>
<tr class="odd">
<td colspan="4"><strong>17. Approval</strong></td>
<td colspan="4"></td>
<td colspan="7"><strong>18. Concurrence</strong></td>
<td></td>
</tr>
<tr class="even">
<td colspan="4"></td>
<td colspan="4"></td>
<td colspan="7"></td>
<td></td>
</tr>
<tr class="odd">
<td colspan="4">___________________________</td>
<td colspan="4">_____</td>
<td colspan="7">___________________________</td>
<td>_____</td>
</tr>
<tr class="even">
<td colspan="4"><strong>Science Team Lead</strong></td>
<td colspan="4"><strong>Date</strong></td>
<td colspan="7"><strong>Systems Engineer</strong></td>
<td><strong>Date</strong></td>
</tr>
<tr class="odd">
<td colspan="4"></td>
<td colspan="4"></td>
<td colspan="7"></td>
<td></td>
</tr>
<tr class="even">
<td colspan="4"><strong>19. PCR Implemented</strong></td>
<td colspan="4"></td>
<td colspan="7"></td>
<td></td>
</tr>
<tr class="odd">
<td colspan="4"></td>
<td colspan="4"></td>
<td colspan="7"></td>
<td></td>
</tr>
<tr class="even">
<td colspan="4">___________________________</td>
<td colspan="4">_____</td>
<td colspan="7">___________________________</td>
<td>_____</td>
</tr>
<tr class="odd">
<td colspan="4"><strong>MODAPS Manager</strong></td>
<td colspan="4"><strong>Date</strong></td>
<td colspan="7"><strong>Or GDAAC Manager</strong></td>
<td><strong>Date</strong></td>
</tr>
<tr class="even">
<td colspan="4"></td>
<td colspan="4"></td>
<td colspan="7"></td>
<td></td>
</tr>
</tbody>
</table>

  -------------------------- ----------------------- ---------------------
  **20. Actual Changes                               
  Implemented:** (max 500                            
  characters)                                        

                                                     

  PGE:                       LUT:                    Loader:

  Process:                   Recipe:                 Input File:

  Production Rule:           DAAC Ingest:            Other :
  -------------------------- ----------------------- ---------------------

**Change Type:**

[Type 1]{.underline}: Minor "bug" fixes which correct or improve known
problems (or that improve QA /metadata/intermediate products) with no
significant impact on the distributed data product or continuous
time-series record. No reprocessing is needed as a result of these
fixes.

[Type 2 :]{.underline} Changes that fix broken code that is generating
bad or no data in the current production. Such change may or may not
warrant additional reprocessing. If reprocessing associated with this
change is required, it must be accompanied with strong rationale. 

[Type 3:]{.underline} Major changes to the science code that result in a
scientifically significant discontinuity to the product and
has downstream impacts and reprocessing implications for a continuous
data set.  

[Type 4:]{.underline} New code for products that have yet to be made.