Anatomy of a SURF task

Surf tasks follow the same general format internally:

(1): Request the messaging level from the parameter system (MSG_LEVEL).
(2): Read in some information concerning the object name, observation mode and run number and write this to the screen (at normal messaging level) to keep the user informed.
(3): Check the history component to make sure that the correct tasks have been run prior to running the current task. This always contains a check to see that the reduce_switch task has been run on the data.
(4): Check the dimensions of the data array, the LST_STRT array and the DEM_PNTR arrays.
(5): Retrieve information from NDF extensions (see e.g. SCULIB_GET_BOL_DESC, SCULIB_GET_JIGGLE). [as required]
(6): If required, construct an output name based on the input filename (SCULIB_CONSTRUCT_OUT). The output file is usually propogated from the input file using NDF_PROP.
(7): Do whatever has to be done.
(8): Shut down NDF, free memory, free locators.