Data Product Quality Assurance Plan (July, 1999)
1.0 Introduction
This document describes the Quality Assurance (QA) procedures that will be applied to MOPITT Science Data Product granules. Production will initially be at the MOPITT Science Computing Facility (SCF) at the National Center for Atmospheric Research (NCAR) in Boulder, Colorado. During the first eighteen months after launch processing will be transitioned to the NASA Langley Research Center (LaRC) Distributed Active Archive Center (DAAC) or LDAAC.
The EOS Data Quality Panel has defined data product quality assurance as the process by which data granule content is determined to meet expected standards of accuracy and flagged in instances where standards are not met. Quality assurance procedures are expected to take place within the operational time window of EOS standard product generation and may take place at the DAAC or at the instrument SCF.
In addition to data product quality assurance, the Data Panel has identified three other areas of data product quality control which are strongly related and have synergistic coupling to the data processing required to meet quality assurance goals. These areas include:
- instrument calibration
- instrument performance monitoring
- data product validation.
The plan described in this document is intended to both meet the goals for data product quality assurance and to provide sources of information necessary to supplement activities in the other three areas.
2.0 Related Documents
Quality Assurance Procedures for EOS Products: Concepts, Implementation and Archival. Draft 4, by Bob Lutz, ESDIS Science Office, June 20, 1995
The QA Process: A Decomposition into Functional Components. Version-2 Draft, by Bob Lutz, ESDIS Science Office, March 15, 1996.
MOPITT Algorithm Theoretical Basis Document: Conversion of MOPITT Digital Counts into Calibrated Radiances in Carbon Monoxide and Methane Absorption Bands (Level 0 to Level 1), University of Toronto and NCAR MOPITT Team, Version 3, August, 1996.
MOPITT Algorithm Theoretical Basis Document: Retrieval of Carbon Monoxide and Column Amounts of Carbon Monoxide and Methane from MOPITT Observed Radiances (Level 1 to Level 2), NCAR MOPITT Team, Version 3, August, 1996.
MOPITT Data Product Validation Plan, MOPITT Science Team, Version-4.0, 1998.
EOS Data Products Reference Guide Volume-1: TRMM & AM-1, S.W. Wharton and M.F. Myers, Editors, NASA Goddard Space Flight Center, 1997.
Drummond, J.R., MOPITT Mission Description Document, University of Toronto, 1993.
HDF-EOS Primer for Version 1 EOSDIS, Hughes Applied Information Systems, Landover, Maryland, Document # 175-WP-001-001.
The HDF-EOS Swath Concept, Hughes Applied Information Systems, Landover, Maryland, Document # 170-WP-003-001.
HDF-EOS Library User”Ēs Guide, 170-TP-005-003 and 170-TP-006-002, Hughes Information Technology Corporation, Landover, Maryland, 1997.
SDP Toolkit Users Guide for the ECS Project, EOSDIS Core System Project Document 333-CD-003-002, Hughes Information Technology Corporation, Landover, Maryland.
SDP Toolkit Primer for the ECS Project, EOSDIS Core System Project Document 194-815-SI4-001, Hughes Applied Information Systems, Landover, Maryland.
Theoretical Basis of the SDP Toolkit Geolocation Package for the ECS Project Document, 445-TP-002-002, Hughes Applied Information Systems, Landover, Maryland.
3.0 MOPITT SDP Quality Assurance Overview
3.1 Experiment Description and Data Products
The Measurements of Pollution in the Troposphere (MOPITT) instrument scheduled to fly on the EOS AM-1 platform in 1999 is provided under a Memorandum of Understanding with the Canadian Space Agency. For the first eighteen months after launch standard products are to be produced at the National Center for Atmospheric Research (NCAR) in Boulder, Colorado. Subsequently, processing will be transferred to the NASA Langley Research Center Distributed Active Archive Center (DAAC).
MOPITT is a correlation radiometer that measures thermal emission in the 4.7 mm band of carbon monoxide reflected solar radiation in the 2.3 mm band of carbon monoxide and reflected solar radiation in the 2.2 mm band of methane. These radiance measurements along with time coincident global analyses of temperature and moisture are used to derive the vertical profile of carbon monoxide in the troposphere globally as well as the total column abundance of carbon monoxide and methane for the sunlit portions of each orbit. Details of the data processing algorithms and the instrument are presented in the references described in Section 2.
MOPITT quality assurance will be performed by a combination of automated procedures within the Product Generation Executables (PGE) running at the DAAC and by human assessment of processing summaries, assisted by software tools, at the MOPITT Science Computing Facility (SCF). There are no plans to involve DAAC personnel in the day-to-day assessment of data product quality. However, there is an implied quality assurance role for the DAAC in maintaining the long-term integrity of data products as they are migrated between various archival media and in assuring that orders from users are appropriately filled.
Although the EOS Data Quality Panel has drawn a distinction between calibration, instrument monitoring, data product quality assurance and data product validation, the activities are interrelated and have some common requirements in terms of basic information that must be acquired and analyzed to support each. The activities "upstream" of product generation (instrument calibration and on-orbit instrument operation and performance) have a direct bearing on the suitability of data products for use by researchers and must be considered in the overall product quality assessment. Browse products also provide a view of the data product that is useful in establishing its overall quality. Support for these synergistic efforts is built into the MOPITT QA procedures described in this document.
The MOPITT at-launch standard product suite consists of a Level-1B radiance product and a Level-2 geophysical parameter product. No Level-3 standard product exists in the current at-launch baseline. However, a research Level-3 product will be created at the SCF to assist in data validation activities. It is possible that this or similar Level-3 data will be offered for consideration as standard products in the post-launch phase. A detailed description of the content of the MOPITT standard products is given in Appendix-A.
Appropriate use of remotely sensed quantitative measurements such as those provided by MOPITT require knowledge of uncertainties in the measurements. Error estimates for each retrieved parameter are determined as part of the data processing and are included in the data products. These provide indications of the random error or precision of each derived parameter. Systematic errors are much more difficult to determine a priori and within the time constraints of product quality assurance activities and are thus a major focus of data product validation. The MOPITT Data Validation Plan should be consulted for details on planned validation activities.
3.2 Processing Overview
Level 0 files and other ancillary data is transferred to the MOPITT SCF from the LDAAC. It is processed by the PGEs into higher level products. The level 1 and level 2 products are then transferred back to LDAAC for archiving and distribution. This data flow is illustrated in Figure 1. Along the way there are several opportunities for QA to occur. During the running of the PGEs various checks will be occurring. These checks are reported in the metadata and in the diagnostic files created. These steps constitute automatic QA. After these files are created, checks are performed to make sure that these files were created properly. These checks constitute operational QA. Failing operational QA may initiate a re-processing of the granule. Finally the MOPITT standard products will be inspected for scientific validity. Metadata will reflect the results of these checks before the data is sent to LDAAC.
4.0 SDP Quality Assurance Procedures
4.1 Level-1 Data Product
The contents of the MOPITT Level-1 data product are described in Section A-1 of Appendix A. Three major aspects of quality assurance are carried out in support of the creation of this product. These include:
- Automatic QA - Checking of input and intermediate data during creation of the data product at the SCF
- Operational QA - Examination of processing diagnostics at the SCF
- Science QA - Checking of the content of the data product during post-processing at the SCF
These operations can be seen in the context diagram of Level-1 Q/A processing shown in Figure 2. Much of the checking also supports instrument performance and calibration monitoring carried out by the MOPITT Instrument Team at the University of Toronto.
4.1.1 Level-1 Automatic QA Procedures
The MOPITT Level-0 required for creation of the Level-1 product arrives at the SCF as three streams. The first stream is designated the "engineering" stream and contains the telemetry elements defining instrument status and performance. It also contains "housekeeping" data, used for monitoring instrument health and safety, and ancillary packets from the spacecraft navigation system. The second is the "science" stream that contains all detector outputs along with information defining scan mirror position. The third stream is the "table" data, which is readout of quasi-static instrument parameters.
During the initial processing of Level-0 data, information bearing on the in-flight radiometric calibration of the MOPITT instrument is collected in a "Calibration History" file. This file will include the detector outputs observed when viewing the in-flight blackbodies and the "zero" radiance input associated with viewing deep space. Also included in the Calibration History (MOPCH) file are various engineering telemetry points important in establishing the radiometric gain and offset when viewing the calibration targets as well as other telemetry points useful for establishing long term instrument performance. The contents of the file will be maintained in their original telemetry form but averaged over appropriate time intervals for compression. Information on the variability of the parameter's telemetry elements will also be maintained. The Calibration History file will be used both for data product creation and for instrument performance monitoring. It will provide a mechanism for applying long-term calibration corrections during reprocessing should it be determined that such corrections are necessary.
4.1.1.1 Limit and Exception Checking during Product Generation
In addition to the instrument parameters that affect calibration, other indicators of instrument performance will be monitored. Monitoring may occur in two ways depending on the options selected in the configuration file. The most common is limit checking and statistics where each engineering parameter output is summarized by a mean, standard deviation, maximum value, minimum value, number of times high limit is exceeded and number of times low limit is exceeded. These values are written to the MOP01ES standard product, which is a small ASCII file. The second option is a graphical display of the time history of the parameter during the period of the Level-1 granule. This is accomplished using the Level 0 Viewer (written in IDL).
Components of the Level-0 "Science" stream will also be checked. This will occur primarily in the "verification" process of the flow chart shown in Figure 2. During this step a signal will be sent from the engineering stream indicating that all the critical instrument parameters were within valid ranges (or not). Thus the data can be considered "valid" (or it is marked "invalid"). Statistical checks are also performed on the science data to assure that the signal calculation did not produce a wildly implausible result.
Error codes from the geolocation services provided via the SDP toolkit will be monitored during the appropriate phase of processing. Pixels affected by incorrect geolocation will be flagged as invalid in the data product. Exceptions will be logged utilizing the ToolKit error tracking methods, such as writing to the LogStatus file. This log will be analyzed during the operational QA process.
4.1.2 Level 1 Operational QA Procedures
The Level 0-1 processor is run by a production system at the SCF. When the PGE has completed running, the production system will perform automated operational QA tasks. If human intervention is necessary an operator will be notified. The items that will be checked by the operational QA system include:
- That the output files are named correctly
- That they are the correct size (within a set range)
- That the PGE terminated correctly
- That the appropriate input files were available and were usable
- That no severe errors were reported in the log files
- That the summary statistics reported in the metadata are reasonable
Upon performance of these checks, the Operational QA flag will be set in the metadata (.met) file. The product is then ready for science QA.
4.1.3 SCF Level-1 Science QA Procedures
The MOPITT Level 1 files will be inspected for Science QA by Science Team staff. Under normal operational conditions it is expected that the review can be completed in 2-4 hours after the granule has been created.
Staff involved in QA evaluations will work in close proximity to the scientists responsible for development of the science algorithms used to generate the data products. QA operations will have a lead manager who is familiar with the expected science products and operation of the instrument. The manager will define the procedures and standards by which the granules will be evaluated and will be consulted in cases where data products are seen to deviate from expectations. University student assistants under the direction of team leaders who are trained in the procedures and expected data product characteristics will carry out day-to-day activities. Some of the inspection procedures will probably include:
- Detection of anomalous high or low radiances
- Detection of a large number of pixels that the algorithm invalidated
- Gaps in the data
- Comparison with validation experiments
- Detection of large scatter among data points which should be consistent (i.e. pointing at the same calibration target)
- Detection of trends in the data (indicative of instrument drift or calibration problems)
At the conclusion of the review for each granule the science QA metadata attribute will be set in the metadata (.met) file.
4.1.3.1 Display Generation
The Science Team will develop tools for use at the SCF for inspecting the granules. These tools will focus on presenting graphical representations of the data, facilitating human judgement. The primary tool will be the Level 1 viewer. This program was written in IDL by MOPITT staff. It will likely be extended to perform analysis operations.
The types of graphical displays useful in Level-1 product quality assessment include plots of instrument outputs as a function of time, calibrated radiances plotted on global projections, and the times of instrument/algorithm exceptions correlated with latitude and longitude. Examples are shown in Appendix-B.
4.1.3.2 Assessment Procedures
The QA Operations staff that is responsible for day-to-day review of Level 1 granules will carry out the assessments in accordance with procedures defined by the MOPITT Data Manager with input from the MOPITT Science Team. Acceptance criteria will be defined in these procedures. Each review item will have specific criteria that define its acceptability. Review items which do not meet these criteria will be brought to the attention of the team leader and if necessary other Science Team members for evaluation of the discrepancy.
Discrepancies will fall into several categories that require different resulting actions. At present, the following classes are recognized. During implementation of the QA Plan these may be modified as necessary or additional categories may be defined.
- Discrepancy Class 1
-
The data granule is found to be unacceptable for research use. This might be the result of algorithm failure, corrupted input data, or instrument operation anomaly. Corrective actions include: isolating the cause of failure; making any changes that may be necessary in SDP software; making any necessary software updates; and reprocessing the affected granule.
- Discrepancy Class 2
-
The data granule is deemed to be acceptable for research use but changes in QA procedures and criteria should be made. This might be the result of range limits being set too tight to accommodate natural variability or incorrect QA review procedures or criteria. Corrective actions should address making the appropriate changes to limit parameters, procedures or criteria.
- Discrepancy Class 3
The data granule is deemed acceptable for research use but changes in instrument operating characteristics are noted. This may indicate the beginning of an instrument problem with possible implications for instrument operations and SDP software. Corrective action should begin with contact with the MOPITT Instrument Team at the University of Toronto to alert them of findings. Subsequent actions may require closer scrutiny of instrument parameters during QA procedures and assessment of the sensitivity of data products to the particular changes in instrument performance.
Certain procedures and criteria may be established based on past instrument performance or data product content. This will require historical data to be available for such comparisons.
4.1.3.3 QA Metadata
Each granule will have all three of its QA metadata flags set (automatic, operational, and scientific) before being sent to the DAAC for archive. However, it is anticipated that metadata updates will be required. For example, the science QA flag may be initially set to "being investigated". Upon investigation the granule is deemed unfit for scientific research, so the QA flag would need to be set to "failed". It is expected that the SCF would inform the DAAC that such a change is required, and they would be able to perform the metadata update.
It is a concern that individual granules within an ESDT cannot be made "invisible" due to failed QA. The high and low quality granules will be commingled within an ESDT. Therefore users attention should be drawn to the QA flags to determine whether a granule is fit for scientific research. Future releases of ECS are expected to provide warning notices to users if "Failed" data is ordered. At present the QA flags are not visible upon search and order within the client. Expected enhancements should allow users to sort the data based on QA flags - prior to receiving the data for use.
4.1.3.4 QA Database Maintenance and Utilization
In order to establish appropriate operating limits for various parameters, it will be necessary to maintain historical records of selected contents of QA summaries. This will be done at the NCAR SCF with a database management system. Such information will also assist Science Team members who are involved in data product validation activities and those who are assisting the University of Toronto Instrument Team in assessing instrument performance. Analysis of long-term trends in QA parameters and statistics may also aid algorithm developers in improving the quality of data products during reprocessing.
4.2 Level-2 Data Product
The contents of the MOPITT Level-2 data product are described in Section A-2 of Appendix A. Five major aspects of quality assurance are carried out in support of the creation of this product. These include:
- Checking of input ancillary data during creation of the data product
- Checking of cloud clearing algorithm exceptions and cloud cleared radiances during creation of the data product
- Checking of retrieval algorithm exceptions and retrieved parameters during creation of the data product
- Checking of the content of the data product during post-processing
- Examination of processing diagnostics
These operations are shown in the context diagram of Level-1 QA processing shown in Figure 3. It is expected that results of the QA processing will also provide a useful supplement to data product validation activities being carried out independently by the MOPITT Science Team.

Figure 3. QA Context for the MOPITT Level-2 Data Product
It should be noted that error estimates for the derived MOPITT parameters are produced as part of the normal output of the science algorithms and are considered part of the basic data. In situations where radiance data cannot be interpreted due to ambiguity in surface or cloud conditions, no Level-2 data will be reported.
4.2.1 Level-2 Automatic QA Procedures
4.2.1.1 Limit and Exception Checking during Product Generation
Two dynamic inputs are required to create the Level-2 product; the MOPITT Level-1 radiance product described in previous sections and ancillary atmospheric data provided by the NASA GSFC Data Assimilation Office (DAO). Other data inputs are static in nature and will have been verified prior to PGE operational use. It is expected that ancillary data will include uncertainty or error estimates for the atmospheric parameters of concern that will aid in assessment of their utility in deriving MOPITT products. Ancillary data will be limit checked prior to use in radiance interpretation. Out of limit situations will be entered into the exception log (MOP02E) and interpretation of the MOPITT radiances will not be attempted at those locations.
Where suitable ancillary data exist, the MOPITT radiances will be examined for clouds and where possible, cloud-cleared radiances will be derived. A significant number of scenes will be considered too unreliable for use in retrieving carbon monoxide and methane products because of uncertainties in cloud clearing or non-uniformity of surface properties. These discarded radiances are written to a file to be analyzed during science QA and algorithm validation.
In selected cases, these discarded radiances may be transferred to the DAAC to assist data validation studies and algorithm verification activities. Cloud algorithm exceptions will also be entered into the exception log.
Corrected scene radiances which pass screening will be used with ancillary data to retrieve atmospheric concentrations of carbon monoxide and methane. Limit checking will be applied to parameters and associated error estimates returned from the retrieval process. Out of range situations will not be included in the Level-2 data product. These and other retrieval algorithm exceptions will be recorded in the exception log. Such exceptions will include lack of convergence of solutions and error conditions returned by numerical routines included in the SDP Toolkit.
4.2.2 Product Post-processing and Operational QA Procedures
The post-processing phase of the Level 1-2 DAAC PGE will assimilate information from several sources and create QA summaries. Standard Browse Products will also be created at this time. Sources of information available to the post-processor include:
- Ancillary Data
- The Exception Log (MOP02E)
- The Diagnostic File (MOP02D)
- Discarded Radiances (MOPDISRD)
- Non-Converged Radiances (MOP02NC)
- The MOPITT Level-2 Data Granule (MOP02)
- The Browse Product (MOP02B)
Global displays of selected parameters from the DAO ancillary data inputs will be created to provide a meteorological context to assist in the review of Level-2 Browse Products and QA displays which use a similar representation.
Entries will be made into exception logs when data range or algorithm internal error codes are encountered during product generation. The exceptions will be logged with a type identifier as well as data time and location markers and possibly other information pertaining to the occurrence. Scripts will search the log files and compile the number of times each particular type of exception occurs within the period of a Level-1 granule. Optionally, tabulations can be generated for each exception type that can be used to produce displays that relate occurrence to geographical location or other relevant conditions. The summaries will be reviewed along with other checks (see section 4.1.2) to comprise operational QA procedures.
4.2.3 Level-2 Science QA Procedures
Intense scrutiny of the Level 2 product and the processing diagnostics is expected initially. The QA inspection of MOP02 will be focused on whether the dynamic range of CO known to exist in the atmosphere is observed in the data, or whether certain conditions create erroneous results (e.g. cloudiness, mountains, high zenith angles). Results will also be checked against validation field data (see section 5.2). Global displays of discarded radiance events can be correlated with meteorological conditions, as described by the DAO ancillary data, to determine if coverage is consistent with expectation.
Under normal operational conditions it is expected that the review can be completed in 2-4 hours after production of the data granule. This assumes an instrument in stable operating mode and SDP software that has been verified such that the nominal characteristics of the data product are well understood. After science QA is completed the appropriate metadata will be attached and the file will be transferred to the DAAC for archive.
4.2.3.1 Display Generation
Much of the Level-2 QA review at the SCF will utilize graphical displays. Displays may be generated during PGE execution using the Interactive Data Language (IDL) suite supplied in the SDP toolkit as Browse Products. Alternatively, the displays may be generated at the SCF using a customized viewing tool. This tool is called the Level 2 Viewer. The Viewer is written in IDL and readily available for installation at additional sites.
The types of graphical displays useful in Level-2 product quality assessment include plots of zonal mean quantities, retrieved carbon monoxide and methane on global projections, locations of data/algorithm exceptions displayed on global projections, and global plots of ancillary meteorological data for correlation with other review materials. Examples are shown in Appendix-B
4.2.3.2 Assessment Procedures
The QA Operations staff that is responsible for day-to-day review of QA summaries will carry out the assessments in accordance with procedures defined by the MOPITT Data Manager with input from the MOPITT Science Team. Acceptance criteria will be defined in these procedures. Each review item will have specific criteria that define its acceptability. Review items which do not meet these criteria will be brought to the attention of the team leader and if necessary other Science Team members for evaluation of the discrepancy.
Discrepancies will fall into several categories that require different resulting actions. At present, the following classes for the Level-2 product are recognized. During implementation of the QA Plan these may be modified as necessary or additional categories may be defined.
- Discrepancy Class 1
-
The data granule is found to be unacceptable for research use. This might be the result of algorithm failure or corrupted input data. Corrective actions include: isolating the cause of failure; correcting input data if necessary; making any changes that may be necessary in SDP software; making any necessary software updates; and reprocessing the affected granule. In situations where upstream instrument or Level-1 algorithm anomalies occur, it might be necessary to suspend Level-2 production until suitable corrective action is completed.
- Discrepancy Class 2
-
The data granule is deemed to be acceptable for research use but changes in QA procedures and criteria should be made. This might be the result of range limits being set too tight to accommodate natural variability or incorrect QA review procedures or criteria. Known but acceptable deficiencies in science algorithms might also be a possible cause. Corrective actions should address making the appropriate changes to limit parameters, procedures or criteria. Deficiencies in science algorithms would likely be addressed in future software releases.
- Discrepancy Class 3
-
The data granule is deemed acceptable for research use but changes in data characteristics are noted. This may signal the onset of atmospheric conditions that are outside the capabilities of the science algorithms. Alternatively, this may indicate the beginning of an instrument problem with possible implications for instrument operations and SDP software. Corrective action should begin with additional scrutiny of the Level-1 product and notification of the Science Team involved in data validation efforts. Efforts should focus on determining if the changes in data characteristics represent real atmospheric behavior or the onset of instrument or science algorithm problems.
Certain procedures and criteria may require knowledge of product content from prior days. This will require historical data to be available for such comparisons.
4.2.3.3 QA Metadata
It is anticipated that nearly all MOPITT data users will prefer the Level 2 product to the Level 1 product. Therefore, the QA metadata for this product will be much more visible and hopefully utilized by data users. This adds an incentive to set each QA flag carefully. Each MOPITT retrieval is accompanied by an uncertainty estimate, so metadata reflecting the global quality of the data is not necessary. Otherwise, section 4.1.3.3 concerning QA metadata for Level 1 products also applies to Level 2 products.
4.2.3.4 QA Database Maintenance
The same concerns for Level 1 apply here (See section 4.1.3.4).
5.0 Implementation
To a large extent, the evolution of quality assurance activities must be guided by actual experience in working with the instrument, science algorithms, data products and the data system to be used. However, it is possible to anticipate the types of problems that will be encountered based on past experiences with similar instrumentation and data processing. Therefore, we intend to implement QA procedures in a phased approach that will allow new information and lessons learned to be assimilated as we move from concept to actual on-orbit application. The emphasis in each phase is discussed below.
5.1 Phased Implementation
- Phase-1: Infrastructure Development
-
As part of the Version-1 (Engineering Version) SDP development, infrastructure will be added to upstream PGE modules to allow appropriate information to be collected and passed to the PGE post-processor module. Prototype post-processors will be developed to produce QA summaries of each type identified in the plan. A subset of the parameters identified to be checked will be processed to demonstrate the viability of the concept. Prototype SCF tools will be developed to review QA summary information generated during SSI&T testing.
- Phase-2: Flight Checkout Implementation
-
The concept demonstrated in Phase-1 will be evaluated and modified as appropriate. The PGE post-processor modules will be expanded to full capability. The baseline list of checks will be implemented and made part of the Version-2 (Flight) SDP delivery. SCF tools will be expanded to allow review of the complete set. During the instrument and software checkout period post-launch, the approach and summaries will be evaluated and adapted to focus attention to those aspects that are found to be most important. During this time it may be necessary to define additional checks and parameters. The goal will be to establish the appropriate level of detail in QA summaries necessary to verify the data product and at the same time minimize the resources required supporting the activity.
- Phase-3: Nominal Flight Operations
-
Once stable instrument and SDP software operation has been established, QA operations should become routine. During this period, independent data validation activities may uncover subtle problems that should be addressed in QA monitoring. Should this be case, it may be necessary to modify some of the procedures.
- Phase-4: Flight Maintenance
-
As the instrument ages, it is possible that science algorithms may have to be modified to accommodate the changes. It is also very likely that improved science algorithms will be developed and applied to past data during reprocessing. Both possibilities will likely require changes to QA procedures to verify that resulting data products are produced as expected.
5.2 Validation
Reductions in the quality of the data can be characterized by relative and absolute errors. It is often easier to estimate relative error or uncertainty, since sources of error and their propagation through the processing can be calculated. Absolute error is harder to estimate because it depends on some sort of independent verification or validation. MOPITT will be devoting a great deal of effort in the post-launch phase in field experiments designed to validate the data. These validation experiments will result in algorithm improvements and will provide the QA staff with a more quantitative method of evaluating MOPITT data quality. As the validation campaign evolves, so will the QA methods and judgements.
5.3 Transition to the DAAC
This document is written under the assumption that processing will be performed at the SCF and data products will be transferred to the LDAAC for archiving. This is the scenario envisioned for at least the first six months after launch for the Level 1 processor and as much as 18 months after launch for the Level 2 processor. At these times the processors will likely be transferred to the LDAAC for processing to occur there. After processing is transferred from the SCF to the DAAC, it is expected that this document will need to be revised.
6.0 Resource Requirements
6.1 QA Personnel
The MOPITT SCF staff will typically only be available for one shift per day (8am to 5pm) during weekdays. The Scientific Computing Division (SCD) will support MOPITT with round-the-clock operators. These operators will monitor processing jobs and follow explicit instructions in response to certain error conditions.
ACRONYM LIST
| API | Application Program Interface |
| DAAC | Distributed Active Archive Center |
| ECS | Earth Observing System Data and Information System (EOSDIS) Core System |
| EOS | Earth Observing System |
| EOSDIS | Earth Observing System Data and Information System |
| HDF | Hierarchical Data Format |
| HDF-EOS | An extension to HDF for EOS data |
| IDL | Interactive Data Language |
| LaRC | Langley Research Center |
| LDAAC | The DAAC at LaRC |
| MOPITT | Measurements Of Pollution In The Troposphere |
| NASA | National Aeronautics and Space Administration |
| NCAR | National Center for Atmospheric Research |
| PGE | Product Generation Executables |
| QA | Quality Assurance |
| SCD | Scientific Computing Division |
| SCF | Science Computing Facility |
| SDP | Science Data Processing |
Appendix-A MOPITT Data Product Description
A-1 MOPITT Level-1B Radiances
EOSDIS Product Code: MOP01
Data Product Overview
The MOPITT Level-1 data product consists of the geolocated, calibrated earth scene radiances, associated instrument engineering data summaries, and inflight calibration information. Data granules are one day in duration and limited to the earth scenes observed within the midnight to midnight period. Data from special calibration sequences and instrument diagnostic modes have been excluded.
The MOPITT instrument is an eight-channel cross-track scanning correlation radiometer. Radiances representing the two states of the correlation cells are reported for each channel. These two states are:
- The "average" radiance which is a measure of the wide band signal seen by the detectors.
- The "difference" radiance which is a measure of the signal passed by the complex filter formed by the target gas in the correlation cell.
A complete description of these signals is given in the MOPITT Algorithm Theoretical Basis Documents referenced in Section 2.0. The characteristics of the eight channels are summarized in Table-1.
Each of the eight channels is imaged on optically co-aligned linear arrays of four pixels. Each pixel is approximately 22 X 22km square. Thus for every measurement time, 16 radiances are reported at each of four adjacent geographical locations. The footprint of the MOPITT observations is shown in Figure-A1 for five cross-track scan sequences. Alternate scan sequences have been shaded for clarity. Periodically these scan sequences are interrupted for a short time while the instrument views internal calibration sources.
In the normal science data collection mode, the cross-track scan begins on the cold space calibrate side of the orbit track. There are 14 possible mirror positions on each side of the nadir position. During the scan, the mirror positions are interlaced on the forward and return parts of the cross-track to maximize coverage. Each observation is termed a "stare" with the time between "stares" equal to 450 msec. Twenty-nine stares are collected for each cross track scan. The stare and pixel positions are identified in Figure-A1.
Selected instrument engineering data and the calibration factors used to convert detector counts into radiances are also collected and summarized over the time interval of each cross-track sequence. Some of these data are needed for subsequent Level-2 processing. Other engineering information is provided for convenience to the MOPITT team in support of data validation and quality control activities.
| Chan.No. | Target Gas | Cell Type | Center Wave length (mm) | Filter Band Width(mm) | Cell Pressure(kPa) | Use |
| 1 | CO | LMC | 4.617 | 0.111 | 20 | Thermal Radiation CO Profile |
| 2 | CO | LMC | 2.334 | 0.022 | 20 | Reflected Solar Radiation CO Column |
| 3 | CO | PMC | 4.617 | 0.111 | 7.5 | Thermal Radiation CO Profile |
| 4 | CH4 | LMC | 2.258 | 0.071 | 80 | Reflected Solar Radiation CH4 Column |
| 5 | CO | LMC | 4.617 | 0.111 | 80 | Thermal Radiation CO Profile |
| 6 | CO | LMC | 2.334 | 0.022 | 80 | Reflected Solar Radiation CO Column |
| 7 | CO | PMC | 4.617 | 0.111 | 3.8 | Thermal Radiation CO Profile |
| 8 | CH4 | LMC | 2.258 | 0.071 | 80 | Reflected Solar Radiation CH4 Column |
Figure A-1 MOPITT Footprint for Five Consecutive Cross Track Scans
Data Format
The MOPITT Level-1B product is archived using the HDF-EOS Swath structure that is described along with Application Program Interfaces (APIs) in references listed in Section 2.0. This structure has been defined to represent time ordered, multi-channel instrument data such as MOPITT. HDF-EOS is an extension to the Hierarchical Data Format (HDF) standard developed at the University of Illinois National Center for Supercomputer Applications. Readers should familarize themselves with HDF and HDF-EOS in advance of using the data.
Data Content
* NOTE -- DIMENSIONALITIES OF ARRAYS ARE DEFINED IN FORTRAN ORDER, C ORDER IS REVERSED *
DIMENSIONS
- ntrack = unlimited (number of cross-tracks = Number of swaths)
- nstare = 29 (29 stares per cross track swath = Number in Crosstrack)
- npixels = 4 (4 pixels per stare)
- nchan = 8 (8 channels of radiance measurement)
- nstate = 2 (Average and difference state of correlation cell)
- nengpoints = 38 (38 engineering data elements per swath)
- neng = 2 (Engineering data elements are represented as an average value over a swath and a standard deviation)
- ncalib = 8 (Calibration parameters for each radiance element: swath average gain, offset, noise and internal black body radiance and associated standard deviations)
GEOLOCATION FIELDS
The following are HDF VDATA variable names:
- Track Count: float Number of tracks in this data set
- Time: double (ntrack) (Holds time of day and date in Tai93 format for first stare in swath. Subsequent stares occur 450 milliseconds apart.)
- Swath Quality: int32 (ntrack) (TBD values to flag if entire swath has valid values)
The following are HDF Scientific Data Set (SDS) variable names
- Latitude: float (npixels,nstare,ntrack) (Latitude in degrees -90 to 90)
- Longitude: float (npixels,nstare,ntrack) (Longitude in degrees -180 to 180)
- Solar Zenith: float (npixels,nstare,ntrack) (Solar direction angles at pixel locations in degrees)
- Solar Azimuth: float (npixels,nstare,ntrack) (Solar direction angles at pixel locations in degrees)
- Satellite Zenith: float (npixels,nstare,ntrack) (Satellite direction angles at pixel locations in degrees)
- Satellite Azimuth: float (npixels,nstare,ntrack) (Satellite direction angles at pixel locations in degrees)
DATA FIELDS
The following are HDF Scientific Data Set (SDS) variable names
- MOPITT Radiances: float (nstate,nchan,npixels,nstare,ntrack) (MOPITT radiances in Watts meter-2 Sr-1 - swath format)
- 1=average state radiance
- 2=difference state radiance
- Engineering Data: float (neng,nengpoints,ntrack) (Engineering data, one set per swath)
- 1=Average over time of swath of engineering element
- 2=Variance of engineering element
- 1-4 = temperature of mirror 1 through 4 in Deg K
- 5-8 = temperature of chopper 1 through 4 in Deg K
- 9-12 = temperature of filter 1,3,5,7 in Deg K
- 13-20 = temperature of detector 1 through 8 in Deg K
- 21-24 = temperature of LMC 1 through 4 in Deg K
- 25-28 = temperature of LMC pressure sensor 1 through 4 in Deg K
- 29 = cell pressure LMC 1 CO 4.7mic in kPa (20 kPa nominal)
- 30 = cell pressure LMC 2 CH4 2.4mic in kPa (80 kPa nominal)
- 31 = cell pressure LMC 3 CO 4.7mic in kPa (80 kPa nominal)
- 32 = cell pressure LMC 4 CO 2.3mic in kPa (80 kPa nominal)
- 33-34 = temperature of PMC 1 and 2 in Deg K
- 35 = cell pressure CO PMC 1 (High state 10 kPa) 4.7mic in kPa
- 36 = cell pressure CO PMC 2 (High state 5 kPa) 4.7mic in kPa
- 37 = cell pressure CO PMC 1 (Low state 5 kPa) 4.7mic in kPa
- 38 = cell pressure CO PMC 2 (Low state 2.5 kPa) 4.7mic in kPa
- Calibration Data : float (ncalib,nstate,nchan,npixels,ntrack) (Calibration data for each state, channel and pixel) (AVERAGED OVER SWATH)
- 1=gain
- 2=offset
- 3=noise equivalent radiance in Watts meter-2 Sr-1
- 4=Internal Black Body Radiance in Watts meter-2 Sr-1
- 5=variance of gain
- 6=variance of offset
- 7=variance of noise in Watts meter-2 Sr-1
- 8=variance of Internal Black Body Radiance in Watts meter-2 Sr-1
-
(in nstate dimension)
(in neng dimension)
(in nengpoints dimension)
(in ncalib dimension)
EOSDIS Product Code: MOP02
Data Product Overview
The MOPITT Level-2 data product consists of the geolocated, retrieved carbon monoxide profiles and total column amounts for carbon monoxide and methane. Ancillary data concerning surface properties and cloud conditions at the locations of the retrieved parameters are also included.
MOPITT geophysical parameters are derived from the Level-1B radiances in combination with ancillary data describing the global distribution of surface and atmospheric temperature and humidity. Radiance measurements in the 4.7mm CO band provide the primary information on the vertical carbon monoxide mixing ratio profile in the troposphere. Total column abundances of carbon monoxide and methane are derived primarily using measurements of reflected solar radiation in 2 bands near 2.3 mm and best retrievals thus occur in sunlit portions of the orbits. Clouds have a large influence on the observed radiances and their effects must be modeled appropriately in the retrieval algorithms. Details of the approach to retrieving the geophysical parameters are presented in the Level-2 Algorithm Theoretical Basis Document referenced in Section 2.0.
Data Format
The MOPITT Level-2 product is archived using the HDF-EOS Swath structure for the Beta Delivery implementation. The Swath structure has been defined to represent time ordered, multi-channel instrument data. Where the MOPITT scenes are interrupted randomly by clouds or large variability in surface properties, much of the regularity of the original cross-track is disturbed and there will not be one-to-one correlation of retrieved parameters and radiance pixels.
HDF-EOS is an extension to the Hierarchical Data Format (HDF) standard developed at the University of Illinois National Center for Supercomputer Applications. Readers should familarize themselves with HDF and HDF-EOS in advance of using the data.
Data Content
* NOTE -- DIMENSIONALITIES OF ARRAYS ARE DEFINED IN FORTRAN ORDER, C ORDER IS REVERSED *
DIMENSIONS
- ntime = unlimited (number of retrieval time/location points)
- nprs = 6 (number of pressure levels in retrieved CO vertical profile)
- nwavlen = 3 (number of wavelengths)
- nbound = 4 (number of boundary points to describe pixel area aggregate)
- ncoord = 2 (number of coordinates for each point in pixel area aggregate)
- ntwo = 2 (Number of reported elements for each retrieved parameter - i.e. for retrieved value and its error estimate)
GLOBAL ATTRIBUTES
- MOP02_NODATA (missing_nodata): real - Value for missing data which has no data value
- TIMECNT (Time Count): integer - number of times in the data set
- MONTH (Month): integer - Month of observations
- DAY (Day): integer - Day of observations
- YEAR (Year): integer - Year of observations (4 digits)
GEOLOCATION FIELDS
- TIME (ntime): double - 'Time' time in TAI format units='seconds since 12 AM 1-1-1993'
- LAT (ntime): real - 'Latitude' latitude units='degrees'
- LONG (ntime): real - 'Longitude' longitude units='degrees east'
Data Fields
The following are HDF VDATA variable names:
- SECINDAY (ntime): real 'Seconds in Day' Time of observation in seconds of day
- WAVELENGTH (nwavlen): real 'Wavelengths' wavelengths associated with nwavelen variable units='microns'
- PRESS (nprs): real 'Pressure Grid' pressures associated with nprs variable units='kPa'
- SOLZEN (ntime): real 'Solar Zenith Angle' solar zenith angle units='degrees'
- SATZEN (ntime): real 'Satellite Zenith Angle' satellite zenith angle units='degrees'
- SURFE (ntwo,nwavlen,ntime): 'Ancillary Surface Emissivity' Surface Emissivitiy
- 1 = data
- 2 = error
- BASEP (ntwo,ntime): 'Retrieval Bottom Pressure' Bottom Pressure of Retrieval (surface or cloud top pressure) units='kPa'
- 1 = data
- 2 = error
- DBASET (ntwo,ntime): 'Derived Effective RetrievalBottom Temperature' derived effective retrieval bottom temperature units='K'
- 1 = data
- 2 = error
- DBASEE (ntwo,nwavlen,ntime): 'Derived Effective Retrieval Bottom Emissivity' derived effective emissivity (2.2, 2.3, 4.7 microns)
- 1 = data
- 2 = error
- SURFIND (ntime): integer 'Surface Indicator' 0=water,1=land,2=sea ice,3=solid cloud
- DEMALT (ntime): real 'DEM Altitude' digital elevation model altitude units='meters'
- NPIXAGG (ntime): integer 'Num Pixels Aggregate' number of pixels in aggregate
- AGGBND (nbound,ncoord,ntime): float 'Aggregate Bounds' Aggregate Bounds (TBD)
- CLOUDD (ntime): real 'Cloud Description' Cloud description - cloud amount (0 to 1 range)
- CH4COL1 (ntwo,ntime): 'CH4 Total Column Bench 1' CH4 total column on Bench 1 units='mol/cm2'
- 1 = data
- 2 = error
- CH4COL2 (ntwo,ntime): 'CH4 Total Column Bench 2' CH4 total column on Bench 2 units='mol/cm2'
- 1 = data
- 2 = error
- COCOL (ntwo,ntime): 'CO Total Column' CO total column units='mol/cm2'
- 1 = data
- 2 = error
- COMIXRAT (ntwo,nprs,ntime): 'CO Mixing Ratio' CO mixing ratio units='ppbv'
- 1 = data
- 2 = error
- COMIXRAT_BOT (ntwo,ntime): 'Retrieval Bottom CO Mixing Ratio' CO Mixing Ratio at bottom of retrieval units='ppbv'
- 1 = data
- 2 = error
- CH4COL_AP1 (ntime): float 'CH4 Column Percent Apriori Bench 1' Percent of Bench 1 CH4 Column from apriori
- CH4COL_AP2 (ntime): float 'CH4 Column Percent Apriori Bench 2' Percent of Bench 2 CH4 Column from apriori
- COMIXRAT_AP (nprs,ntime): float 'CO Mixing Ratio Percent Apriori' Percent of CH4 mixing ratio from apriori
- COMIXRAT_BOT_AP (ntime): float 'Retrieval Bottom CO Mixing Ratio Percent Apriori' Percent of CO Mixing Ratio from bottom of retrieval from apriori
Appendix-B Examples of Graphical Displays Used in MOPITT Quality Assessment
B-1 Level-1 QA Display Examples

Figure B1 - Visual display of a Level 1 radiance channel. These plots will assist in the detection of processing errors or instrument malfunctions. QA inspections of L1 data will also involve comparisons to model calculations.
B-2 Level-2 QA Display Examples

Figure B2 - Visual display of one field of a Level 2 file. Images such as these will provide the basis of the MOPITT SCF QA effort. They will be inspected for qualitative discrepancies from expected ranges. Quantitative analysis may also be performed to detect longer-term trends in the data. Note that this image is of two days of "cloud-free" simulated data. Actual Level 2 files will contain far less coverage.