• Visit our Facebook page
  • Visit our Twitter feed
  •     NASA Home
  •     >    Goddard Home
  •     >    Direct Readout Laboratory
  •     >    SPAs
Click here for information on the NASA Direct Readout Conference (NDRC) Webinar

Direct Readout Laboratory

Science Processing Algorithms (SPAs)

                          SPA Wrapper
                 > Larger image (PDF Format)
             Modular Components Approach
             > Larger image (PDF Format)

                           SPA Model
                           > Larger image

                    SPA Implementation
                    > Larger image
The DRL has developed a wrapper to provide a common interface to encapsulate multi-discipline, multi-mission Science Processing Algorithms (SPAs).  The wrapper also provides a structured, standardized packaging technique for future algorithm updates that will require minimum effort.  (The DRL defines an SPA as an algorithm to which the wrapper has been applied.)  Wrappers are implemented in Java. SPAs function in a standalone environment across platforms, to serve the needs of the broad Direct Readout community in the EOS, NPP and JPSS eras. SPAs enable the DRL's Modular Components Approach (MCA) for data processing.

The wrapper is a uniform external interface on top of the underlying algorithm code (whatever that underlying code may be) that allows an arbitrary algorithm to be added to a generic processing environment.  The wrapper assumes that the algorithm code:

  • Consists of one or more executable programs that can be run from a command line.
  • Takes in one or more input data files, processes them, and emits one or more output data files.  The files are labeled with a simple symbolic type.
  • May also use other ancillary data files (e.g., Digital Elevation Model [DEM]) or dynamically generated control files (e.g., lists of input files and parameters) that can be hidden inside the wrapper.
  • Makes use of a scratch directory while running (for intermediate temporary files).

Wrappers are implemented in Java.  In order to execute an algorithm, a generic Java wrapper core reads in two Extensible Mark-up Language (XML) documents:

  • a generic document that lists the algorithm’s inputs, outputs, executables, ancillary and control files, and contains instructions for how to use them to run the code, and
  • an installation-specific document that lists exactly where the various executables and ancillary files are located on the current system.

After reading in the algorithm description documents, the wrapper core gets values for its input and output files from its environment (i.e., a list of labels and file pathnames on the command line when the wrapper system is running outside the data processing system environment).  After validating the filenames (inputs exist and are readable, outputs are writeable), the wrapper interprets the main document—generating temporary files and directories, building command lines, executing them and checking their status, copying and renaming files so inputs and outputs appear where they are supposed to appear, with the naming conventions expected by the algorithm.  After all of the executables have completed successfully, the SPA emits a labeled list of output files, suitable for passing on to other SPAs.