NAME

foting - the SAX Final Observation Tape INGestor program

SYNOPSIS

foting [parameter=value ...]

DESCRIPTION

foting is the primary program to read and decode data from SAX Narrow Field Instrument (NFI) Final Observation Tapes (FOTs) as supplied from the Scientific Data Center (SDC) and convert them into FITS format according to the specifications defined in [2].

A SAX NFI FOT is a set of individual files - either stored on tape or in a directory on a magnetic disk - which represent all the data acquired by all the NFIs during a FOT Observing Period (FOP). This is defined to be a period during which the satellite was kept pointing at the same position in the sky. In addition to the instrument-specific data a NFI FOT contains files detailing the time evolution of general satellite data (position, velocity, attitude, etc.) during the FOP and other auxiliary information. For more details on the types of files on SAX FOTs, please consult [3].

Flow of operations

The nominal flow of operations in the ingestor is the following:
1. Reading and decoding of FOT tape directory file (TAPEDIR)
   This is an ASCII file containing a list of all files the FOT consists of. A subset of this list is selected giving all relevant files which have to be processed in this ingestor run. The selection can be influenced via the command line parameter instrument.

2. Reading and decoding of ephemeris file (EPHEMERIS)
   This file should be present on every FOT and contains information about the satellite's position, velocity and other auxiliary quantities as a function of time. The data will be used to populate the EPHEMERIS extension in to be created raw HK files (see [2] for details). Should the ephemeris file be missing empty EPHEMERIS extension(s) will be generated.

3. Reading and decoding of attitude file (ATTITUDE)
   This file should be present on every FOT and contains information about the satellite's attitude as a function of time. The data will be used to populate the ASPECT extension in to be created raw HK files (see [2] for details). Should the attitude file be missing empty ASPECT extension(s) will be generated.

4. Reading and decoding of OBT-UTC file (OBT_UTC)
   All events in the instrumental science files on the FOTs are time-tagged using the 32 most significant bits of the 40 bit wide satellite clock. In order to be able to relate these On-Board-Time tags to UTCs the OBT-UTC file provides a list of OBT-UTC points at various times. This list is read and a polynomial is fitted to the data points which will subsequently be used to obtain the UTC value for an arbitrary OBT value. The fitting process and the reading of the OBT-UTC file can be controlled through several parameters all starting with obtutc (see below).
   Please note the following:
   • The reason for the existence of the OBT-UTC file and its interpretation is to account for potential drifts of the satellite clock with respect to very precise clocks on the ground. The satellite clock has, however, turned out to be very stable, and, as a result of this, the derived OBT-UTC relation is linear with slope 1 over practically all FOPs with typical durations of a few ten ksec.
     
   • The time tags in all to be created event list and HK files will be derived using the OBT-UTC relation constructed from the contents of the OBT-UTC file. It is therefore of uttermost importance, that this relation is correct, in the sense that the intrinsic precision of the event time tags of 16 us is maintained. Shall this not be the case, for instance, due to incorrect OBT-UTC data, it is recommended to alter the default values of the parameters starting with obtutc) (see below). If this does not produce satisfactory results, the decoding of the OBT-UTC file should be suppressed via the useobtutc switch.
   • All time tags in to be created FITS files are measured in seconds from the fixed mission reference time 01/01/1994 00:00:00.

5. Calculation of auxiliary ephemeris quantities
   In addition to those already present in the ephemeris file on the FOT in this phase the ingestor calculates more quantities which are to be stored corresponding columns in the EPHEMERIS extension of HK FITS files. The complete list of quantities with their respective Bintable column names is:
   1. FOV flag (FOV_FLAG):
      A flag with values 0, 1, or 2 signaling whether the satellite is pointing at the sky, the bright, or the dark earth, respectively.
   2. Earth elevation angle (EARTH_ANG):
      The angle between the satellite pointing direction and the earth's limb.
   3. Bright earth angle (BREARTH_ANG):
      The angle between the satellite pointing direction and the day-night terminator, if visible, on earth. If the satellite is pointing directly to the bright earth this value is set to -70° and if the satellite is in the shadow of the earth, this value is set to 120°.
   4. Solar elevation angle (SUN_ANG):
      The angle between the satellite pointing direction and the direction to the sun (Beta angle).
   5. Geomagnetic rigidity (COR_MIN):
      The minimum momentum in GeV/c needed by a particle of charge +1e to penetrate the earth's magnetic field down to the altitude of the satellite.

   Please note: In case of lacking information about the satellite's attitude during the FOT observing period (for instance due to the non presence of an ATTITUDE file on the FOT) the calculation of the auxiliary ephemeris quantities (AEQs) cannot be carried out. Since these quantities are utilized for event selection purposes during pipeline processing (see for instance stage III of lecspipe) their lack may result in an undesired loss of "scientifically" senseful source photons. In order to avoid this scenario foting will in case of missing attitude information calculate the AEQs on the basis of an assumed constant satellite attitude. The constant attitude values shall be derived from the "Alpha/Delta/Roll" fields in the INSTDIR file on the FOT. (see also description of parameter fakeauxqts below).

6. Reading and decoding of instrument specific files
   For each instrument selected via the instrument parameter, the ingestor is now looping over all observations performed by this instrument during the entire FOP. A single observation is defined to be the longest uninterrupted time period of stable pointing to a distinct target. Possible interruptions of stable pointing periods can be external events such as SAA passages, or changes in the instrument's configuration. For each HK and "science" file present within each observation as defined above the ingestor will create a corresponding FITS file using a naming convention described below. The mapping between types of files on the FOT and to be created FITS files is given in the following table:
   

   type of FOT file	type of FITS file	Bintable ext.	comment
   EPHEMERIS	SAXLEDAS HK [2] Multi-Bintable	3th	fully implemented
   ATTITUDE	SAXLEDAS HK [2] Multi-Bintable	4th	fully implemented
   LEHKD001 LECS Response Bus HK	SAXLEDAS HK [2] Multi-Bintable	2nd	fully implemented
   LEENG001 LECS Engineering HK	-	-	not implemented
   LEDIR001 LECS Direct Mode	SAXLEDAS Event list [2] Multi-Bintable	2nd	fully implemented
   LEIND001 LECS Indirect Mode	OGIP Spectrum [4] Multi-Bintable	1st	not yet implemented
   LEIMA001 LECS Image Mode	Standard Image [5]	0th	not yet implemented

7. If run under the control of the SAXDAS GUI scs, the program will as the very last step update the contents of the file list browser window of this tool, displaying all raw event list files that have been newly created during this ingestor run.

Error conditions and warning messages

Due to the complexity of the data on a FOT and the actions carried out by the ingestor, the number of possible error conditions is naturally large. In general, it has been attempted to make the ingestor as error tolerant as possible, which mainly pertains to potential data integrity errors in the various FOT files.
The error and warning messages issued by foting will depend on the verbosity level setting (parameter verbosity). In general, all messages should be self-explanatory, and, in case of a non-fatal error conditions, execution will be automatically resumed after corrective measures have been taken. The program will merely be abandoned if non-correctable error conditions are met. The following list is subset of the possible warning and error messages which might not be readily understandable:

General messages

• Warning: This is an old-style attitude file - no
           information on star tracker configuration is available.
           The STR_CONF column of the ATTITUDE extensions of all HK
           files will be filled with NULL values.
  

  Attitude files created before January 1997 do not contain information about the star tracker configuration that was used during the observation. Since this information is currently (01/97) not being used for data analysis purposes it is not fatal and can be ignored.

• Warning: gap of XXXX s in attitude data between records #x and #y
  

  A gap larger than the nominal data granularity of 0.5 s has been found between two consecutive attitude records. This is an unforeseen condition which could be problematic if the gap is significantly larger than a few seconds. As described above, the calculation of the auxiliary ephemeris quantities (AEQ) depends on the attitude data and, consequently, the AEQs will be incomplete in case of data gaps. Since the AEQs are used for event screening purposes in the data analysis pipeline, missing attitude data might result in the partial loss of "scientifically" useful event data. Please contact the SAX SDC and request a re-processed FOT with corrected attitude data or consider re-ingesting the FOT with the parameter fakeauxqts set to "yes".

• ReadAndDecodeAttitudeFile: Attitude record X (starting at byte position x)
           has unexpected structure."
  

  It has been found that attitude record X has not the nominal structure with respect to the number and/or type of expected data fields. This might cause the reading process to get "out of synchronization" and, in this case, lead to the loss of all attitude data after the reported record X with the potential consequences as outlined above.

• Warning: time tag of record #x is identical to previous one - ignoring this
           record.
  

  This indicates a repeated record in the attitude file which is not fatal.

• ReadAndDecodeAttitudeFile: Warning: Unexpected EOF or read error encountered "
           while reading record #X of attitude file.
  

  In most cases, this message will indicate an inconsistency between the actual number of records found in the attitude file and the size of this file as specified in the tape directory. This condition is not fatal unless the lack of attitude data will lead to the loss of event data as described in the above scenario.

• An equivalent set of warning/error messages to the above ones exists pertaining to the reading and decoding of the ephemeris file.

• Error: DoPolyFit: Routine `DPOLFIT' failed to find a polynomial of maximum
         degree X - return code is Y
  

  It has not been possible to find a polynomial fit to the OBT-UTC data with a maximum degree X which satisfies the specified RMS criterion. This is a serious condition and execution cannot continue after this point. Please refer to the above hints about the OBT-UTC data treatment in order to proceed from here.

LECS specific messages

• Error: ReadCheckSumValidationFlag: Error reading checksum validation flag
         of packet X
  

  Error: ReadPrimaryHeader: Error reading primary header of packet X
  

  Error: ReadSecondaryHeader: Error reading secondary header of packet X
  

  Error: Read_DM_TertiaryHeader: Error reading tertiary header of packet X
  

  Error: Read_DM_DataPacket: Error reading Direct Mode data packet X
  

  Error: ReadRBHK_DataPacket: Error reading HK packet X
  

  These set of errors indicate that an attempt to read a data packet from a HK or Direct Mode file has failed for either of the following reasons:
  1. An unexpected EOF has been encountered
     In this case, it is likely that the actual length of the corresponding file does not coincide with the size of this file as specified in the tape directory. Please contact the SDC about this problem.
  2. A physical read error has occured.
  3. The data in the packet or part of it were found to be invalid (corrupted, null values, etc.).
  The program will try to continue in all of the above cases, skipping the actual problematic data packet.

• Warning: null/corrupted HK packet X/Y at byte position Z
  

  Subpacket Y of HK packet X (see [3] for structure of HK data on FOT) starting at byte position Z in the FOT file was found to either consist of null or any other non-plausible data items. This condition is not fatal - the erroneous packet will be ignored and execution will continue normally.

• Warning: All HK packets X/Y-Z are invalid and have been skipped
  

  An entire, consecutive group of subpackets, viz. Y - Z, within the HK packet with sequence number X was found to be corrupted, i.e., filled with null or non-plausible data. As in the above case, this condition is not fatal. Execution will normally continue after the erroneous packets have been discarded from the packet stream.

• Error: IngestDirModeFile: No observation interval has yet been defined -
         cannot proceed
  

  A HK or science file is to be decoded but no observation directory file has been read so far. This is a fatal condition and execution cannot continue after this point. Presumably, the FOT does not contain the required FOT file OBSDIR - please contact the SDC about this problem.

• Warning: change in AE discriminator parameter XXX from packet #A to #B -
           old/new value: X/Y
  

  Between the two consecutive Direct Mode packets #A and #B, an Analogue Electronic discriminator parameter has changed its value from X to Y. This warning message is insignificant and can be ignored.

• Warning: Packets X and Y have identical sequence numbers -
           ignoring the first one
  

  The current Direct Mode packet and the following one have identical sequence numbers. This indicates that a bus conflict has occured and the second packet is the re-transmitted version of the first one. The first packet will be discarded from the packet stream and execution will continue normally.

• Warning: X packet(s) missing - sequence counters increases from
           #A to #B between packets #Y and #Z
  

  A jump in the sequence counters between two consecutive Direct Mode data packets was detected, i.e., a certain number of packets is missing. This can be the result of telemetry drop-outs or, in case of bright sources, loss of packets due to telemetry bandwidth limitations. In any case, the condition is insignificant for the decoding process. Please note that foting will create a Good Time Interval (GTI) extension in the event list FITS file corresponding to the Direct Mode file which is being decoded. In this GTI extensions, all phases of lacking data packets will be properly considered. This is necessary to enable downstream software to compute correct count rates.

• Warning: Sequence counter of packet #X is completely out of bounds -
           should be: #A, is: #B - ignoring this packet
  

  A packet with an apparently incorrect sequence counter has been found. The cause of this problem is unknown. The packet is ignored and execution will continue normally.

• Warning: Packet X is invalid and has been ignored
  

  The Direct Mode packet X has been found to contain non-sensible data and is ignored - execution will continue normally.

• Warning: time between events (A/B) and (C/D) has increased by about 64s
           (actual difference: Xs, change in OBT: 0x........ -> 0x........) -
           all subsequent time tags will be corrected
  

  and later

  Warning: time between events (E/F) and (G/H) has decreased by about 64s
           (actual difference: Ys, change in OBT: 0x........ -> 0x........) -
           this is the counterpart of a +64s jump that has occured earlier
  

  It is likely that a large number of these pairs of messages will be issued (only on verbosity level 3) during execution. The cause of the reported "+/-64s effect" is complex but understood. In brevity, it due to a combination of errors in the LECS's Electronic Unit and the FOT production software which causes the time tags of a range of events within a single or even over multiple packets to be too high by 64 seconds. foting fully corrects for this effect and the issued warning messages can be ignored.

• Warning: The absolute time difference is larger than 64s - this must not
           happen - ignoring the rest of the packet
  

  The program had detected a +64s time jump earlier and now found the time between two consecutive events to decrease. However, the absolute difference is larger than the anticipated 64s which is an illegal condition. The rest of the packet will be ignored.

• Warning: time between events (A/B) and (C/D) has decreased by Xs (change in
           OBT: 0x........ -> 0x........) - ignoring the rest of the packet
  

  This is an illegal condition which should not occur. In any case, execution will continue normally after the rest of the packet has been ignored.

• Warning: time between events (A/B) and (C/D) has increased by more than 5s
           (actual difference Xs, change in OBT: 0x........ -> 0x........)
  

  A time jump of more than 5s between two consecutive events within a packet or across a packet boundary has been found. This is an unforeseen condition and will result in the creation of a new GTI entry in the GTI extension. Apart from this, execution will continue normally.

• Warning: event (X/Y) is corrupted
  

  The data corresponding to event X in packet Y were found to be invalid, i.e., null or out of bounds. The affected event will simply be ignored and execution will continue normally. It is likely that many of these messages will be generated with event numbers close to 130, i.e., at the end of a data packet (one Direct Mode packet contains originally 133 events). This is due to an error in the FOT production software which does not properly update the event counter in the secondary header after having removed the so-called "dummy time events" from the original packet as generated by the instrument. For more detailed information about this problem see [3] and [6].

• WriteAttitudeExt: Warning: No attitude data is available - will create
                    empty attitude extension
  

  or

• WriteEphemerisExt: Warning: No ephemeris data is available - will create
                     empty ephemeris extension
  

  This warning message is issued when foting tries to create the ASPECT/EPHEMERIS extension of a HK FITS file, but no attitude/ephemeris data have previously been read. This situation can arise if the FOT does not contain complete attitude/ephemeris data or no attitude/ephemeris data at all (no file ATTITUDE/EPHEMERIS). This is not a fatal condition for the foting run but will cause problems later on since the pipeline process will need to access this data. Please contact the SDC to obtain a FOT with complete attitude/ephemeris data.

• LE_IngestExpconfFile: Warning: Unexpected EOF or read error encountered "
                        while reading record #X of experiment configuration file
  

  An experiment configuration file contains information about the LECS's nominal configuration during a particular observation period. The above message indicates that this information is not complete or not present at all on the FOT. Please contact the SDC to get a complete FOT with proper experiment configuration files.

MECS/PDS/HPGSPC specific messages

No information available at time of writing.

The above list represents only a subset of possible error/warning messages issued by foting. All other messages that might appear should be self-explanatory. If this is not the case or additional information is required, please contact the SDC.

PARAMETERS

The following command line parameters are recognized by the program:

disk = no [boolean: yes|no]

A boolean switch determining whether FOT files are to be read from disk or tape. In the former case, the indir parameter must point to a directory containing all FOT files that are to be decoded in this foting run. In tape-reading mode, the program uses a device file to access the tape drive. The name of this file can be specified via the tapedev parameter.



indir = "./" [string: valid directory name]

If FOT files are to be read from disk (disk=yes), this parameter determines the source directory under which all relevant files are expected. Note that foting always attempts to open the tape directory file as <indir>/tapedirtape_XXXXXX_00_0.dat (see below for meaning of XXXXXX). If this fails, execution will be aborted.



trimfotdir = "none" [string: name of external program]

This is a name of an external program that will be invoked by foting in case disk=yes prior to open the tape directory file. This program is supposed to "trim" the names of the FOT files in the source directory indir in case they do not follow the default naming convention:

     [ID]type[tape]_XXXXXX_YY_Z.dat

The various fields have the following meaning:

ID	- the instrument ID (e.g. le); empty (i.e. "") for non-instrument specific files
type	- file type field from tape directory, e.g. ephemeris, ledir001, ...
tape	- the word tape for "directory" files, e.g. tapedir, instdir, obsdir
XXXXXX	- the zero-padded, six-digit FOT sequence number
YY	- the observation number
Z	- i, f, n or 0 depending on type of observing period ('inital slew', 'final slew', 'normal', 'common')

foting will change into the right directory before it attempts to run the name-trimming program. No program will actually be run in case trimfotdir is given the special value "none" or no value at.



tapedev = "-" [string: valid device file name or "-"]

If FOT files shall be read from tape (disk=no), this parameter determines the tape device to be used. The special value "-" signifies to utilize an installation dependant default device (actual value can be checked with "foting help=yes"). The tapedev parameter is ignored in disk-reading mode (disk=yes).



instrument = "-" [string: "LE|ME|M1-3|HP|PD|P1-4A-C|W1|W2|**|ALL|-"]

This parameter determines which kind of instrument specific files are to be read and decoded. The permitted values for instrument are indicated above, multiple choices - separated by blank or "+" - are possible. Specifying "-" means to actually use the installation dependant default value which can be inferred through foting help=yes.



namestem = "fot" [string]

This establishes the stem of the names for event and HK FITS files that are to be created. The actual complete name of a FITS file created by foting has the form



<namestem>_<FOTID>_<InstID>_<ObsNr>_<ObsType>_<Nr>_<ID>.fits



where FOTID, InstID, ObsNr, ObsType, Nr, and ID stand for the six-digit FOT sequence number, a unique two-letter instrument ID (LE for the LECS), the observation interval number, a single-letter observing type ID (i, f, n for initial slew, final slew, and normal observing period), the running file number in the current observing period, and ID is a three-letter identification of the type of the SAXLEDAS FITS file, e.g. rev for "Raw EVent" or rhk for "Raw HouseKeeping".



outdir = "./" [string]

The name of the directory in which the output FITS files shall be created. The directory has to exist prior to run foting otherwise execution shall be aborted if the programs tries (and fails) to create a new FITS file under the specified outdir directory.



useobtutc = yes [boolean: yes|no]

This boolean switch determines if the OBT-UTC file on the FOT is to be used or not. In the latter case, the OBT-UTC file on the FOT will not be read and the OBT-UTC relation is assumed to be a perfectly linear one with slope 1 (see above on the significance of the OBT-UTC relation for the event time tags).



obtutcmaxdeg = 1 [integer: 1-10]

This is the maximum allowed degree of the OBT-UTC fit-polynomial. The degree is automatically optimized by the fitting process. Setting obtutcmaxdeg to 1 enforces the OBT-UTC relation to be linear which is the default.



obtutcfitrms = 0.00001 [real: >= 0]

The RMS to be attained in the OBT-UTC fit. It is not recommended to use higher values than 0.00001.



obtutcblocknr = 1 [integer: >= 0]

The OBT-UTC data points in the OBT-UTC file on the FOT are grouped into blocks of 8-10 with consecutive points within the same block being 1 min. apart in time. The temporal distance between two consecutive blocks is about 94 min., the satellite's orbital period. Analyses have shown that if one considers all points in all blocks the fitting process fails to find a polynomial with a RMS better than 1.E-5 which is needed to maintain the intrinsic precision of the event time tags of 16 us. Taking only one particular OBT-UTC block into account gives a satisfactory result and the obtutcblocknr parameter controls which block is to be used. The special value 0 means to consider all blocks in the fit (which will give unsatisfactory results). Specifying a number larger than the number of blocks available will result in usage of the very last block. The default is to use the very first block of OBT-UTC data points.



obtutcplot = no [boolean: yes|no]

A boolean switch to control the creation of a plot showing the relation between the satellite clock (OBT) and UTC expressed in seconds since the fixed mission reference time 01/01/94 00:00:00 (TAI - 28s). This relation is the result of a least-square fit of a polynomial with maximum degree obtutcmaxdeg to the distinct OBT-UTC data points from the OBT_UTC file on the FOT. After the plot is displayed the user shall be prompted for a confirmation to proceed with the current OBT-UTC relation.



plotdev = "/xwin" [string: a valid PGPLOT device]

The plotting device to be used to create the OBT-UTC plot. All devices supported by the FTOOLS PGPLOT library can be specified.



ranom/decnom = "-" [string]

The values to be assigned to the FITS header keywords RA_OBJ and DEC_OBJ respectively, which are supposed to contain the true equatorial coordinates (Right Ascension and Declination) of the observed celestial target. If both ranom and decnom are specified as "-" the program will attempt to extract the actual values from the comment field of the first tape directory record, and, if this fails, from the "Alpha/Delta"-fields in the instrument directory on the FOT. Please note that NFI FOTs produced before January 1997 do not contain the true source coordinates in the tape directory and the "Alpha/Delta"-fields in the instrument directory represent the satellite pointing direction at the beginning of the observation which can deviate from the true source position by several arcmins (worst case). The modules baryconv and evelin interpret the RA_OBJ/DEC_OBJ keyword values as the true source coordinates to calculate barycentric times and event sky coordinates respectively.

In order to avoid undesired effects due to erroneous source coordinates it is recommended to provide the right values through ranom and decnom in case the FOT does not contain this information.

A corresponding warning message is issued by foting if the true source coordinates have not been read from the tape directory.
ranom and decnom can either be specified in decimal degrees, e.g., ranom=236.1324343, decnom=-45.244343 or in the conventional astronomical form ranom=15h44m31.8s, decnom=-45o14'40".



origin = "-" [string]

Value of FITS header keyword ORIGIN. "-" means to use an installation dependant default value - foting help=yes shows this default value.



obs_mode = "-" [string: "POINTING|SLEW|CALIBRATION|-"]

Value of FITS header keyword OBS_MODE. "-" means to determine the value from corresponding information on the FOT.



observer = "-" [string]

Value of FITS header keyword OBSERVER. "-" means to determine the value from corresponding information on the FOT.



obs_no = 1 [integer: >=1]

Value of FITS header keyword OBS_NO. Default is 1.



xreverse/yreverse = no [boolean: yes|no]

Switch to trigger the mirroring of X/Y event detection coordinates. Default is "no".



sub3 = yes [boolean: yes|no]

This parameter is only of relevance for LECS Direct Mode data. Due to distinct circumstances, the X/Y detection coordinates, the PHA and VETO signal are reported with a value 3 too high by the LECS's electronic unit. Setting sub3 equal to "yes" (the default) compensates for this effect and produces correct event data. Altering the default value is strongly discouraged and reserved for expert users.



hkscience = no [boolean: yes|no]

Under certain circumstances instrumental HK data are being generated even if no "science task", is enabled, i.e., the instrument(s) do not produce scientifically senseful data. The hkscience switch determines whether HK data acquired during such intervals shall be decoded or not. Setting it to "yes" requests to decode only HK data if a science task was active which will potentially reduce the size of to be generated HK FITS files considerably. Please note that the SAXDAS pipeline software will not make use of any HK information during "non-science" task intervals, thus, changing the value to "yes" will have no impact on the data analysis process.



nohk = no [boolean: yes|no]

If set to yes, the generation of HK FITS files is suppressed. Default is "no".



fakeauxqts = no [boolean: yes|no]

As described above, in case of lacking information about the satellite's attitude, i.e., a missing ATTITUDE file, the calculation of the auxiliary ephemeris quantities is performed assuming a constant satellite attitude over the entire FOT observing period. If fakeauxqts is set to "yes" this behavior is also enforced in case the ATTITUDE file is present. This can be desirable if the data in the ATTITUDE file is known to be of "poor" quality or to contain gaps which would lead to corresponding gaps in the auxiliary quantities with the above described consequences.



verbosity = 2 [integer: 0|1|2|3]

Specifies the program verbosity level, i.e. the amount of screen output that will be issued during program execution. Level 0 means "mute", only fatal error messages will be printed. Verbosity level 3 results into detailed diagnostic messages. Default is level 2.



help = no [boolean: yes|no]

Display a brief on-screen description of all available command line parameters with default values and the current program version number.

EXAMPLES

1. Process all files related to the SAX LECS and MECS instrument on the current FOT. The FOT is available in the form of a tape loaded in the tape drive /dev/rst1. The creation of FITS HK files shall be suppressed:

      foting instrument=LE+ME tapedev=/dev/rst1 nohk=yes
   

2. Read all LECS specific FOT files from a disk directory /fot and create all resulting FITS output files in user's home directory

      foting disk=yes indir=/fot outdir=$HOME instrument=LE
   

3. Process all files from all instruments on a tape FOT loaded in the default tape device (which is hard-coded in the program). All FITS files are to be created in the current directory:

      foting instrument=ALL
   

FURTHER DOCUMENTATION

1. The SAX LECS Data Analysis System - Software User Manual,
   U. Lammers, Doc. SAX/LEDA/0010
2. The SAX LECS Data Analysis System - Software User Manual, Chapter 2,
   U. Lammers, Doc. SAX/LEDA/0010
3. MSC FOT Layout Document - User Manual, Telespazio, Doc. TPZ/GO.SDC-100/FOT-TN/SAX
4. The OGIP Spectral File Format, OGIP Memo 92-007 + Addendum
5. General documentation about FITS (http://www.gsfc.nasa.gov/astro/fits/fits_home.html)
6. SAX LEGSPC User Manual, Arvind Parmar,Doc. SX-UM-ES-001

BUGS

• For the LECS, merely the decoding of Direct Mode science and HK files is supported (no Indirect and Image Mode).
• The decoding of satellite HK files is not supported.
• Due to the fact that the ATTITUDE and EPHEMERIS files on the FOT are in ASCII format and several Mb in size, the reading and decoding of this information is relatively slow.

SEE ALSO

teleing