This parameter specifies the names of 1-25 input EDR files, containing the data from which the cube will be generated. NIMS EDR files can be obtained from the PDS imaging node, as follows (as of 19 June 2008): 1. Go to http://www-pdsimage.jpl.nasa.gov/resources/onlineData.html 2. Under "Sorted by Mission", click on "NIMS EDRs". 3. Find the encounter needed and click on the appropriate icon. The EDRs and their detached VICAR labels are in subdirectories of the "target" directories. Both are needed and the labels must be attached to the EDR proper, before inputting to nimscmm2. E.g., the files g7g002.edr and g7g002.vic can be retrieved from their respective directories and then merged by the Unix command: % cat g7g002.vic g7g002.edr > g7g002.EDR which generates the VICAR-labelled EDR file g7g002.EDR. The PDS filenames can be correlated to the NIMS observations by information in the files in the "index" directory of the dataset. Note that, at the time of writing, the NIMS EDRs are also online at MIPL in the directory /project/gll/nims/edr/pb. However, it is not certain how long they will remain there. These EDRs have the original filenames based on the observation name, not the shortened versions that were delivered to PDS. E.g., the EDR listed above, g7g002.edr, corresponds to g7gnglobal01a.11 in this location.
This specifies the filename for the cube generated by NIMSCMM2, which will be a three-dimensional image file of size NS*NL*NB numbers. The format will be halfword if CALTYP=NOCAL is specified, otherwise floating-point (unless RADSCAL>0 is specified). The spatial dimensions NS and NL may be set by the OUTSIZ parameter, otherwise they will be computed automaticall using SCALE. The spectral dimension, NB, is determined from the intrument mode as read from the EDR. However, the user may override this and specify that only one band be produced, using the OUTBAND parameter. Note that if the cube is a "tube" file, then the output size is determined in a very different manner: NS = number of mirror positions (normally 20), and NL = number of grating cycles. See parameter OUTTYPE. The ISIS "special pixel value" convention is used to flag pixels with unusual circumstances, e.g., missing data, saturation. See "Special Pixels Values" under Help. During Galileo systematic processing, the cube names were required to be of the form: Observation-name + Observation-extension + "_" + Initials + Mosaic-number where: Observation-name is a 12-character string starting with the Orbit designation (G1,G2,C3,...31,32,33), Observation-extension is a one-character designation (A,B,C,...), Initials is a 3-character string designating the person responsible for the cube or "MSY" for a delivered Systematic product, Mosaic-number is a two-digit number to make the name unique. The filetype designated the type of cube, e.g., ".QUB" for projected radiance cube, ".VTUB" for radiance tube, etc. E.g.: G1ENGLOBAL01A_MSY04.QUB for a Europa global mosaic from the first orbit, 33JNGLOBAL01A_MSY01.VTUB for a Jupiter global mosaic from the last orbit. Unfortunately, PDS at that time had a requirement of 8.3-format file names, so the delivered cubes have different names; the two examples cited above were changed as follows: G1ENGLOBAL01A_MSY04.QUB became G1E002CR.QUB, 33JNGLOBAL01A_MSY01.VTUB became 33J001TI.QUB. The original names can be found in the labels of the delivered cubes under the PRODUCT_ID keyword and also in files in the Index directories of PDS. In the current version of the program, the CUBE parameter is completely unconstrained, users are free to make up their own names.
This specifies the type of cube the program should generate. Note the following definitions: "Cube" = any three-dimensional file. "G-cube" = a cube in which the first two dimensions are map-projection space (geometrically resampled) and the third is band. "Tube" = a cube in which the first two dimensions are instrument space (defined below) and the third is band. "P-Tube" = same as "Tube", but with pointing data in the cotube. Specifying "TUBE" for this parameter specifies that the output cube should be a tube file. In this option, the sample direction follows the motion of the scanning mirror, while the line direction is along the scan platform motion. Thus, the 3 dimensions correspond to: 1 (sample )= mirror motion (always 1 or 20) 2 (line) = grating cycle 3 (bands) = same as cube file. The mirror UP position corresponds to sample = 20 and DOWN is sample = 1. Note that in Fixed mode (only) data taken in mirrow WAIT state are also projected; these data are not reversed, so they will show up as an anomaly in the regular reversal of the chop count in the last band of the co-tube (see HELP COCUBE). The default, "GCUBE", is to generate a projected cube, in which the first two dimensions correspond to the two dimensions of a spatial map. Note that under the TUBE option, the weights file (parameter WTFIL) is not used, and the cocube is significantly changed (see parameter COCUBE). Furthermore, in this case the following parameters are not used: OUTDETS, OUTBAND, SDBAND, SDGEO, and FILL. (Although OUTSIZ is used, it applies to the size of the map projection, so does not affect the tube dimensions, but just the [line, sample] planes in the co-cube.) The program will still perform a map projection for the TUBE option, but the pixels will not be stored in the map-projected locations; instead the projected (Line,Sample) values will be stored in the cocube, which is greatly expanded in size over the G-cube case (see parameter COCUBE). Since the Line and Sample values stored in the cocube are floating point rather than integer, and since DN values falling into the same projected pixels are not averaged, the information content of the tube file is actually far greater than of the G-cube.
This parameter specifies the organization of the output cube. Possible choices are: BSQ (band sequential): the order of the pixels in the file is Sample (varying fastest) - Line - Band (varying slowest), BIL (band interleaved by line): the order is Sample - Band - Line, BIP (band interleaved by pixel): the order is Band - Sample - Line. The normal Vicar standard is BSQ, which is the default value for NIMSCMM2. However, because the input data are processed in order of detector, this leads to swapping and extremely inefficient program performance in FULL or LONG mode (204 or 408 bands), when the spatial area (NL*NS) is large. This can be considerably remedied by specifying another file organization, especially BIP. The Fill algorithm will only work on BSQ files, therefore if BIP or BIL is specified, FILL is disabled. This parameter is not used under the TUBE option. (Note that the COCUBE file is always BSQ.) THIS OPTION IS TEMPORARILY DISABLED FOR RADIANCE SCALING
This specifies the filename for the "geometry co-cube" produced by NIMSCMM2. For the default G-cube option, this consists of 9 bands containing: 1 = latitude (planetocentric or planetographic, depending on LAT_TYPE) 2 = longitude (west for all allowed TARGETs except Venus, which has east) 3 = incidence angle 4 = emission angle 5 = phase angle 6 = "slant distance", in km 7 = height above planet (expanded-radius only, see below), in km 8 = standard deviation for one of bands 3-7 (see parameter SDGEO) 9 = standard deviation for one cube band (see parameter SDBAND). (For the TUBE option the structure is quite different, see below.) The format of this cocube is REAL. Pixels containing no data are assigned the value Null, see Special Pixel Values under Help. Band 6 (slant distance) is the distance from the spacecraft to the target body surface intercept point. For most projections, the value written to this backplane is the weighted mean of the actual slant distances for all input pixels contributing to this projected pixel. However, for the Perspective projetion, it is the slant distance from the standard perspective point of the projection; this can be used (together with the FOV) to obtain the linear dimension of the projected pixel in this projectionn. In this case, to obtain the actual slant distance at the instant of observation, one must examine the corresponding co-tube. Band 7 (height) is only of significance when the expanded-radius option is used (parameter RADFACT). In this option, a pixel falling off the planet for the normal radius is reprojected using an expanded radius. The DN of band 7 then has the following significance: If the pixel falls on the planet normally: DN = 0.0. If the pixel is projected using expanded radius: DN = height above surface. Completely off-planet pixels have the Null value, as for all other planes. Note that longitudes in the cocube/cotube are east for Venus, following IAU convention; the same is true for all longitude parameters. However, the longitudes in the Vicar label are always west, even for Venus, for compatibility with Vicar software. If parameter COCUBE is defaulted, the name is constructed out of the cube name by adding the filetype ".COC" for a G-cube (default), or ".COT" for a tube file. The incidence and emission angles are computed from the vectors to sun and spacecraft at the target-body surface. However, the phase angle is computed between the LOS (negated) at the spacecraft and the solar vector. This means that the phase angle is defined even when the LOS misses the target body, which can be an advantage when observing targets such as rings or upper atmosphere. There is a small error, in that the solar vector is reckoned from the spacecraft rather than the target, but this is negligible in most cases. For the TUBE file option, there are no standard deviation bands, and latitude, longitude, line, sample are stored for each grating position. (Line and sample refer to location of the pixel when map-projected.) When the Footprint option has been selected, then two extra bands are stored for each grating position, viz., line/sample of right edge. The exact structure for this option is: NBPG*(G-1)+1 = latitude for g.p. = G NBPG*(G-1)+2 = longitude for g.p. = G NBPG*(G-1)+3 = line for g.p. = G NBPG*(G-1)+4 = sample for g.p. = G NBPG*(G-1)+5 = line of right edge for g.p. = G (Footprint only) NBPG*(G-1)+6 = sample of right edge for g.p. = G (Footprint only) NBPG*NG+1 = incidence angle NBPG*NG+2 = emission angle NBPG*NG+3 = phase angle NBPG*NG+4 = "slant distance", in km NBPG*NG+5 = height above planet, in km, NBPG*NG+6 = time in chops after the beginning of the observation, as given by the BEG_SCLK label item. This is written for the first step in the grating cycle (only). In a tube, BEG_SCLK is always set to the beginning of a grating cycle, so the first line of the cotube always (except for Fixed mode) contains 19,...,0. (NOTE: 1 chop = 1 mirror step = 1/21 mirror scan = 1/42 minor frame) where: NBPG = 4 if not Footprint, 6 if Footprint, G (grating position) = 1,...,NG, and NG can range from 1 (Fixed mode) to 24 (Long mode). (For Long mode with Footprint there will be 150 bands in the cotube!) For a P-Tube cotube (P-cotube), the following bands are added: NBPG*(G-1)+NBPG0+1 = Right Ascension for (g.p. = G) NBPG*(G-1)+NBPG0+2 = Declination for (g.p. = G) NBPG*(G-1)+NBPG0+3 = Twist for (g.p. = G) NBPG*(G-1)+NBPG0+4 = X-component of vector from S/C to Target for (g.p. = G) NBPG*(G-1)+NBPG0+5 = Y-component of vector from S/C to Target for (g.p. = G) NBPG*(G-1)+NBPG0+6 = Z-component of vector from S/C to Target for (g.p. = G) where NBPG0 is the NBPG of the "standard" case, and NBPG = NBPG0+6. (For Long mode with Footprint a P-cotube will have 294 bands.) The extra bands for the P-cotube contain the geometry extracted from the NAIF SPICE kernels and interpolated to the mirror position. Right Ascension, Declination, and Twist are the three Euler angles defining the pointing matrices in the C-kernels. (Note that the Galileo C-kernels use a different definition of Twist than was used for Voyager: Twist(VGR) = Twist(GLL) - 90. The GLL Twist is the one stored here.) The other stored quantity is the vector from the spacecraft to the target body center. (This is the inverse of the normal "RS-vector) used by VICAR software.) All these quantities are in the B1950 system, per the Galileo project standard.
TARGET specifies the name of the target body being observed. A special case is TARGET=CALIBRATION, in which there really is no valid target body. This may only be used in the Tube option, and a dummy AACSFILE must be supplied (created by program CRDA).
DELRAD specifies a correction to the radius of the target body obtained from the SPICE interface, which will normally be used to account for the effect of an atmosphere. (Note that this effect is in principle wavelength-dependent, although the program cannot take account of this!) DELRAD is specified in km.
This specifies the name of the calibration files supplied by the NIMS team for this MM. Usually one file suffices, but if the Gain state changed during the observation, then multiple EDRs will have been generated, some with differing Gains in their headers. In this case, the user has the option to merge them all into a single cube by specifying different calibration files, one for each Gain state. It is required that, if more than one Cal files are supplied, the number of Cal files be exactly the same as the number of EDRs, and they be in the same order; i.e., for the Nth EDR, the program will use the Nth Cal files. This may mean that the same Cal file is repeated in the list. It is needed even if no calibration is requested (CALTYPE = NOCAL) because it is also used to calculate wavelengths. NOTE: there are two types of Cal and Dark files, binary and ascii. For most of the mission, binary files were used, but only the ascii versions were archived (though they were not delivered to PDS). The program assumes that the Cal file is binary, unless the filename contains the string ".tab" or ".TAB", or the keyword ASC_CAL was specified (which is the default). The ascii Cal files are online on Mipl in /project/gll/nims/cal.
This specifies the grating correction to be used in calculating the wavelengths. Normally, the value in the CALFILE is used, but if the user specifies this parameter, that value is overridden.
The grating step inflation correction, like PSHIFT, a parameter that was added when the NIMS wavelength calibration began to degrade.
This specifies the name of the dark files supplied by the NIMS team for this MM. It is not needed if CALTYPE = NOCAL, i.e., no radiometric calibration is requested. Like for the CALFILE, multiple dark files for one cube are possible. NOTE: there are two types of Cal and Dark files, binary and ascii. For most of the mission, binary files were used, but only the ascii versions were archived (though they were not delivered to PDS). The program assumes that the Cal file is binary, unless the filename contains the string ".tab" or ".TAB", or the keyword ASC_CAL was specified (which is the default). The ascii Dark files are online on Mipl in /project/gll/nims/dark.
This specifies the name of the boom obscuration map file supplied by the NIMS team. It is used to identify boom-obscured pixels and omit them from processing. The default value for this parameter is the standard Galileo boom map as seen from NIMS. To turn off boom-obscuration checking, enter null ("--") or DUMMY_DBM.DAT for this parameter. Note that the cone/clock angles used for the boom obscuration correction are require both a Platform and a Rotor [NOT IMPLEMENTED!] C-kernel, or equivalently an AACS-file. (See parameter CSOURCE.) If a Predict C-kernel is supplied, then boom correction cannot be performed, as there are no Predict rotor kernels.
This specifies the name of the despike file supplied by the NIMS team for this MM. NIMS spike files can be obtained from the PDS imaging node, as follows (as of 19 June 2008): 1. Go to http://www-pdsimage.jpl.nasa.gov/resources/onlineData.html 2. Under "Sorted by Mission", click on "NIMS EDRs". 3. Find the encounter needed and click on the appropriate icon. The spike files are in parallel subdirectory to that of the EDRs, under the "target" directories. Note that not all EDRs have associated spike files.
This specifies the name of the file containing the mean intensity at the solar surface, which is used only if Radiance calibration is performed (CALTYPE=RAD). In this case, the mean incident solar flux on the target body will be computed and written to the label for use in scaling the radiances. The default for this parameter is a file containing a standard solar spectrum from Allen, "Astrophysical Quantities", 3rd ed., which should be adequate for most purposes. Note: the intensities in this file must be in cgs units, i.e., erg/cm^2/sec/sterad/mu. However, the solar fluxes written to the label will be in the "mixed" units: uWatt/cm^2/mu, consistent with those used for cube radiances.
This specifies the name of on optional cube containing "standard deviations" (actually, square roots of the variances) for all cube pixels. These are defined as: SD = <DN**2> -**2 where the quantities on the RHS are defined under Help WTFIL. This parameter is ignored if the Tube option is used.
This specifies the name of the file in which the weights and squares are stored for the computation of mean output quantities and standard deviations. By default, this filename has no extension and the file is therefore temporary, with the Vicar2 default extension of ".Znn" (where nn are the final digits of the process id). By specifying an explicit file extension, the user can cause this file to be saved. The weights file is not used in the TUBE option. This file contains, for each spatial pixel containing valid data: - NGP bands (one for each grating position) containing the DN weight, WDN, - one band containing the weight for the geometry data, WG, - one band containing the mean of the square of the co-cube band SDGEO, - one band containing the mean of the square of the cube band SDBAND. (For definitions of these quantities, see below. SDGEO and SDBAND are user parameters.) NGP, the number of grating positions, is normally NB/17. Since weights are floating-point numbers, this yields a total file size of: NL * NS * (NB/17 + 3) * 4 bytes, where NL, NS, NB are the line/sample/band dimensions of the output cube. (Of course if NB=1 because the user specified the OUTBAND parameter, then the above factor of 1/17 vanishes and the temporary file is 8 times as big as the output "cube", which is in this case just a 2-D image.) DEFINITION OF QUANTITIES IN WEIGHTS FILE: Each output DN in the merged mosaic is the weighted mean of all contributing input data, formed as follows: ODNlsj = <IDN> = SUMi( Wilsj * IDNi) / SUMi( Wilsj) where: ODNlsj = DN for output pixel at line l, sample s, band j, IDNi = DN for input comb i, Wilsj = contribution of i to (l,s,j), SUMi is a notation signifying summation over index i, and this equation serves to define the notation <X> used below. (A "comb" is an array of 17 detector DNs for a given grating position, all of which have an identical geometry.) The quantities in the first NGP bands of the weights file are the denominator of the above equation: WDNlsj = SUMi( Wilsj) (This will apply to all 17 output bands corresponding to the given grating position.) The the mapping of i to (l,s) is a complicated function that is performed by the map projection routines. (For this reason, the limits of the summation cannot be explicitly given in the above equation.) In the nearest-neighbour algorithm the weight W is 1 for the single output location it maps to, and 0 for all others; therefore each WDN is simply the number of input combs contributing to that location. In the footprint algorithm the weights can be fractional, but the sum of the weights for one input comb is unity. See parameter BIN. The same algorithm is used to compute means of geometric angles and squares, see parameter COCUBE. For these quantities, the summation is over all grating positions as well as all combs, so that the corresponding weight is the sum of all the preceding band weights for that spatial location: WGls = SUMj( WDNlsj), j=1,...,NGP. In the nearest-neighbout algorithm, this sum is then the number of all combs falling into this (l,s) location anywhere in the cube. The standard deviation (SD) of a quantity X is computed by the equation: SD**2 = <X**2> -**2 (Note that this is not strictly the classical standard deviation, but rather the square root of the variance. For large samples, these two quantities are practically identical.) The last 2 bands of the weights file contain the quantities <SG**2> and <SDN**2>, where SG = one of bands 3-7 of the cocube (see parameter SDGEO), and SDN = a band of the cube (see parameter SDBAND).
Name of the mission phase -- this is needed as a label item only.
Name of the observation -- this is obtained from the NIMS request form and is needed as a label item. It is also used, together with MOS_NUM, to construct the cube file name (by SYSNIMS.PDF) and the PRODUCT_ID label item, as follows: PRODUCT_ID = OBSNAME // "_MSY" // seq_no where seq_no is a 2-digit expansion of MOS_NUM: "1" becomes "01", "A" becomes "10", "B" becomes "11", etc.
Mosaic number, which is used to identify the product in cases where more than one cubes are generated for a given observation. It is used to generate the cube name and PRODUCT_ID label item, together with OBSNAME. See HELP OBSNAME for more details. MOS_NUM should identify products in the sequence: 1, 2, 3,.., 9, A, B, C, ... Z. Thus, 35 different products for a given observation are allowed.
Observation note - this is obtained from the NIMS request form and is an optional label item.
This is any optional supplementary text to the OBSNOTE, which will appear in the cube label.
Product note - this is obtained from the NIMS request form and is an optional label item.
Product identification - this should be identical to the output cube name. If NIMSCMM2 is run from SYSNIMS, PRODID will be constructed as follows: PRODID = OBSNAME // "_" // INITIALS // SEQ_NO where SEQ_NO is a 3-digit number that is generated from the last character of OBSNAME, if this is alphabetic (A-Z). If PRODID is defaulted, then NIMSCMM2 will attempt this construction itself. However, in this case there is no guarantee that this will be the cube name.
A 3-letter code that will be used to generate the PRODID label item and output Cube names. This is supposed to identify the person primarily responsible for the cube. If NIMSCMM2 is run from SYSNIMS, then the default value for this will be MSY (= MIPS Systematic Processing), which should not normally be changed. NOTE: as of 03apr01, using INITIALS=MSY will turn off certain fixes to nimscmm2 which are not intended to be applied to Systematic products. Any other value will invoke these fixes. This can be overridden by specifying the keyword OLD_VER.
This keyword specifies that nimscmm2 should be run without using two fixes made in 2000-2001, which would cause cosmetic changes in the Nims systematic products which could confuse users without adding significant value. (The changes are to the cylindrical projection for Jupiter, and to thes slant-distance backplane for the Perspective case.) Normally this will be controlled by the INITIALS parameter (q.v.), but this keyword provides a means of overriding it. (If 'OLD_VER is specified, then the changes will *not* be used.)
Type of calibration for output data. The following choices exist: NOCAL = uncalibrated, raw DN. RAD = radiance (units: uWatt/cm^2/sterad/mu). When RAD is specified, the solar flux will be written to the label for use in scaling (see parameter SOLFILE), with units of uWatt/cm^2/mu.
Selects whether radiance scaling is performed. (It only has meaning when CALTYP=RAD.) This parameter is obsolete and the default value of 0 should always be used. RADSCAL=0: radiances will not be scaled. This is the default value. RADSCAL=1: radiances will be scaled dynamically to the halfword range with band-dependent base and multipliers. RADSCAL=2: radiances will be scaled to the halfword range using preset band- dependent base and multipliers, which are read in from the calibration file. RADSCAL=3: the radiances will be scaled to the halfword range using a single base and multiplier, which are read in from the calibration file. In addition, the following option is supported for special test purposes only (NOT to be selected for standard processing): RADSCAL=-1: this is actually a DN cube, which is output in floating-point in order to preserve accuracy of averaging; it is labelled a 'radiance cube' because all the s/w expects DN data to be integer. If a Dark File is specified in this option, then dark values will be subtracted from the data. If RADSCAL<=0 the output cube data format will be REAL (4-byte floating- point). Otherwise it will be HALF (2-byte integer). CAUTION! When a photometric correction is applied, (see parameter PHOTFUNC) it is possible to obtain radiances that would exceed the detector saturation limit if observed directly; therefore, the precomputed scaling factors used by default may be invalid. For such cubes, no scaling (RADSCAL=0) or dynamical scaling (RADSCAL=1) is recommended.
Type of dark interpolation used in the calibration. (Not yet implemented.)
This parameter specifies a threshold below which to omit data as being most likely part of the sky (dark) background. It is specified in terms of the dark value read in from the DARKFILE, e.g. DRKTHRSH=1.1 means that all pixels with DN less than 10% above the DARK value are omitted (set to NULL). This parameter is intended to help clean up the limb when using the Footprint algorithm.
This specifies the photometric function used to correct for effects of viewing angle. The options are: NOPCOR: no correction, raw DN is output. LAMBERTF: f = cos(I) LOMMEL: f = cos(I) / (cos(I) + cos(E)) MINNAERT: f = cos(I)**k * cos(E)**(k-1) This correction is applied only for wavelengths less than the value specified by parameter PHOTCUT. If MINNAERT is specified, then the exponential term "k" is determined by parameter MINN_EXP. (LAMBERTF has the final F to distinguish this keyword from the otherwise identical one under Projection.) (LOMMEL actually invokes the Lommel-Seeliger function, but this was shortened as a keyword for the sake of simplicity.)
Cutoff wavelength for the photometric correction specified by parameter PHOTFUNC. This should correspond to the highest wavelength at which there is significant incident sunlight in the data. The default (NULL in the PDF) is to use PHOTCUT=4.0 for Jupiter, and 5.3 (i.e., all NIMS wavelengths) for other targets. This parameter is ignored if no function is specified under PHOTFUNC.
This parameter specifies the exponential term "k" in the Minnaert photometric function, see parameter PHOTFUNC. It is ignored if PHOTFUNC is not MINNAERT.
Cutoff incidence angle (degrees): all pixels with incidence angles greater than this value are omitted from the mosaic.
Cutoff emission angle (degrees): all pixels with emission angles greater than this value are omitted from the mosaic.
PROJ specifies the desired map projection. Valid projection keywords are: MERCATOR CYLINDRI = simple cylindrical (or rectangular) NORMCYL = normal cylindrical SINUSOID = sinusoidal equal area LAMBERT = Lambert conformal conic STEREO = oblique stereographic POLSTER = polar stereographic ORTHO = oblique orthographic POLORTH = polar orthographic POV = point of view, or "object space" PERSPECT = perspective, synonym for POV Choosing a projection can imply that certain projection parameters are treated in a special fashion. In particular, TIELAT, TIELON, TIELINE, and TIESAMP specify the so-called "special point" which all projections require. For some projections this is just an arbitrary tiepoint, but others have a specific interpretation or constraint on these: CYLINDRI, NORMCYL, and SINUSOIDAL requires that the special point lie on the equator, i.e., TIELAT=0 is assumed (any user specification is ignored). MERCATOR requires that TIELINE = TIESAMP = 1 (any other specification will be ignored). POLSTER & POLORTH require that the special point be a pole, i.e., |TIELAT|=90; furthermore, this point is the center of projection. If the user omits TIELAT, then the pole nearest to the bulk of the image data is used. If TIELON is omitted, a default of 0 is used. ORTHO does not impose a constraint on the special point, but it will be the center of projection. LAMBERT: this projection requires 2 standard parallels to be specified using the PARALLEL parameter (which is ignored for all other projections). POV/PERSPECT: in this projection the viewing geometry may be specified by the REFSCLK parameter if the point of view is an actual scan platform position during the observation. If not, then the user must specify the full viewing geometry by hand, which means all of the following parameters (note that for this projection "TIE" refers to the sub- spacecraft point): TIELAT, TIELON, NORTH, PDIST, plus either: TIELINE and TIESAMP, or: OLATLON. The line and sample position of the optical axis may also be specified by the OAXIS parameter, and the output image size by OUTSIZ. However, if the user does not know these values from a previous run, then it is simplest to let the program compute them from the extent of the data. (OUTSIZ is not really a projection parameter, but if not specified the program will revise OAXIS & TIELINE/SAMP in the course of calculating the size, unless NORECENT[er] is specified.)
TIELAT specifies the special latitude point for map projection from latitude-longitude space to line-sample space. If projection is Polar Stereographic or Orthographic, this parameter is ignored: the pole nearest to the data is found automatically and used. If projection is Cylindrical or Sinusoidal, it is also ignored and the equator (tielat=0.0) is used. Otherwise, this defaults to the central latitude of the data. It may also be specified by the REFSCLK parameter for some projections. TIELAT ranges from -90 to 90, and is either planetocentric or planetodetic, depending on the LAT_TYPE parameter.
TIELON specifies the special longitude point for map projection from latitude-longitude space to line-sample space. It may also be specified by the REFSCLK parameter for some projections. If projection is Polar Stereographic or Orthographic, TIELON specifies the longitude that is "up" in the image. In this case, the default is 0. If projection is Cylindrical, this longitude will be in the center of the output mosaic. TIELON ranges from 0 to 360. It is West for all bodies except for Venus, for which East longitude is used following IAU convention. (Note that the Vicar cube label will show a West tiepoint longitude even for Venus, per Vicar convention, but the final ISIS cube will have East longitude in this case.)
TIELIN is the line location of the "special point", corresponding to the point specified by TIELAT and TIELON. If defaulted, the center of the data will be used. If projection is MERCATOR, then the special point is always at (1,1), and any other specification is ignored.
TIESAMP is the sample location of "special point", corresponding to the point specified by TIELAT and TIELON. If defaulted, the center of the data will be used. If projection is MERCATOR, then the special point is always at (1,1), and any other specification is ignored.
This allows the user to specify the North angle (measured clockwise from "up") for Oblique projections (Orthographic/Stereographic), or for Perspective if the user is specifying the parameters explicitly (as opposed to by the REFSCLK parameter). Default = 0., i.e., North is pointing straight up in the image. If "null" (--) is entered for this parameter, then the north angle of the original data (evaluated at the midpoint of the observation) is used.
PARALLEL specifies the latitudes of two standard parallels for Lambert projection. This parameter is ignored for all other parameters. If no values are specified for this parameter by the user, the program uses the following defaults: PARALLEL = (59.17, 35.83) or the negative of these values if the center of projection is in the Southren hemisphere. The parallels range from -90 to 90, and are either planetocentric or planetodetic, depending on the LAT_TYPE parameter.
REFSCLK specifies the s/c time (SCLK) which is to be the reference point for the map projection. It is defined as follows: REFSCLK(1) = 100*RIM + MOD91 (This time can be made more precise by using the parameter REFMP.) The subspacecraft point at the time specified by REFSCLK is taken as the center of projection, and is an alternative way of specifying the TIELAT, TIELON parameters. REFSCLK is ignored if the projection is Cylindrical, Sinusoidal, Mercator, or Polar Stereographic or Orthographic, as these have their own conventions for the "special point". For POV/PERSPECT projection, REFSCLK determines not only the sub-space- craft point, but also the distance to planet center and the optical axis direction. If a point of view outside the actual range of scan platform positions during the observation is desired, then the user must specify the full viewing geometry by hand, see HELP PROJ. Also, OLATLON may be specified in conjunction with REFSCLK, in which case the latter only determines the sub-spacecraft point, while the former determines the optical axis position (OM-matrix). If the full viewing geometry is not specified, and REFSCLK is also omitted, a default value of REFSCLK midway between the extreme SCLK values in the input EDRs is used.
This parameter is only used if REFSCLK has been specified (q.v.), in which case it specifies the mirror position (MP) inside the RIM and MOD91 of the latter parameter. Note that MP ranges from 0 to 39, and there are 4 MP per MOD10 (or RTI). REFMP defaults to 9, halfway in the first mirror scan of the MOD91.
This allows user specification of the optical axis line and sample for Perspective projection. (It is ignored for other projections.) This need not not normally be specified by the user, as the program computes it from the extent of the valid data in the image, unless 'NORECENT[er] is specified. However, if OAXIS is known from a previous run with the same projection, then specifying it and OUTSIZ will save cpu time. In this case, the full viewing geometry must be specified (see POV/PERSPECTIVE under HELP PROJ). The exact location of the optical axis in the image plane is fairly immaterial, unless it is offset from the target body center by an amount that is of the order of or greater than the NIMS focal length, which is 2000 pixels: in that case, the effect will be to distort the body being observed along the line connecting the optical axis to the body center (subspacecraft point); e.g., a spherical body will appear as an ellipse. (The optical axis does NOT have to be in the image!) Note that the effective focal length is changed by the SCALE parameter: an increased SCALE corresponds to a shorter focal length, which will increase the effects of an offset in the optical axis from the target body center.
This allows user specification of the optical axis latitude and longitude for Perspective projection. (It is ignored for other projections.) This parameter gives the user more control over the output projection than the TIELIN, TIESAM parameters, which are hard to estimate ahead of time. (However, OAXIS is better suited for a case where one is trying to reproduce a previous result, in which the optical axis location is specified by Line/ Sample in the map labels.) Note that this parameter only allows an optical axis that intersects the target body surface. See discussion of the optical axis under the OAXIS parameter. OLATLON may either be specified along with all the other viewing geometry parameters (see PERSPECTIVE/POV under HELP PROJ), or it may be used along with the REFSCLK parameter. In the latter case, REFSCLK will only be used to determine the RS-vector, while the OM-matrix will come from OLATLON. As with other longitude parameters, OLATLON(2) is West longitude for all bodies except Venus, for which it is East per IAU convention. OLATLON(1) ranges from -90 to 90, and is either planetocentric or planetodetic, depending on the LAT_TYPE parameter.
If RECENTER is specified, then the program will shift the optical axis (OAXIS parameter) to center the data in the image. Otherwise, the user-specified optical axis will be retained. (It is possible that the user entered an arbitrary optical axis in order to complete the viewing geometry requirements of MOMATI.) The default is to recenter, unless the user specified both OUTSIZ and OAXIS. (If the user did not specify OAXIS, the program uses an initial guess of (0,0), and always recenters; the RECENTER parameter is not checked in this case.) (POV/PERSPECT only)
This specifies the S/C-Planet distance ("range") for POV/PERSPECT projection, in km. (It is ignored for other projections.) It is not needed if REFSCLK has been specified.
SCLK specifies a list of pairs of numbers, which represent a series of beginning and ending SCLK values. Only cube data inside these intervals will be used for the mosaic. Each SCLK value in this list specifies a RIM and MOD91 count, as follows: SCLK = 100*RIM + MOD91 If either the beginning or the ending SCLK of an interval is 0, then the program will use the earliest or latest SCLK in the input data, respectively.
RADII allows the user to override the target body radii in the SPICE kernels. The three values are the axes of a tri-axial ellipsoid, in the following order: (Semi-Major Equatorial Axis, Semi-Minor Equatorial Axis, Polar Axis).
RADFACT specifies a radius expansion factor for pixels that fall off the planet for the nominal radius (including the DELRAD correction). It is only usable for projections which allow off-limb regions to be displayed, currently only POV/PERSPECT and Orthographic. Some applications for this include atmospheric limb data, nearby bodies, or data rendered off-planet by pointing errors. RADFACT is specified as a multiplicative factor to the nominal radius supplied by SPICE. E.g., if RADFACT=1.5 and the radius from SPICE is 6000 km, then the expanded radius" is 9000 km. This is actually an upper limit to the radius expansion used, see next paragraph. When RADFACT > 0.0 is specified, then for every pixel falling off the planet, a second projection is attempted using a larger radius. The new radius is the tangent radius to the line of sight from the planet center, assuming that this does not exceed the expanded radius. If this succeeds in putting the pixel on-planet, then the DN is written out normally but the increase in radius is written to the corresponding location in plane 7 of the cocube, which indicates that the value is "fudged". Some points that fall barely off-limb may turn out to be "back-of- planet" and therefore still not be projectable, depending on where the projection viewpoint is taken. This can be remedied by changing the viewing perspective, using the REFSCLK parameter.
For true map projections (i.e., all values of the PROJ parameter except for POV/PERSPECT), SCALE specifies the number of kilometers per pixel at some special point of the projection plane. The special point varies for different projections. If SCALE is defaulted (a "null" value or 0 is supplied), then it is determined as follows: a) if OUTSIZ is specified, then SCALE is computed to be that value which allows the data to just fit in the specified size; b) otherwise, SCALE is computed from the nominal FOV (0.5 mrad), by the formula: SCALE = FOV * DIST, where DIST is the distance from spacecraft to target body at the reference time (see REFSCLK). For POV/PERSPECT (perspective) projection, SCALE specifies a factor which multiplies the default scale, which is that of the instrument at the distance determined by REFSCLK (or PDIST). For this value of PROJ, the default value of SCALE is 1.0. Note that in all cases, decreasing SCALE increases the spatial size of the cube.
This parameter specifies the linear dimensions of the spatial planes of the cube file: NS and NL. Note that the SCALE parameter determines the size of the output mosaic, and therefore OUTSIZ may be omitted if SCALE is specified. If OUTSIZ is defaulted, the image size will be just large enough to fit the entire image at the specified scale (see HELP SCALE). In the POV/PERSPECT case, it is allowable to specify only one of NL or NS; in this case the other must be given the value 0 in OUTSIZ. The program will then compute the missing value of the pair. For other projections this is not allowed, i.e., the user must specify either both or neither of NL and NS as non-zero quantities. Note that if OUTSIZ is specified, the program assumes that the user has worked out the whole geometry, so no attempt will be made to recenter the image.
BIN specifies the type of binning algorithm that will be used in assigning output pixel values. There are two choices, FOOTPRNT and NEAREST. BIN=NEAREST: This is the "nearest-neighbour" algorithm, in which the output DN is assigned to the pixel closest to the map projection of the center point of the input pixel. The neglect of the pixel footprint can be partially corrected by the FILL algorithm. BIN=FOOTPRNT: In this algorithm, the footprint in the output image is computed for each input pixel. For each output pixel, the fraction of its area falling inside this footprint is the weight of this pixel in the determination of the final output DN. This is accomplished by map-projecting the four corners of the input pixel, covering the resulting quadrilateral in the output image by a grid of 200 points, and then processing each of these points by the nearest-neighbour algorithm, weighted by the detector response function at that point. NOTE: if the scale of the projection (or significant parts of it) rises to significantly more than 1 output pixel per input FOV, then the grid density should be correspondingly increased using the FPNGRID parameter. CAUTION: when the footprint algorithm is used in a cylindrical projection (Simple/Normal Cylindrical, Mercator, Sinusoidal, Lambert), there is a danger that some pixels may straddle the longitude at which the image "wraps around", so that one side of the pixel projects at the far left edge of the image and the other side at the far right edge. This can usually be avoided by judicious choice of the position of the center longitude (TIELON, TIESAM), but if the data span the entire surface of the target body, then no choice will eliminate the possibility entirely. The code contains a check for this condition for Simple Cylindrical, where it is easily remedied, but so far no correction has been implemented for the other cylindrical projecitons. A discussion of the weighting algorithm used when averaging output pixels in a given "bin" is given under HELP WTFIL.
For planets that are not modelled as perfect spheres, this keyword controls the type of latitudes output by the program: LAT_TYPE = PGRAPHIC or PDETIC (this value is provided because the term "planetodetic" is used for this case in VICAR documentation) specify planetographic latitudes, which are measured with reference to the surface normal. LAT_TYPE = PCENTRIC specifes that latitudes are planetocentric, i.e., determined by the vector from the planet center. The default is PGRAPHIC, since this is the PDS and ISIS standard. The scope of this specification includes latitudes both in the cocube and in the label. If the target body is a sphere, then this keyword is ignored and no reference to planetographic/-detic is made in the label.
This parameter specifies whether or not to fill pixels for which no data exist by interpolation among surrounding data values. If requested, this algorithm requires two additional parameters, N1 and N2, both of which are specified by the user parameter FILPAR (q.v.). The algorithm works as follows: for each missing pixel (indicated by a data value of Null, see Help on Special Pixels) that is on-planet, construct an N1 x N1 box centered on that pixel and count the number of valid pixels inside that box. If this number exceeds N2, then replace the missing pixel by the weighted mean of the valid pixels in the box, using the inverse square of the distance as the weight. FILL is also ignored under the TUBE option.
This parameter specifies the two parameters needed by the FILL algorithm (see parameter FILL): dimension of fill area, and number of valid pixels.
For a DN cube, this parameter indicates whether to flag saturated DNs, i.e., pixels with DN = 1023, with an ISIS special value, as described under "Special Pixel Values" in Help. For a Radiance cube, this function is done by the external calibration software; in this case, this parameter indicates whether a saturated pixel is to be overwritten by a valid datum if it happens to coincide in the output cube: IGNORE means that saturated pixels are overwitten by valid data, FLAG means that a saturated pixel will "dominate" any other coincident data, as long as its weight exceeds that specified by the SATTHRSH parameter. SATURATD=BB_REPL is a special option for radiance cubes, in which saturated values in the "thermal" region (which is assumed to be above 3.0 mu) are replaced by an estimate based on the black-body function for the mean brightness temperature of the non-saturated thermal radiances in the same comb. This should be used with caution, as an experimental means of avoiding problems of varying contributions to a given output pixel from different parts of a comb due to some being saturated. SATURATD=MAX_REPL is an even more extravagant option, in which a saturated DN (1023) is replaced by the largest unsaturated value (1022). This should only be used in very unusual circumstances.
Threshold weight above which to flag saturated pixels, see parameter SATURATD. If this is Null (which is the default), then the threshold will be set to 0.5*S', where S' is the ratio of the actual scale to the nominal scale. Typically the cube scale is set to 0.5 times nominal (for Nyquist sampling), so this corresponds to SATTHRSH = 0.125.
This parameter only has meaning if thresholding is used, in which case DNs below a certain value are replaced by the value 4 in the EDR. If LO_SAT is specified, then these DNs are represented in the cube by the ISIS special value for Low_Instrument_Saturation, otherwise they are simply replaced by NULLs.
This parameter is used only if BIN=NEAREST. If BIN=FOOTPRINT, then overapping pixels are always averaged. If OVERLAP = AVERAGE, then overlapping output pixels are averaged. This is the default option, and should only be changed for some special purpose. (But see the cautions below.) If OVERLAP = REPLACE, then each subsequent overlapping output pixel replaces its predecessor, i.e., the last pixel is used. This option exists for comparison of test cases with Flagstaff software. If OVERLAP = MAXIMUM, then in case of overlapping output pixels the largest one is used and others are discarded. This is useful in case of boom obscuration, where the boom is darker than data pixels. CAUTION on the averaging process: Averaging uncalibrated DNs (if CALTYP=NOCAL) can give incorrect results if calibration constants are not the same for all data. Currently, this condition is satisfied for all values except those in the "thermal" detectors (15, 16, and 17), which have different sensitivities above and below a threshold DN near 512; the program corrects for this in an approximate fashion. However, future calibrations may violate the condition, e.g., with dark values that depend on mirror position.
This parameter is used only in the Footprint option (see parameter BIN), and is the threshold weight above which to keep an output data value. If the weight for a given spatial pixel at a given grating position is less than THRESH, then the DNs for all 17 detectors at this point are set to the special value NULL (see Special Pixel Values under Help). The default for this parameter (if "null" is specified) is to let it depend on the scale of the projection relative to the nominal scale of the observation: at this nominal scale, one output pixel (at least at the center of the projection) is equal to one input FOV; for this, the default THRESH is set to 0.1. If the scale differs from the nominal value, then THRESH is varied proportionally to its square. E.g., if the nominal scale of an observation is 60 km/pixel, and the projection uses 30 km/pixel, then the default THRESH will be 0.025.
This parameter sets the maximum "distortion" allowed in the footprint of a single pixel, i.e., the maximum distance (in the Line or Sample direction) allowed between the 4 corner points of a pixel footprint. If this is exceeded, then the pixel is omitted from processing. This can be useful to remove artifacts from image regions which are distorted in certain map projections, e.g. the polar areas in cylindrical projections, and pixels falling near the limb.
Determines footprint grid mesh density. The footprint of an input pixel is covered by a grid with FPNGRID points in cone direction and 2*FPNGRID points in cross-cone. The weight of this pixel for a given output pixel is then determined by counting the number of grid points falling into that output pixel. (The "tent function" detector sensitivity is also factored into this weight.) Since only the four corner points of the rectangular footprint are actually projected, increasing FPNGRID should not seriously degrade program performance, though it will have some impact.
This parameter controls the "histogram binning" option, in which output pixels are not averaged together but are accumulated into histograms, of which the peak value is selected as the final output. Specifying a non-null value for this parameter enables this option, and the value specified is the number of bins used in each histogram. Since there is a histogram for each output pixel, plus one for the geometrical weight which is still used when computing the co-cube planes, the total size of the weights file is NL*NS*(1+NB*(HBINSIZE+1)) real*4 items. This is equivalent to a cube with band dimension (1+NB*(HBINSIZE+1)), at most (NB=17, HBINSIZE=1023) 52364; it is very doubtful that a file anywhere near this size can actually run on our current platforms for a typical cube, so this parameter should normally be set to a value considerably below its maximum. Because of the large demands on disk space, this option is only allowed in Fixed-mode cubes. HBINSIZE=510 (the current PDF maximum) and HBINSTEP=2 covers essentially the entire NIMS DN range (7-1022), and works for most normal cubes.
This specifies the # of DNs per histogram bin, if the HBINSIZE parameter is non-null.
The criterion used to evaluate histogram, if the HBINSIZE parameter is non-null.
This specifies the maximum slew rate allowed, in units of the Nyquist sampling rate of one-half NIMS resolution element (0.5 mrad) per grating cycle. If two mfs in succession show a higher rate, then the first one is discarded. The intent of this parameter is to check for scan platform flybacks between swaths and anomalies in the scan platform guidance and control, and remove these data from the observation. Note that the first two minor frames after a gap (including those at the start of an observation) are omitted because the slew rate cannot be determined for them. This can be avoided by specifying a negative number for SLEW_TOL (and TWIST_TOL, q.v.), which suppresses the slew rate check.
This specifies the maximum twist change allowed in the AACS pointing data, in degrees. If two mfs in succession show a higher rate, then the first one is discarded. This parameter is similar to SLEW_TOL, in that it checks for "spikes" in the twist data. (Twist angle does not directly affect the scan platform spaial motion, but it determines the NIMS mirror offset position, so a bad value can have drastic effects on the location of cube pixels.) As for parameter SLEW_TOL, this can be suppressed by specifying a negative number for this parameter.
This keyword controls what is done when a C-matrix (pointing data) is missing for an mf, and when computing C-matrices for individual mirror positions: CEXTRAP (default): if a C-matrix is missing, the program will search nearby mf's (up to a limited distance away, currently hard-coded at 10 MFs) for valid values, and then interpolate/extrapolate to the desired mf. When computing C-matrices for mirror steps within an mf, if no C-matrix is available at both start and end of the mf, the program will extrapolate from the preceding mf. NOCEXTRP: in both these situations, the sensor data in the mf are not processed.
CSOURCE specifies the source of the angles which define the camera pointing (characterized by the "C-matrix", which transforms between Earth and Camera coordinate systems). CSOURCE can have the following values: AFILE: the angles are extracted from an "AACS file", supplied by the NIMS team. The name of this file must be supplied using the parameter AACSFILE. SPICE: the angles are extracted from C-kernels, specified by the parameters PCKERNEL and (if Debooming is desired) RCKERNEL. NOTE: the RCKERNEL is not currently supported! If de-booming is desired, then CSOURCE=AFILE must be specified. The default is AFILE.
This parameter specifies the C-kernel containing the scan platform pointing angles, to be used when CSOURCE=SPICE is specified. This parameter is required when CSOURCE=SPICE is specified.
This parameter specifies the C-kernel containing the rotor pointing angles, to be used when CSOURCE=SPICE is specified and the Deboom option is on. This is required in order for the program to compute the cone/clock angles required for the boom obscuration check. NOTE: this is currently not supported! If de-booming is desired, then an AACSFILE must be supplied, see parameter CSOURCE.
This parameter specifies the name of the AACS pointing file supplied by the NIMS team, from which the pointing data will be obtained. This parameter is required when CSOURCE=AFILE is specified.
This parameter specifies the SP-kernel, containing Spacecraft and Planet state vectors. This parameter should not normally be specified by the user as the SP-kernel usage is regulated through the MIPS kernel database (logical name KDB__DATA).
This parameter specifies the Planet constants kernel, containing Planet (also Moon, Asteroid, etc.) radii and rotation constants. This parameter should not normally be specified by the user as the PC- kernel usage is regulated through the MIPS SPICE interface.
This parameter specifies the I-kernel (containing Instrument specs) that is to be read by the program. This should not normally be specifed by the user.
This specifies a single offset to Right Ascension and Declination: DPOINT = (dRA, dDEC) (in RADIANS!) which is to be added to all the pointing data (Camera Euler angles: Right Ascension, Declination, Twist) read in from the source specified by the CSOURCE parameter. Note that this is the crudest possible way of correcting the pointing, and should only be used as a last resort. The offset in this parameter would normally be derived from navigation of images pertaining to the observation.
SCLK range for DPOINT. If (0,0) is specified (the default), then DPOINT applies to the entire range.
Amplitude of wobble that can be optionally added to the pointing. This has the form: Delta(Cone) = WAMP * cos( WFREQ*t + WPHASE) Delta(Cross-cone) = WAMP * cos( WFREQ*t + 90 + WPHASE) * cos(CONE) Delta(Twist) = WAMP * cos( WFREQ*t - 90 + WPHASE) * sin(CONE) where: WAMP is the amplitude in radians WFREQ is the frequency in degrees per minor frame (must be > 0) WPHASE = phase with respect to the beginning SCLK of the observation, in degrees Note that time, t, is measured in minor frames (MOD91) since the beginning of the observation. An alternative formulation in terms of Clock angle instead of time is also supported: Delta(Cone) = WAMP * sin( WPHASE - CLOCK) Delta(Cross-cone) = - WAMP * cos( WPHASE - CLOCK) * cos(CONE) Delta(Twist) = - WAMP * cos( WPHASE - CLOCK) * sin(CONE) This formulation is used when WFREQ=0 is specified. Here WPHASE is the phase angle of the wobble unit vector (cross product of the angular- momentum unit vector and the rotor-Z axis) in the rotor coordinate system. Since CLOCK is not available with Predict pointing, this option is only available when AACS telemetry pointing is supplied. This formulation is more elegant than the above one since it is independent of the time of the observation, and takes account of clock slews. Since CONE is required, for Predict pointing this must be specified separately using the WCONE parameter.
Wobble frequency, see WAMP. The default value is the current best estimate of the GLL Rotor frequency. This is ignored if WAMP=0.
Wobble phase, see WAMP. This is ignored if WAMP=0.
Estimate of the Cone angle for wobble model, if Predict pointing is used. This is ignored if WAMP=0 or an AACSFILE is specified.
EPHERR is a time offset (in seconds) that allows the user to simulate an ephemeris error: the time at which the spacecraft and target body positions are read in from the SP-kernel is offset from the time of the data by this amount.
Mirror asymmetry offset: a signed floating-point number that is added to the 20 XCONE_UP mirror offsets read in from the IKERNEL and subracted from the 20 XCONE_DOWN offsets. THIS IS A TEST PARAMETER FOR USE BY THE NIMS COG.ENG. ONLY
Grating offset. This parameter is required for the calibration algorithm. It helps to determine the physical grating position (GPHYS) by: GPHYS = GOFFSET + GLOG where GLOG is the logical g.p., obtained from the HRS data in the EDR file. Grating offset is expected to vary infrequently from its default of 4 over the course of the mission. If it does, this information must be supplied by the NIMS team. The value of this parameter is written in the cube label.
This parameter allows the user to specify the grating start position, which is normally read in from the "digital stat" section of the HRS data. This is useful if the EDR is incomplete or corrupted. Note that if this item is present in the EDR, then the user-specified value will be overwritten, unless INSMODE or NOHKP is specified.
Instrument gain state. This parameter should not normally be specified by the user, as the program reads it from the LRS data in the EDR record headers. However, should this item be missing from the EDR for some reason, the user can supply it by this parameter. Note that this quantity does not affect program processing in any way, it is included only for the label information. However, the gain state should be consistent with the calibration file used if the cube is to be in radiance units (see parameters CALTYPE and CALFILE). (Multiple Gain states are not supported in this parameter: in such a case, the program *must* get the Gain from the EDR headers; see parameter CALFILE.) Note that if this item is present in the EDR, then the user-specified value will be overwritten, unless INSMODE or NOHKP is specified.
Instrument chopper mode (this has to do with the basic clock frequency). The numerical value signifies the following states: 0 = 63_HERTZ mode 1 = REFERENCE mode 2 = OFF 3 = FREE_RUN This parameter should not normally be specified by the user, as the program reads it from the LRS data in the EDR record headers. However, should this item be missing from the EDR for some reason, the user can supply it by this parameter. Note that this quantity does not affect program processing in any way, it is included only for the label information. If this item is present in the EDR, then the user-specified value will be overwritten, unless INSMODE or NOHKP is specified.
Instrument mode. This should not normally be specified, since it is determined from the Housekeeping data in the EDR file. If the user should specify a mode different from what is in the data, then the program will immediately find a mode change and stop processing. Therefore, the only use for this parameter is as a check on what is in the EDR, or if the housekeeping data are corrupted (see param NOHKP). Codes for instrument modes are: 0 = safe 1 = full map 2 = full spect 3 = long map 4 = long spect 5 = short map 6 = short spect 7 = fixed map 8 = bandedge map 9 = bandedge spect 10 = stop/slide map 11 = stop/slide spect 12 = "special sequence" 13 = "long fixed map" (see below) Note that stop/slide mode consists of two modes, each generating one cube, so that specification of the STOPSLID parameter is required. "Special sequence" is not an official NIMS mode, but denotes a mode used in Earth-2 with Short Map number of grating steps and Full Map grating increment. In the future more special sequences are expected, in which case code must be added to handle them. "Long fixed map" is another unoffial mode, which was created to handle the I24 anomaly in which the grating was stuck. The nominal mode of the observation is Long Map, and the grating delta (GDEL) is zero. The number of bands in the cube is equal to the number of detectors used. When INSMODE is specified, parameter GSTART and, for SAFE and FIXED modes only, NLGP (q.v.) should also be specified.
This keyword specifies that the housekeeping data in the EDR should be ignored. This has two effects: (a) the instrument mode must be user-specified (using parameters INSMODE, GSTART, and for some modes NLGP); (b) valid data flags are ignored.
This parameter instructs the program to discard the specified mirror positions. In this case (only) mirror positions are counted from 1 to 40, i.e., the "up" and "down" scans are taken together in one cycle. (Usually this program considers each to be a separate scan with 20 positions.) Therefore, up to 39 values may be specified (it would be pointless to discard all 40!), and each must be in the range 1-40. This parameter only affects pixel DN values. The co-tube will contain data for all mirror positions even if MIRROMIT has been specified. This parameter is intended for test purposes and to correct problems with the instrument, and should not be specified by the casual user.
These are 6 instrument temperatures applying to the following subsystems, in order: Focal Plane Assembly (FPA) Radiation Shield Telescope Grating Chopper Electronics These temperatures are used by the photometric and wavelength calibration routines. They are also written to the cube label. Only the FPA and Grating temperatures are used in the calibration. In phase-1 data, these temperatures are normally read from the EDR label and this parameter exits only to allow user override. However in phase 2 they are not present in the EDR, so reasonable defaults have been added.
This parameter will very rarely be used: it has meaning only for SAFE and FIXED modes (INSMODE = 0 or 7), and only if the user specifies INSMODE (which should itself be rare, see HELP INSMODE). The reason for this parameter is as follows: in these modes, the grating is in fact stationary, but the mirror pretends that it is moving and goes into a wait state every NLGP cycles. The program must know when this occurs in order to treat these data appropriately.
This parameter specifies which mode is to be used for the current cube if instrument mode is "Stop / Slide". (This mode contains a mixture of data in 2 different modes, alternating regularly. NOTE: This option is not yet implemented.
This parameter specifies which band of the cocube will be used to compute the "geometric" standard deviation in band 8 of the cocube (see parameter COCUBE). Only bands 3-7 are allowed, since the lat/long bands are not computed as each input pixel is processed, but once at the end of processing. The default is band 5, phase angle. This parameter has no meaning under the TUBE option.
This parameter specifies the band index at which to compute a standard deviation for the cocube file (see parameter COCUBE). Band index is related to detector, D, and grating position, G, by: BAND = (D-1) * NG + G where D = 1,...,17 G = 1,...,NG NG = number of grating positions for current instrument mode (possible values are 1, 2, 6, 12, and 24). The default for SDBAND is NB/2 (rounded up). This parameter has no meaning under the TUBE option.
Range of detectors to ouput: The two values entered are Starting Detector and Ending Detector, both in the range 1,...,17. The default (if the parameter is nulled) is to generate data for all 17 detectors. Note that the number of bands in the output cube is the number of detectors specified multiplied by the number of grating positions, as determined by the instrument mode.
Detector(s) to omit. The bands for these detector are still included in the cube, but all data values are set to NULL. Detectors are numbered from 1, so the range is 1,..,17.
If this is N>0, then only every Nth (logical) grating position will be processed, starting with 0. GPs are numbered from 0 to 23.
This parameter specifies that only a single band be generated in the output cube, thus making it a 2-dimensional image. The band index will correspond to a certain detector, D, and grating position, G, where: OUTBAND = (D-1) * NG + G where D = 1,...,17 G = 1,...,NG NG = number of grating positions for current instrument mode (possible values are 1, 2, 6, 12, and 24). By default all bands for the mode used are generated. This parameter will normally only be used for test purposes.
If this keyword is set, the compression status flag is checked and EDR records in which it is not ok (zero) are skipped. Otherwise, such records are processed, though the number of possible affected combs is reported.
Beginning and ending mirror positions. This should normally remain at the default values. This parameter is intended for use for observations taken with mirror blocking, for tubes. By convention, mirror positions are numbered from 0 to 19, starting from the "top" (= most negative cross-cone value). Hence, MP=0 corresponds to the rightmost pixel in a tube, sample 20.
Specifies whether or not the program is to update the Image Catalog.
This is a debugging/test parameter and should always be left at its default value of 0 by users. TEST=1 generates an ascii file called MTRACK.DAT, containing coordinates of the mirror track for the chosen projection. TEST=2 generates a listing of SCLK, mirror position Lat/Long, and planet radius at intersect point (as returned by PPROJ). TEST=3 generates a listing of SCLK, OM-matrix, and RS-vector, for mirror extrema only. TEST=4 generates a listing of wavelengths and radiance scaling coefficients by band #. TEST=5 generates a listing of Euler angles, Cone, Clock (as read in from pointing source), and valid flag, for all mfs TEST=6 generates a listing of SCLK, MP, Lat, Long, Line, Sample for the points used to determine the map projection size and offset. TEST=7 is same as 5, except only valid mfs are printed TEST=8 is same as 2, except only data for MP=10 (counting from 1) are printed. TEST=9 generates a listing of Euler angles & Cone/X-cone offsets after all corrections have been applied, for MP=9 only TEST=10 is same as 1, except only MP=0 (mirror extrema) is printed. To restrict output (TEST=1-3 only) to one gp, use the OUTBAND parameter.
This keyword disables passing LRS temperatures to the calibration routines, so as to return the old default wavelength sets. It also enables the old scheme by which the calibration routines were called at every new RIM, rather than only at the start of the observation. It is to be used for test purposes ONLY!