Ocean PEATE

Page 1

Ocean PEATE

Fred Patt

Page 2

Ocean PEATE Agenda

• Science Team Introduction• Ocean PEATE Design• ODPS Design Overview• Implementation Plan and

Schedule• Documentation• Issues

Land

SD3E

PSOE

Ocean

Atmosphere

Ozone

Sounder

I&TSE

NICSE

Page 3

NPP/VIIRS Ocean Team

• Chuck McClain – Ocean Color PI• Peter Minnett (U. Miami) – SST PI• Gene Feldman – Ocean PEATE Manager• VIIRS Ocean Science Team

– Wayne Esaias– Barney Balch (Bigelow Lab)– Mike Behrenfeld (Oregon State U.)– Janet Campbell (U. New Hampshire)– Bob Evans (U. Miami)– Stephane Maritorena (UCSB) – Norm Nelson (UCSB)– Dave Siegel (UCSB) – Ken Voss (U. Miami)– Menghua Wang (NOAA/NESDIS)

Page 4

Ocean Team (cont.)

• VIIRS Instrument and Calibration Support– Kevin Turpie– Bob Barnes– Gene Eplee– Gerhard Meister

• Validation Support– Sean Bailey– Jeremy Werdell

• Software Support– Bryan Franz– Joel Gales

• Data System– John Wilding

• Systems Management– Paul Smith

Page 5

NASA/GSFC Ocean Biology Processing Group (OBPG) Projects

• Sea-viewing Wide Field-of-view Sensor (SeaWiFS) / Orbview-2 – active

• Moderate-resolution Imaging Spectroradiometer (MODIS) / Terra and Aqua – active

• Coastal Zone Color Scanner (CZCS) / Nimbus-7 – heritage

• Ocean Color and Temperature Scanner (OCTS) / ADEOS-I – heritage

• Glory data system prototype – 2009 launch• Aquarius / SAC-D – May 2010 launch• VIIRS / NPP – September 2009 launch

Page 6

Ocean PEATE Agenda

Land

SD3E

PSOE

Ocean

Atmosphere

Ozone

Sounder

I&TSE

NICSE

• Science Team Introductions• Ocean PEATE Design • ODPS Design Overview• Implementation Plan and


Page 7

Ocean PEATE Design

● The NPP Ocean PEATE will be implemented within the framework and facilities of the current NASA Ocean Data Processing System (ODPS)

● This system has been successfully supporting operational, satellite-based remote-sensing missions since 1996, and its capabilities continue to evolve and expand to meet the demands and challenges of future missions.

Page 8

Element Overview

• Acquire VIIRS RDRs, SDRs, and Ocean EDRs from the SD3E and ADS/CLASS

• Assess the quality of the NPP Ocean EDRs for accomplishing NASA’s climate research requirements

• Provide suggested algorithm improvements to the IDPS via the Project Science Office Element (PSOE)

• Process selected data subsets in support of Evaluation and Validation activities

Page 9

Changes since PDR

• Established interface with RSMAS (U. Miami) for SST Validation – using MODIS validation for proof of concept.

• Expanded and elaborated on xDR evaluation methodologies (as presented at July Peer Review).

Page 10

Ocean PEATE Interface Diagram

PSOESD3E

I&TSE

NICSE

VOST

CLASS(ADS)

AncillaryData

Providers

Ocean Science

Community

Casa-NOSA

xDRs, IPs, Ancillary Data

Alternate Ancillary Data

Management Direction

Calibration Updates and Evaluations

Interaction

xDR Eval. Results, Algorithm Updates

Pre-flight

Algorithms,

Data, Info

Software, Data

In Situ Data

OceanPEATE

Algorithm Updates, Test Requests &

Results

xDRs, IPs, Ancillary Data(if unavailable from SD3E)

Analysis Results, Proposed

Algorithm Updates

RSMASSeaBASS

In Situ Data

Matchups

Page 11

Ocean PEATE External Interfaces (1 of 2)

• SDS Science Data Distribution and Depository Element (SD3E)– Provides NRT access to raw data– Primary source of RDRs– Provides selected SDRs and EDRs

• SDS Integration and Test System Element (I&TSE)– Build and test updates to operational code in mini-IDPS– Run tests on selected data per request of PEATE

• Archive Distribution Segment (ADS) – Primary source for archived data

• xDRs, IPs, Ancillary Data, Operational Algorithm/Source Code and Calibration Products

• Ancillary Data Providers (ADP)– Provides alternate ancillary data sets (e.g., ozone, meteorological data sets)

• CasaNOSA– Serves as the NPP pre-flight repository of Government held data for distribution to

Government user teams– Place to acquire pre-launch NPP algorithms and supported data files

Page 12

Ocean PEATE External Interfaces (2 of 2)

• NASA VIIRS Ocean Science Team (VOST)– Coordinate activities with PEATEs and PSOE on xDR and recommended

algorithm improvements. Supports Independent Calibration Validation Activities• NPP Instrument Calibration Support Element (NICSE)

– Provides alternative calibration LUTs and recommended improvements to calibration algorithms

– PEATE provides results of LUT and algorithm tests• Project Science Office Element (PSOE)

– Provides management direction– Accepts algorithm update recommendations

• SeaBASS/ODPS– Provides Ocean Color in situ data

• RSMAS/U. Miami– Provides SST in situ locations– PEATE provides SST EDR matchups

• Ocean Science Community– Relies on Ocean PEATE to provide evaluation products and results

Page 13

Assumptions – Role of I&TSE

• The Ocean PEATE will rely upon the SDS-provided I&TSE (mini-IDPS) to serve as the testbed for algorithm evaluation and potential improvements and will not attempt to duplicate efforts by running the operational code within the PEATE environment.

• The staff of the I&TSE will have the ability to modify any operational code as per Ocean PEATE specification and run the code within the operational environment against a set of PEATE-specified test data sets.

• The I&TSE will receive and install the most current version of the code and executable programs for all operational IDPS software required to produce NASA-evaluated EDRs, starting from RDRs.

• The I&TSE will maintain all processing code under configuration control. The PEATEs will have access to the configuration controlled code.

Page 14

Ocean PEATE Support for IDPS Software

• The Ocean PEATE will maintain a working knowledge of the VIIRS SDR code and the EDR code for the Ocean Color and SST EDRs.

• The Ocean PEATE will maintain an understanding of the relevant IP characteristics, but will (initially) assume that the IPs are properly generated.

• The Ocean PEATE will design changes to the code in the I&TSE for the purpose of algorithm improvement or problem resolution.

• The Ocean PEATE will develop appropriate test cases and request runs to verify and evaluate the changes.

• The Ocean PEATE will provide recommended changes to the PSOE, including a description of the proposed change, effect on the EDR performance, and the evaluation of the test runs.

Page 15

VIIRSRDR

Previous VIIRSGridded Products

NAAPSTOD

MODISLand/Water

Mask

NCEPGeopotential

HeightAncillary

Files

DEM

NDT

AncillaryFiles


ProcessingModule

VIIRSProduct

DynamicAncillary

Data

StaticAncillary

Data

IDPS VIIRS Ocean EDR Data Flow

Page 16


VIIRS_SDR_01RDR Decompression

VIIRS_GEO_01Geolocation

VIIRS_SDR.IM375m SDR

VIIRS_SDR.MOD750m SDR

VIIRSRDR


NAAPSTOD

MODISLand/Water

Mask

NCEPGeopotential

HeightAncillary

Files

DEM

NDT

AncillaryFiles


VIIRSSDRVIIRS

SDR

VIIRSGeolocation

ProcessingModule

VIIRSProduct

DynamicAncillary

Data

StaticAncillary

Data

Page 17


VIIRS_GD_28Surface Pressure

Adjustment

VIIRS_GD_08750m Granulation

VIIRS_GD_25NAAPS Granulation

VIIRS_GD_27L/W Mask Granulation

VIIRS_GD_09GFS Granulation

VIIRS_GD_12BathymetryGranulation

VIIRS_GD_13TemperatureGranulation

ALL_GD_01Time Interpolation





VIIRSRDR


NAAPSTOD

MODISLand/Water

Mask

NCEPGeopotential

HeightAncillary

Files

DEM

NDT

AncillaryFiles


VIIRS_GD_11Ancillary Profile

VIIRSSDRVIIRS

SDR

VIIRSGeolocation

ProcessingModule

VIIRSProduct

DynamicAncillary

Data

StaticAncillary

Data

Page 18


VIIRS_LN_06Active Fires

VIIRS_CM_01Cloud Mask



Adjustment












VIIRSRDR


NAAPSTOD

MODISLand/Water

Mask

NCEPGeopotential

HeightAncillary

Files

DEM

NDT

AncillaryFiles


VIIRSSDRVIIRS

SDR

VIIRSGeolocation

ProcessingModule

VIIRSProduct

DynamicAncillary

Data

StaticAncillary

Data

Page 19

VIIRS_OC_01Ocean Color /

Chlorophyll

VIIRS_ST_02 Surface Temp

VIIRS_SN_03Ice Concentration

VIIRS_ST_01Sea SurfaceTemperature

VIIRS_AR_01Aerosol Type

VIIRS_SN_02Ice Quality

VIIRS_LN_06Active Fires

VIIRS_CL_01Cloud Optical

Properties

VIIRS_CM_01Cloud Mask



Adjustment












SSTEDR

OCCEDR

VIIRSRDR


NAAPSTOD

MODISLand/Water

Mask

NCEPGeopotential

HeightAncillary

Files

DEM

NDT

AncillaryFiles


ProcessingModule

VIIRSProduct

DynamicAncillary

Data

StaticAncillary

Data

VIIRSSDRVIIRS

SDR

VIIRSGeolocation


Page 20

ODPS MODIS Ocean Product Data Flow

ProcessingModule

MODISProduct

DynamicAncillary

Data

StaticAncillary

Data

MOD_PR01Level-0 to 1A

MOD_PR03Geolocation

MSl12Level-1B to 2

MOD_PR02Level-1A to 1B

MODISLevel-0

Land/WaterMask

PlatformATTEPH

Data

OzoneAncillary

Files

METAncillary

Data

MODIS1 km

Level-1B

MODISGeolocation

MODISLevel-1A

MODISSST

MODISOceanColor

Page 21

Evaluation vs. Product Level

• Level-1 (SDR) Evaluations– Onboard calibration analyses– Vicarious calibration

• Level-2 (EDR) Evaluations– Matchup analyses– Residual detector (striping) and scan (RVS) dependence

• Level-3 Product Evaluations– Sensor cross-comparisons– Algorithm comparisons– Temporal anomaly evaluations

Page 22

SDR Example – Vicarious Calibration

Page 23

EDR Example – Scan and Detector Dependence

Page 24

Level-3 Example – Zonal Cross-Comparisons

Page 25

Ocean PEATE Agenda

Land

SD3E

PSOE

Ocean

Atmosphere

Ozone

Sounder

I&TSE

NICSE

• Science Team Introductions• Ocean PEATE Design • ODPS Design Overview• Implementation Plan and


Page 26

ODPS Design Overview

• Fully automated, distributed data system for acquiring, processing, archiving, and distributing scientific data

• Highly scalable

• Easily adaptable to support multiple concurrent missions

• Graphical user interfaces for controlling and monitoring system functions and activity

• Non-platform specific

Page 27

ODPS Design Philosophy

• Building-Block approach• Programs are usually small and do one thing well• Programs are less complex and subsequently easy to maintain• Promotes reuse• Programs loosely coupled so testing and production can be done in the

same environment

• Adopt basic standards• ANSI, POSIX, C9x• Use existing technology when possible• Exit statuses indicate successful or failure conditions

Page 28

Components and Subsystems

DeviceManager

RDBMS

VDC/Scheduler

DataAcquisitionand Ingest

Level 3Scheduler

DataDistribution

FileMigration

andManagement

Page 29

Components and Subsystems (1 of 2)

• RDBMS is the primary element that manages all system activity

• Generic core databases support system infrastructure and non-mission-specific functions

• Mission databases catalogue products and house mission-specific data and procedures

• High level of reuse possible for similar missions; e.g., MODIS Aqua/Terra, SeaWiFS, CZCS, and OCTS are all ocean-color missions and have similar product suites and requirements

Page 30

Components and Subsystems (2 of 2)

• Relational Database Management System (RDBMS) supports all of the system components (subsystems)

• VDC/Scheduler is the primary controlling module within the system

• Other subsystems are independent modules, yet rely on the VDC/Scheduler for some their functions

• Archive Device Manager (ADM)• Data acquisition and ingest• Level-3 Scheduler• File migration and management• Data distribution

Page 31

ODPS COTS and Freeware

• Linux OS (CentOS 4.x)• Solaris OS• Sybase RDBMS• Subversion (source code management)• Pro-active DBA• Interactive Data Language (IDL)• Generic Mapping Tool (GMT)• Netpbm (graphic image toolkit)• HDF5 Library• Languages: C, PERL, SQL

Page 32

ODPS Architecture: Hardware

• Processing Servers• Intel-based dual Xeon / AMD-based dual Opteron• 8 GB RAM• Five 72 GB SCSI drives

• Storage Servers• Intel-based P4 / AMD-based single Opteron• 1 GB / 2 GB RAM• 1.5 TB IDE RAID 5 (3ware) / 9.6 TB SATA RAID 6

(Areca)• 2 hot spare drives per RAID5

• Database Server• Sun V880• 8-16 GB RAM• 6-12 70 GB SCSI HDD

Page 33

ODPS Current Components

Processing Cluster 34 processing nodes 1.5 TB

Ingest Servers2 SeaSpace ground stations

5 storage nodes11.2 TB

Distribution Servers (FTP)1 processing node6 storage nodes

25.5 TB Distribution Servers (web)1 large 3 processing nodes

63 storage nodes605 TB

Testing Cluster13 test nodes

2 TB

Network Support Systems

Database Server1 large server

876 GB

Backup Servers1 large server

876 GB2 storage nodes

11 TB

Extreme NetworksBlack Diamond 6816

Gigabit Ethernet switch

Development Servers1 processing node

2 storage nodes2.4 TB

User Desktops

Cal/Val & QC Systems

Mission Operations Systems

Page 34

Building 28 Room W220 Computing Facility

Page 35

Reliability and Redundancy

• Critical components (database server, network systems) have full maintenance contracts to ensure rapid response to problems

• Multiple-server components (ingest, processing, storage, distribution) have substantial redundancy to maintain full capability; spares maintained for rapid replacement.

• Testing nodes are separated from mainstream production components.

Page 36

Technology Refresh

• Hardware technology advances (CPU, storage) are continuously monitored to select new components for evaluation.– Typical upgrade threshold is a doubling in capacity (~18 months).– Two generations of hardware are generally in use.

• Candidate components are procured, installed in testing cluster and rigorously evaluated in a production-like environment.

• Following successful evaluation, multiple copies are procured, installed, tested and swapped in for older components.– ODPS design allows new components to be rapidly added to resource

tables without interrupting system operations.• Performance of new components is closely evaluated following

installation in operations environment.• Critical components are run in parallel with existing system to ensure

reliability under production loading.

Page 37

Ocean PEATE Agenda

Land

SD3E

PSOE

Ocean

Atmosphere

Ozone

Sounder

I&TSE

NICSE

• Science Team Introductions• Ocean PEATE Design• ODPS Design Overview• Implementation Plan and


Page 38

Ocean PEATE Gap Analysis (1 of 2)

• Acquire, ingest and catalog NPP VIIRS data products: RDRs, SDRs and Ocean EDRs (Data Acquisition & Ingest, Device Manager and File Migration and Management).– Status: Development of acquisition and ingest scripts underway

based on sample products in SD3E.• Process selected Ocean EDRs (SST and OCC) to Level-3

to support data product and algorithm evaluations (Level-3 Scheduler, VDC and Level-3 binner).– Status: Prototype Level-3 processing has been demonstrated using

sample IDPS Build 1.4 OCC and SST EDRs.• Perform VIIRS OCC EDR matchups with SeaBASS

Ocean Color in situ data (extract code).– Status: Pending completion of acquisition and ingest capabilities.

Page 39

Ocean PEATE Gap Analysis (2 of 2)

• Incorporate VIIRS SDR processing for vicarious calibration analysis. (*)– Status: Pending availability of sample SDRs in Build 1.5 format

• Produce VIIRS proxy data using VOST-developed software (VDC/Scheduler).– Status: Prototype geolocation and EDR simulation developed to

test Level-3 binning of EDRs.• Acquire SST in situ data from RSMAS and perform

matchups with SST EDRs (*)– Status: Pending final MOU

• Support browse and distribution of data products for team members (Data Distribution).– Status: Pending completion of acquisition and ingest capabilities.

(*) New PEATE capability identified since PDR

Page 40

Prototype Level-3 Processing

• EDR to Level-3 processing prototype completed using IDPS Build 1.4 EDRs.

Page 41

Existing Software Reuse

• ODPS Components– Database– VDC/Scheduler– Data Acquisition and Ingest– Level-3 Scheduler– File migration and management– Archive Device Manager– Data distribution

• Level-2 multi-mission software (vicarious calibration)• Level-3 multi-mission software (long-term trends and

comparisons• Level-2 to Level-3 comparison software (residual sensor

errors)• SeaBASS (in situ data management)• Matchup/extraction software

Page 42

Basis of Estimate (1 of 2)

• Acquire, ingest and catalog NPP VIIRS data products:– 200 LOC (combined UNIX shell, SQL, C) per new

product, for each of the four VIIRS products• Process Ocean EDRs (SST and OCC) to Level-3:

– 300 C LOC to add VIIRS Ocean EDR input to existing binning software (L2bin)

– 300 SQL LOC per temporal range (10 ranges total)– 200 shell LOC for all ranges

• Perform VIIRS EDR matchups:– 100 C LOC + 10 PERL LOC to add VIIRS Ocean EDR

input to existing extraction software

Page 43

Basis of Estimate (2 of 2)

• Process SDRs for vicarious calibration analysis:– 1000 C LOC to add VIIRS SDR input to existing

Level-2 processing software (MSl12) • Produce VIIRS proxy data:

– 100 shell LOC for each processing stage

• Support browse and distribution of data products:– 3000 C LOC to implement browse image generation– 100 PERL LOC to add VIIRS products to existing

browse and order web site

Page 44

Ocean PEATE Data Storage Estimate

Data Type Daily 1 Year 5 Years

RDR 150 GB 53.5 TB 268 TB

SDR (M-band) 242 GB(2) 8.6 TB(1,2) 43 TB(1,2)

OCC EDR 84 GB 3 TB(1) 15 TB(1)

SST EDR 19 GB 0.7 TB(1) 3.4 TB(1)

Inter. Products ~70 GB N/A N/A

Ancillary Data 0.1 GB .04 TB .2 TB

Total 565 GB 66 TB 330 TB

Assumptions: (1) Long-term storage is sized for 100% of RDRs and 10% of SDRs and EDRs(2) SDR volume includes geolocation

Page 45

New Hardware for the Ocean PEATE

• 7 Storage Servers @ 9.6 TB – first-year VIIRS data storage

• Additional servers acquired post-launch to handle years 2 – 5

• No new processing or network capacity required; technology refresh cycle to be continued within the ODPS as described.

Page 46

Ocean PEATE Build Schedule

Build 1 (L-18 months)• All interfaces fully

implemented and tested• Verify initial versions of

operational code ported and running in I&TSE

• L-3 product code developed and tested

• Prelaunch VIIRS test data storage and SDS interface testing support with existing ODPS storage capacity

• Initial test products generated for review by VIIRS Ocean Science Team

Build 2 (L-12 months)• Routine exercise of interfaces to

acquire proxy, surrogate (Aqua?) and/or simulated data

• Verify pre-launch version of operational code running in I&TSE

• Browse and distribution capability developed and tested

• Test products routinely acquired as available and posted for access by VIIRS Ocean Science Team

• Data storage for one year

Page 47

Ocean PEATE Development Schedule

Page 48

External Schedule Dates

• C3S –SDS Integration– October 2008

• IDPS – SDS Integration– October 2008

• NSIPS – SDS Integration– October 2008

• Functional Thread Test Dates– FTT8 A – Ingesting xDRs – October 2008– FTT8 B – Validating xDRs – October 2008

• NPP Compatibility Tests– NCT2C - December 2007– NCT3 - September 2008

Page 49

Ocean PEATE Testing

• ODPS Testing Philosophy:– Test as you run.– Test early, test often.

• Phased approach to testing: get one thing working and move on to the next step until entire end-to-end stream is operational.

• Testing VIIRS support to be done within operational ODPS environment, with products clearly identified for separation from operational product stream.

• Testing stages:– Interfaces– Internal functionality (processing, evaluation)– End-to-end

• Test data sources:– VIIRS proxy data– VOST simulation– MODIS products (e.g., initial SST validation)

• Availability of “official” test data is an issue.

Page 50

Ocean PEATERequirements Implementation

• 95% of requirements (19) implemented by Build 2; add additional storage capacity before launch

Requirements Met

0

1818 1919 20

0

5

10

15

20

25

Build 1 Build 2 Launch

# of

Req

s

Build 1Build 2Launch

Page 51

Sustaining Operations and Maintenance

• ODPS runs 24x7 with on-site support 8x5.• Support is shared across all projects.• Staffing needs are covered by existing OBPG

support personnel.

Page 52

Ocean PEATE Staffing Levels

VOST PEATE VOST SDS VOST SDS VOST SDSManager 0.7 0.7 0.7 0.7Sr. Sci. Prgmr/Mgr 1 1 1 1System Administrator 1 1.5 1.5 1.5Software Engineer 1.5 2 2 2Sci. Prgmr/Analyst 1.5 1.5 2 2.5Database Manager 0.5 0.5 0.5 0.5Totals 1 5.2 1 6.2 1 6.7 1 7.2Grand total

FY09 FY10 - FY14FY07 FY08

6.2 7.2 7.7 8.2

• All staffing needs will be met with existing OBPG staff• Increases will be accommodated as other projects (e.g., MODIS Aqua) wind

down.

Page 53

Documentation

• Ocean PEATE Level 4 Requirements and Operations Concept

• ICDs– SD3D to PEATEs– CLASS?

• MOU with RSMAS (TBS)• ODPS Project Data Management Plan (draft)• OCDPS Risk Management Plan• Network IT Security Plan

Page 54

Historical Milestones

• PEATE selected January 2004• PEATE Peer Review November 30, 2006 • SDS PDR September 19, 2006• EDR Evaluation Peer Review July 18, 2007

Page 55

Issues/Challenges/Concerns

• Limits of available test data– Ability to adequately test and flow data across interfaces– Verification of EDR evaluation processes

• Extent of prelaunch end-to-end (observatory & ground system) data flows

• ADS to PEATE interface• Complexity of IDPS internal processes and data flows• Version synchronization of operational products with

IDPS software in the I&TSE• Ability to diagnose software and algorithm problems in the

I&TSE• Bandwidth of NSIPS/SD3E interface

– Sole source of IPs including OBC products• Separation of spacecraft diary from science RDRs

– Requires tracking >4000 small granules/day

Page 56

Conclusion

• Ocean PEATE will meet all requirements

Next Up: Land PEATE – Ed MasuokaNPP_SDS_Land.ppt

Page 57

Backup Slides

Page 58

Ocean PEATE Level 4Requirements Allocation (1 of 2)

SDS RqmtNumber

SDS Rqmt Title Subsystem

3 Ocean PEATE N/A

3.1 Acquire RDRs, SDRs, and Ocean EDRs N/A

3.1.13.1.23.1.33.1.43.1.53.1.63.1.73.1.8

Acquire and Ingest VIIRS RDRs from SD3ESubmit Requests to SD3E for Subsets of SDRs and EDRsAcquire and Ingest SDRs and EDRs from SD3ESubmit Requests to ADS/Class for SDRs and EDRsAcquire and Ingest SDRs and EDRs from ADS/CLASSProvide Storage for RDRs, SDRs and EDRsSupport Cataloging, Searching, Ordering and Distribution

VDC/SchedulerData Acquisition & IngestFile Migration and ManagementDevice ManagerData DistributionPEATE Personnel

3.2 Assess the Quality of the NPP Products N/A

3.2.1 Assess the Quality of the Ocean EDRs N/A

3.2.1.13.2.1.23.2.1.33.2.1.43.2.1.53.2.1.63.2.1.7

Ground Truth Validation with In Situ DataCross-comparisons with Concurrent Satellite Data SetsComparisons with Climatological Data SetsAssessments of Internal ConsistencyFlagging and Masking AssessmentPrelaunch Algorithm Assessment

VDC/SchedulerLevel 3 SchedulerLevel 3 BinnerSeaBASS Matchup/Extraction Software

Page 59

Ocean PEATERequirement Allocation (2 of 2)

SDS RqmtNumber

SDS Rqmt Title Subsystem

3.2.2 Support VOST in Assessing Quality of the VIIRS SDRs N/A

3.2.2.13.2.2.23.2.2.3

Assessment of long-term radiometric stabilityAssessment of instrumental correctionsAnalysis of prelaunch test results

VDC/SchedulerLevel 2 Processing SoftwarePEATE Personnel

3.3 Provide Suggested Algorithm Improvements

3.4 Process Selected Data Subsets N/A

3.4.1 Interface with I&TSE for Processing Data PEATE Personnel

3.4.2 Acquire Processing Code from I&TSE PEATE PersonnelODPS CM

3.4.3 Acquire SDRs and EDRs from I&TSE VDC/SchedulerData Acquisition & IngestFile Migration and ManagementDevice ManagerData Distribution

Page 60

ODPS Design Details

Page 61

RDBMS

Vendor Client LibraryVendor Library Module

Database Services Layer

C Interface FunctionsPerl DBI Module

PerlScripts

CPrograms

Goal: Isolate RDBMS from system software

To use a differentRDBMS vendor, swap

in a new DatabaseServices Layer

Components and Subsystems: RDBMS

RDBMS

Page 62

VDC/Scheduler

• C program with supporting database procedures

• Runs in a daemon-like state on every processing server

• Primary system element responsible for coordinating most of the system activity

• Monitors task records in a to-do list database table

• Runs tasks according to defined task attributes

• Standard job-shell interface allows new programs to be quickly adapted as tasks for Scheduler control

Subsystems: VDC/Scheduler

Page 63

VDC/Scheduler

• Highly scalable, distributed infrastructure for concurrent processing of serial streams (e.g., L0 L1A L1B L2)

• Suite of C programs with supporting database procedures

• Uses recipes to encapsulate data-specific processing schemes, parameters, and pre-processing rules

• Virtual Processing Units (VPUs) serve as distinct distributed processing resources

• VPUs dynamically allocated based on available time and current OS load

• Comprehensive, user-defined processing priorities

Subsystems: VDC

Page 64

VDC: Ancillary Data Stager

• Runs in a daemon-like state

• Monitors entries in the processing queue and runs the rule proceduresthat are associated with the rule scheme for each recipe

• Updates queue-entry status when all rule procedures return successfully

• Governed by currently configured processing priorities

VDC: Pre-processing Rule Manager

Page 65

VDC: MakeVDC

• Selects processing-queue entries that have passed pre-processing-rule requirements

• Generates custom VDC job files from templates according to configured priorities

• Runs as a Scheduler task, so it can easily be configured to run as often as needed to keep the VDC queue full

VDC: MakeVDC

Page 66

VDC: Engine

• Function performed by the VDC/Scheduler module

• Each instance actively competes for jobs that it is allowed to run, based on priority, length of time in the queue, and user “nudges”

• Monitors and manages processing resources

• Initializes processing streams

• Invokes recipe steps and monitors step-execution time

• Handles operator-requested stream actions

VDC: Engine

Page 67

Archive Device Manager

• User defines logical pools of storage devices

• Processes request a device in a specific pool

• DM returns information for a storage device in the requested pool

• If auto-cycling is enabled, the DM time-stamps the record for the selected device, so a different device within the pool will be selected for the next request

• When a device in a pool exceeds a user-configured usage threshold, the device is no longer eligible to be selected

• Disk-monitor process polls all devices periodically to record usage statistics and invoke threshold handlers

Subsystems: Device Manager (DM)

Page 68

Data Acquisition and Ingest (1 of 2)

• Data types and sources are described in the database

• Active, passive, and periodic notification methods

• Active method scans remote systems for new files and populates the ingest queue

• Passive method waits for arrival of e-mail messages describing type and location of new file and populates the ingest queue

• Periodic method schedules transfers of files at user-specified intervals

Subsystems: Data Acquisition and Ingest

Page 69

Data Acquisition and Ingest (2 of 2)

• File transfers handled by ingest daemons and Scheduler tasks

• FTP, RCP, SCP, WGET transfer protocols supported

• Generic script handles the file transfer and then hands off to data-specific post-ingest scripts

Subsystems: Data Acquisition and Ingest

Page 70

Level-3 Scheduler

• Responsible for scheduling processing for level-3 composite products

• Runs as a Scheduler task

• Configuration is database driven

• Mission-specific stored procedures are invoked to identify input files for a composite product

Subsystems: Level-3 Scheduler

Page 71

File Migration and Management

• Responsible for compressing files and migrating them to their various destinations

• Event- or time-based actions– Ex1: compress files after they are QC’d– Ex2: remove files that are more than N days old– Ex3: mirror files upon creation

• Queries associated with each action are run periodically by a Scheduler task to select files that are eligible for some type of migratory action and populate a migration queue

• Command-line queuing for file removal and delayed copies

• Migration daemons query the migration queue, perform registered actions on the files, and update catalog tables

Subsystems: File Migration and Management

Page 72

Data Distribution

• Interactive, web-based Data Ordering System, currently supporting SeaWiFS and MODIS Aqua

• Data Subscription System, currently supporting MODIS Aqua, allows users to define region and products of interest

• Order and Subscription Manager Daemons monitor the order and subscription queues and stage files on FTP servers (stage rate ~12 GB/hr)

• Near-real-time data extraction and image support

• Web-CGI applications that allow users to view and update their orders and subscriptions

Subsystems: Data Distribution

Page 73

New Data/Source Acquisition and Ingest

• Insert DB records for new data-source servers and data types

• Compose data-specific post-ingest scripts

• Configure ingest daemons if that method is going to be used for any of the new data types

• Define archive-device pools for product storage

Page 74

New Data Product Cataloging

• Insert record into the core tables (catalog DB) that describe the mission and products

• Create mission specific database and objects, reusing objects from existing mission databases where applicable

• Compose a program to provide geographical L1 meta-data information including granule start and stop times, day-night flag, and geographic coordinates, e.g., MSl1info

• Compose functions for DB-metaload program, so meta-data files can be read and product tables can be populated

• Configure file migration and management actions for new mission data

Page 75

New Data Processing Streams

• Define a recipe for each distinct serial processing stream• Insert records for each recipe and each recipe step• Compose a job template for each recipe• Compose a ancillary-selection procedure for each recipe

that requires ancillary data• Compose scripts for each science program associated

with the new mission's data• Insert record in recipe-constraints table for each

processing host allowed to run a recipe• Compose AP-load procedure for each base data type that

can be processed with a recipe• Update the reproc program to support each base data type

that has an AP-load procedure• Configure L3-Scheduler for desired composite processing

Page 76

VIIRS Ocean Level-3 Processing

• Develop data input routines to support processing of VIIRS Ocean EDRs using existing multi-mission Level-3 binning software

Page 77

New Data Product Distribution

• Update Subscription CGI to support new mission data

• Compose match-subscription procedure

• If data extraction and mapping is to be supported:• Compose extraction and mapping programs• Compose match-XM-requests procedure• Modify XM CGI to support new mission products

• Compose browser capabilities for new mission products

• Provide FTP access to new mission products

Documents

Ocean PEATE