For true FITS, keywords must be in capitals. Permitted characters are 'A' - 'Z', '0' - '9', '+', '-', '_'. FITS uses 7-bit ASCII for character parameters.
The FITS standard also notes that: "The units of all FITS header keyword values should conform with the recommendations of the IAU Style Manual at nccs/doc/IAUunits.txt.
For a full definition of FITS, see the FITS standard at /usr/local/src/fits_standard.ps. Also available in printed form.
For more information on FITS and CFITSIO, refer to the NCCS index.
Logical description of file format, T if file conforms to FITS standard, otherwise F. (standard FITS, must be first keyword in HDU)
Number of bits per pixel in a FITS data structure. Values are:
Number of axes in the primary data array. (standard FITS, must be third keyword). This is zero if the data are in a binary table rather than in the primary data array.
Number of values on the nth axis of the data array, if present. (standard FITS, must be fourth... keyword)
Optional. FITS dataset may contain extensions, T if true, F if false. Must be present if a binary table is used. (standard FITS)
Date of creation of this HDU (FITS header and data unit). Y2K-compliant date FITS date format is 1999-03-17T13:54:17.321. If the keyword TIMESYS is not present, the time system is assumed to be UTC. IAU recommends the use of Terrestrial Time, TT. (standard FITS)
End of keyword list. (standard FITS, must be last keyword in HDU)
Name of object. (standard FITS)
Equinox in years applicable to equatorial coordinates, e.g. 1950.0 for B1950, 2000.0 for J2000. (standard FITS)
For further discussion, see Representations of celestial coordinates in FITS, of 1996/09/09, by E W Greisen and M Calabretta, in /usr/local/src/fits/wcs.all.ps
Frame of reference for an equatorial coordinate system. (Recommended keyword by Greisen and Calabretta, WCS for FITS) Allowed values are:
Object's RA of EQUINOX in decimal degrees.
Object's Dec. of EQUINOX in decimal degrees.
Galactic Longitude of object in decimal degrees. (Recommended keyword in WCS for FITS)
Galactic Latitude of object in decimal degrees. (Recommended keyword in WCS for FITS)
Ecliptic Longitude of object in decimal degrees. (Recommended keyword in WCS for FITS)
Ecliptic latitude of object in decimal degrees. (Recommended keyword in WCS for FITS)
If the object is a calibrator, this is its flux density at RESTFREQ, computed from the catalogue information, in Jy.
Reference or source of information. (standard FITS)
Principal Investigator's (Observer's) name. (standard FITS)
On-site observer if PI not on site.
Mandatory. Short name for the observing project, taken from the observing proposal. Specified in section 6.10 of the "NCCS Requirements and Specifications".
Mandatory. Number of the observing proposal, allocated on acceptance of the observing proposal. Specified in section 6.10 of the "NCCS Requirements and Specifications".
Telescope name. (standard FITS)
Date of observation. Y2K-compliant FITS date format is '1999-03-17T13:54:17.123'. See notes on DATE. This is conventionally defined to indicate the start of the observation. (standard FITS)
Modified Julian Date (= JD - 2400000.5) of start of SCAN. The number of significant figures used must define the start time to the required accuracy for data reduction purposes. For example, five decimal places defines time to about one second, six to one-tenth of a second etc. What accuracy is needed for pulsars? MJD-OBS is strictly redundant in that it can be calculated from DATE-OBS, but "nice to have", recommended for working with time series of data, and avoids post-observation recalculation. (recommended by Greisen and Calabretta, in WCS for FITS.)
Scan or observation number or alphanumeric designator uniquely identifying this scan.
Type of scan.
Observing frequency or Line rest frequency (spectroscopy) in Hz.
Hour angle recorded at either the start, middle, or end of SCAN in degrees. Used for calculation of atmospheric absorption and gain corrections, where the middle of the scan is usually the most appropriate. Strictly redundant in that the HA can be calculated from the RA and DATE-OBS or JULDATE, but "nice to have", avoiding post-observation recalculation.
Telescope altitude (elevation) in degrees at the middle of the observation, computed from HA and DEC. Used in the correction for atmospheric absorption. Strictly redundant in that the ALT can be calculated from the RA and DATE-OBS or JULDATE, but "nice to have", avoiding post-observation recalculation.
All observers conducting monitoring programs have in the past been bedevilled by undocumented changes in receiver hardware that affect the recorded data. All parameters relevant to observing are now meant to be recorded in SYPARM. Those relevant to the receiver system with which the data were captured can then be defined by suitable keywords. Hardware changes can then be identified post facto through changes in the parameters taken by keywords, instead of by trying to find records of changes in control room diaries.
The following keywords should provide a reasonably complete description of the factors that have the most effect on observations.
Antenna surface status, needed given resurfacing "in process". This is descriptive, e.g. "PANELS 001-0038 REPLACED, PANEL 039 MISSING". From SYPARM. The effect of changes in the surface can be quantified as a (frequency-dependent) gain factor using the keyword GAINFAC.
Gain of the telescope at zenith relative to that before the surface upgrade started. From SYPARM. Theoretically, calibrators should be observed after each surface change and these most recent calibrations applied to the data, making use of this keyword unneccessary. Real life may be a little different.
Subreflector tilt position during the scan. Units are natural readout values - or converted to a real angle in degrees ? Confirms that the subreflector was where it should have been. From STEER.
Subreflector focus position during the scan. Units are natural readout values - or converted to a proper unit of length, i.e. (milli)metres ? Confirms that the subreflector was where it should have been. From STEER.
Dichroic reflector position, either ON or OFF, during the scan. If the dichroic is on, system temperature and aperture efficiency (usually recorded in the reciprocal form of the Point Source Sensitivity in Jy/K) will change. Default measurements are with the dichroic off. From STEER.
Feed horn type, e.g. RECTANGULAR, CIRCULAR, or DIAGONAL. Each type has different efficiencies and bandwidths. From SYPARM.
Beam offset from axis in Hour Angle used for the observation, in units of degrees. Repositioning of feeds will change the PSS and gain surface. From SYPARM.
Beam offset from axis in Declination used for the observation, in units of degrees. Repositioning of feeds will change the PSS and gain surface. From SYPARM.
Beam separation in dual beam systems, in degrees. From SYPARM.
Half-power beamwidth (full width at half maximum), in degrees. Necessary for reducing pointing observations. Confirms offsets used for stepping observations. From SYPARM.
Beamwidth to first nulls, in degrees. Confirms offsets used for stepping observations. From SYPARM.
Beamwidth to second nulls, in degrees. Confirms offsets used for stepping observations. From SYPARM.
High frequency end of detected band at the 3dB (6dB? 10dB?) point, in Hz. The RESTFREQ used for the observation may not be centred in the detected band, so this parameter is needed to define the band centre frequency for calibration purposes. RFBANDHI - RFBANDLO should give BW, the effective bandwidth, in Hz. From local oscillator settings and data in SYPARM.
Low frequency end of detected band at the 3dB (6dB? 10dB?), in Hz. The RESTFREQ used for the observation may not be centred in the detected band, so this parameter is needed to define the band centre frequency for calibration purposes. From local oscillator settings and data in SYPARM.
Nominal minimum system temperature at zenith, in K. Useful for checks on system performance, such as the noise level in the data. From SYPARM.
Describes the instrument or backend and mode used to acquire the data. From input file. (Standard FITS)
Polarization of each receiver channel. The FITS standard does not specify how the polarization of data should be recorded. A standard will have to be defined - see examples for possibilities. From SYPARM or input file if selectable.
Adopted numerical value of the calibration signal from the calibration noise diode. As two polarizations are recorded in general, TCAL1 and TCAL2 will be needed, one for each polarization. TCAL would normally have been determined by a hot-cold load measurement. Frequency-dependent. From SYPARM.
Uncertainty in the adopted numerical value of the calibration signal from the calibration noise diode. A value is needed for reach polarization. From SYPARM.
Frequency at which the adopted numerical value of the calibration signal was measured, in Hz. From SYPARM.
Date at which the numerical value of the calibration signal given by TCAL was adopted. From SYPARM.
Calibration signal units, analogous to BUNIT, e.g. 'K'. From SYPARM.
Counts per Kelvin from noise diode calibration signal, for each receiver channel. Used to calibrate data recorded in raw form. From noise diode firing during this scan.
Uncertainty (1 standard deviation) in counts per Kelvin from noise diode calibration signal, for each receiver channel. From noise diode firing during this scan.
Point Source Sensitivity derived from observations of standard calibrator source(s). Units are Jy/K. Used to rescale data from antenna temperature to flux density. The values may differ in the two polarizations observed. From SYPARM.
Uncertainty in Point Source Sensitivity derived from observations of standard calibrator source(s). Units are Jy/K. From SYPARM.
Name of flux calibrator used to measure the PSS. From SYPARM.
Frequency at which the flux calibration was made, in Hz. From SYPARM.
Calibrator flux density assumed at the time of calibration, in Jy. From SYPARM.
Date of flux calibration. From SYPARM.
Really serious observers may want to record the following parameters of the calibration noise diodes:
Stepping data are to be recorded as sets of tracking data. If all the tracks are of equal length, counting the track with calibration as a double track, then the data can be packed into one dimension of an array and decoded using the set of mnemonics defined by STEPSEQ. Alternatively, the data could be recorded in multiple dimensions of an array, permitting unequal length steps. See comments with the example.
Sequence of steps performed. Used to interpret the data sequence. Optional description of stepping observations. From input file, otherwise from standard sequence list. For data recorded in a binary table, TTYPn includes the acronym for each step and the polarization.
For example if STEPSEQ followed TNFPC dual beam:
FNNACAL, HPNA, ONA, HPSA, FNSA, ZC, FNNB, HPNB, ONB, HPSB, FNSBthere would be a double track at the start, followed by ten single tracks, giving a total of twelve tracks. Recording the data for each polarization, this gives 24 data fields.
These are taken directly from the input file keywords.
x offset from special point of scan start. Units are decimal degrees.
y offset from special point of scan start. Units are decimal degrees.
x offset from special point of scan end. Units are decimal degrees.
y offset from special point of scan end. Units are decimal degrees.
Length of scan in seconds.
The ATNF multibeam correlator used on the NCCS provides for dual input signals (usually left- and right-circularly polarized). It therefore outputs two spectra, one for each input channel. In addition, it can be configured to give the Stokes IQUV parameters of the signal. Hence we may have either 1 (for a single-polarization receiver), 2 or 6 data outputs for each spectrum.
In spectroscopic observations, the final spectrum comprises the difference between a pair of spectra taken with either a frequency offset or a position offset for the second. On the HP1000, only this difference spectrum was recorded. On the NCCS we want to record both the original components. This will again double the amount of data to be recorded, as each output file will normally contain both sets of spectra, and Stokes parameters when configured for that.
If we want to permit the use of a single reference spectrum that can be used with many on-source spectra, we will have to allow the possibility that there will not be a pair of data sets, only the on-source one.
To further complicate matters, in order to check the pointing error during spectroscopy, spectra may be taken at the half-power points of the beam before observing the on-source position. If frequency-switching is being used, the first spectrum of the pair is taken offset HPBW North (or East) and the second is taken offset HPBW South (or West). One therefore gets a series of spectra taken at these positions:
To simplify post observing data reduction, these offsets need to be recorded in the housekeeping by a keyword taking designators like those used above.
On the HP1000, calibration of the spectra was done once, at the end of the first spectrum of the pair. On the NCCS we will calibrate each spectrum independently, at the end of each spectrum. This will better allow for the effects of position- and frequency-shifting in getting accurately calibrated spectra.
External usage:
Device and Log FITS Files for the GBT by Richard M. and Prestage Mark H. Clark, in http://www.gb.nrao.edu/GBT/MC/doc/dataproc/gbtFits/gbtFits/gbtFits.html
Representations of spectral coordinates in FITS by Griesen and Valdes, in http://www.aoc.nrao.edu/ egreisen/inFITS.html
FITS Keywords for DSN Radio Spectroscopy by Tom Kuiper, in http://dsnra.jpl.nasa.gov/devel/fits/keywords_dsn.html
Standard FITS Keywords by Tom Kuiper, in http://dsnra.jpl.nasa.gov/devel/fits/keywords_dsn.html
The GBT autocorrelation spectrometer, in http://www.gb.nrao.edu/GBT/MC/gbt/devices/backends/spectrometer/docs/ with links to FITS format outputs.
Using Dish : The AIPS++ Single Dish Analysis Environment by R. W. Garwood, J. P. McMullin, in http://aips2.nrao.edu/released/docs/notes/225/225.html. This shows how single dish spectra are reduced in AIPS++, and on the SDFITS file format. These have implications for how we write the data files for maximum compatibility.
SPC by Mark Calabretta, in http://www.atnf.csiro.au/computing/software/spc.html is a Spectral Line Reduction Package used for reducing spectral line data from the Parkes and Mopra radiotelescopes. It also reads and writes SDFITS files.
Naive first attempt at keywords for spectroscopy:
Spectroscopy only. RA of EQUINOX for "up" spectrum. Relevant to offset spectra used to measure the pointing, where RAUP = RA of date +(HPBW/2)/COS(DEC) for spectrum offset East. If not specified in the housekeeping, RAUP = RA of object.
Spectroscopy only. Dec of EQUINOX for "up" spectrum. Relevant to offset spectra used to measure the pointing, where DECUP = DEC of date +HPBW/2 for the spectrum offset North. If not specified in the housekeeping, DECUP = DEC of object.
Spectroscopy only. RA of EQUINOX for "down" spectrum.
For frequency-switched spectra, RADOWN = RA of object.
For frequency-switched spectra used to measure the pointing, RADOWN = RA of date -(HPBW/2)/COS(DEC) for spectrum offset West. HPBW is from SYPARM.
For position-switched spectra, RADOWN = RA + RA offset calculated from the SPPS parameters in the input file.
If not specified in the housekeeping, RADOWN = RA of object.
Spectroscopy only. Dec of EQUINOX for "down" spectrum.
For frequency-switched spectra, DECDOWN = DEC of object.
For frequency-switched spectra used to measure the pointing, DECDOWN = DEC of date -HPBW/2 for spectrum offset South. HPBW is from SYPARM.
For position-switched spectra, DECDOWN = DEC + DEC offset calculated from the SPPS parameters in the input file.
If not specified in the housekeeping, DECDOWN = DEC of object.
Spectroscopy only. Galactic longitude of "up" posn. Optional, derived from RAUP, DECUP, EQUINOX.
Spectroscopy only. Galactic latitude of "up" posn. Optional, derived from RAUP, DECUP, EQUINOX.
Spectroscopy only. Galactic longitude of "down" posn. Optional, derived from RADOWN, DECDOWN, EQUINOX.
Spectroscopy only. Galactic latitude of "down" posn. Optional, derived from RADOWN, DECDOWN, EQUINOX.
Spectroscopy only. Optional. Used for spectra of galactic objects. Parameter is the velocity with respect to the local standard of rest at which the spectrum was centred. Units are km/s. An alternative parameter will be used for solar system objects such as comets, e.g. SPVHEL.
Spectroscopy only (?). Measured system temperature at the middle of the SCAN in TCALUNITS. Used to scale the spectrum and to calculate RMS.
Spectroscopy only (?). Measured uncertainty in TSYS in TCALUNITS.
Spectroscopy only (?). Duration, or total integration time, of SCAN in seconds. Must be known if RMS is to be calculated.
Spectroscopy only (?). Bandwidth of the detected signal in Hz. Must be known if RMS is to be calculated.
Spectroscopy only. Frequency offset for frequency-switched spectra, in Hz.
Spectroscopy only (?). Expected rms noise of the data in BUNITS. Calculated using the radiometer sensitivity equation.
Spectroscopy only. Frequency-shifted spectra are "shifted and folded" to superimpose and add the data in the two halves of the spectra. This keyword indicates whether this has been done. FOLDED =0 unfolded, =1 folded.
Spectroscopy only. Indicates whether the data in the array are in their natural form or have been Fourier-transformed. TRANSFORM=0 spectrum, =1 transform.
At the moment, the analysis of pulsar data recorded on the HP1000 requires the source catalogue to be present to provide the requisite housekeeping information. I suggest that this housekeeping information accompany each pulsar timing observation so that the analysis can be done independently of the source catalogue. This provides a definitive record of the actual parameters used at the time of observation, and makes the data portable.
The pulsar period in seconds. From the input file or catalogue.
The pulsar period derivative, in s/s^1. Also known as "pdot". From the input file or catalogue.
The pulsar period second derivative, in s/s^2. Also known as "pdotdot". From the input file or catalogue.
The dispersion measure, in units of pc/cm^3. From the input file or catalogue.
The rate of change of the dispersion measure with time, in units of pc/cm^3/s^1. From the input file or catalogue.
The epoch in Julian days (MJD?) applicable to PLPERIOD, PLPDRV1, PLPDRV2, PLDM and PLDMDRV. From the input file or catalogue.
A numerical factor to do with polarization, does what? If PLPOL is omitted, the default value is unity. From the input file or catalogue.
The phase offset from current ephemeris at the time of the most recent observation, in milliperiods. Also known as the "drift". From the input file or catalogue.
The time constant that was set for the post-detection filter, from the input file, in microseconds. From the input file or catalogue.
The number of periods that were integrated. From the input file or catalogue.
Computed current period at epoch of observation, at solar system barycentre (seconds). From the observing program. The nominal time interval between each data point = PLPBARY / number of samples.
Computed period at epoch of observation corrected for radial velocity doppler shift (seconds). From the observing program. The actual time interval between each data point = PLPAPP / number of samples.
Sampling frequency that was used (= Nsamples / Papparent, i.e. = NAXIS2 / PLPAPP), in Hz. From the observing program.
If data are to be stored in true FITS format, certain keywords are mandatory. Others may have to be added to make explicit the nature of the data, as FITS is rather minimalist.
In general the data acquired in single dish observing comprise data streams or sets from the left- and right-circularly polarized receivers. In the case of spectra or a polarimeter, this could alternatively be linearly polarized at some polarization angle or could be the Stokes parameters. Additional data streams might include the RA, Dec or pointing errors. The data may be in various forms eg integer or real, with different degrees of precision.
The best way to handle these multiple data streams in the FITS style is with either an ASCII or binary table. At first sight it might seem that an ASCII table could be imported easily into a spreadsheet, but this is not so, as it is actually a byte-stream stored in 2880-byte blocks. The more compact binary table therefore seems the preferred option for recording the data.
An advantage of the using the primary data array is the coordinates of evenly spaced data are identified very compactly using CRVALn, CRPIXn and CDELTn. In binary tables however, the coordinates are specified as another data field. This is less compact, but does cope automatically with unevenly spaced data.
The keywords in this section cover the primary data array, if used. The keywords for data in a binary table are in the following section.
Physical units in which the quantities of the primary data array are expressed. (standard FITS). The examples quoted in the original FITS papers are 'K' or 'Jy'. However this is ambiguous, as 'K' could be either antenna or brightness temperature, for example. If raw data are recorded, the units are instrumental, e.g. 'COUNTS'.
I suggest the use of BTYPE to specify the quantity, and BUNIT to specify the units unambiguously, following the example of TTYPn and TUNITn specified in the FITS standard for binary tables.
Owing to the deficiencies of the BUNIT specifier, BTYPE is used to define the type of data in the primary data array. For instance, 'RAW DATA' are just that. Alternatives are 'ANTENNA TEMPERATURE', 'BRIGHTNESS TEMPERATURE' and 'FLUX DENSITY', or abbreviated forms of them.
Name of the coordinate represented by axis n. (standard FITS)
Note that the units can be embedded in CTYPEn, but if they are not they may be ambiguous. This can be a problem. I would be happier if the units were explicitly stated in the keyword, or in another keyword such as CUNIT1. We will need to set local internal standards.
For spatial data, examples in FITS documentation are 'RA', 'DEC' are used for equatorial coordinates, i.e. Right Ascension and Declination, 'GLON', 'GLAT' for Galactic Longitude and Latitude, 'ELON', 'ELAT' for Ecliptic Longitude and Latitude. Units are always degrees for all these.
For spectroscopy, examples given in the original FITS paper are 'VELO' for velocity in meters/second, 'VELO-LSR' for the velocity with respect to the local standard of rest, with units unspecified, VELO-HEL' for heliocentric velocity (wrt the Sun), 'VELO-OBS' for velocity wrt the observer. I used 'VELO-LSR KM/S', for Vlsr from the HP to make the units explicit, the SI units for velocity being m/s.
For pulsar timing, the units appear to be the fractional period, with a random start phase.
Units for the coordinate of axis n.
Value at the coordinate specified by CTYPEn at CRPIXn. The data are always regarded as being evenly spaced. CRVALn, CRPIXn and CDELTn together define how to set up the abscissae for the data. (standard FITS)
Location of reference point for CRVALn on axis CTYPEn, pixels being numbered 1,2,3...n. Typically the first pixel (1) is used. (standard FITS)
Pixel spacing on NAXISn. (standard FITS)
The first seven keywords must be in the order described, with no intervening keywords. I have not listed every possible keyword, see the FITS standard for more information.
In the examples, in the interests of transparency I have used a separate field for every variable being recorded in the table, in order to make explicit where LCP and RCP data are stored. However it is quite possible to have multiple data (of the same type) per field, such as pairs LCP and RCP data values. The binary table example in the previous version of the FITS standard (NOST 100-1.1), pp 47-49 does this. The absence of such examples from the latest FITS standard does not help :-(
Mandatory. Value field (parameter) must be = 'BINTABLE'. (standard FITS)
Mandatory. Value field must be 8, indicating an array of 8-bit bytes. (standard FITS)
Mandatory. Value field must be 2, indicating that the array is two-dimensional: rows and columns. (standard FITS)
Mandatory. Value field gives the number of 8-bit bytes in each row of the table. This is the sum of the bytes per field. (standard FITS)
Mandatory. Value field gives the number of rows in the table. (standard FITS)
Mandatory. Value field gives the number of bytes that follow the table in any associated extension data. (standard FITS)
Mandatory. Value field contains the integer 1, indicating that the data records contain a single table. (standard FITS)
Mandatory. Value field is an integer giving the number of fields in each row. (standard FITS)
Mandatory. Value field of the keyword is a character string of the form rT describing the nth field in the table. The repeat count r is an integer specifying the number of elements in field n, default value is 1. (standard FITS). Some examples of the data type T are:
Optional. Character string giving the name or description of the nth field. Only letters, digits and '_' should be used. Use different names for each field. (standard FITS)
Optional. Character string describing the physical units in which the quantity in field n is expressed, as per BUNIT. (standard FITS)
Optional. Integer that represents an undefined value for data of type B, I or J. (standard FITS)
Optional. Floating point number giving the scale factor for field n. Default value = 1. Physical_value_n = TZEROn + TSCALn * field_value_n. (standard FITS)
Optional. Floating point number giving the zero level for field n. Default value = 0. (standard FITS)
Optional. Character string describing the format for the display of the contents of field n. (standard FITS) Some examples are:
Ends the keywords defining this extension. (standard FITS)
This is followed, at the start of the next FITS record, by the binary data table, comprising a two-dimensional byte array. The number of bytes in a row and the number of rows determines the size of the byte array. Every row shall have the same number of bytes. The first row begins at the start of the record immediately following the last header record.
The following data processes can be applied to each data channel individually, hence they may need a suffix (e.g. 1 or 2) to indicate the channel to which they have been applied.
Atmospheric attenuation correction that has been applied to the amplitude of the data. The SLAP formula is used:
ABSORB = 1D0 / DEXP(0.0069D0*(1D0/DSIN(ALTRAD)-1D0))A value of zero or unity indicates no correction has been applied.
Pointing correction that has been applied to the amplitude of the data. The pointing correction is calculated from data obtained on the object, or a nearby object, on source and at the N,S,E,W half-power points of the beam (typically). A value of zero or unity indicates no correction has been applied.
Antenna gain correction that has been applied to the amplitude of the data. This is derived from a gain surface or gain curve, and is a function of HA,Dec. Care should be taken as to whether this includes or excludes atmospheric absorption. A value of zero or unity indicates no correction has been applied. GAINCORR defines the change in gain of the antenna at the observing position relative to that at zenith.
Point Source Sensitivity factor in Jy/K that has been used to convert the data from antenna temperature to flux density. It is derived from flux calibrator observations, and is essentially the reciprocal of the aperture efficiency. Set to zero if data have not been converted from Ta/K to S/Jy. Proper usage of this conversion implies that the atmospheric, pointing and gain corrections have been made.
Number of compatible data sets that have been averaged to produce the current data. Applicable to spectra and drift scans for example. Default is 1 if not specified.
First valid pixel in the data. Applicable to one-dimensional data which may be "windowed", such as spectra and drift scans, where data outside the window are not necessarily discarded. Default is first pixel, if not specified.
Last valid pixel in the data, with notes as above. Default is last pixel, if not specified.
Spectroscopy and drift scans. Order of polynomial that has been fitted to the spectrum baseline. Used in spectroscopy, may be used elsewhere.
Indicates whether a smoothing operation has been applied to the data array. SMOOTHD =0 unsmoothed =1 smoothed. Used in spectroscopy, may be used elsewhere.