The parameter file obspars allows the astronomer to specify details of
how the images will be named, whether or not s/he wishes to set the filter
and/or telescope focus for each exposure, details of how focus frames should
be taken for direct imaging, and additional comments for the header.
A sample obspars can be seen in Figure 5.
An inspection of Figure 5 can be a little misleading---it
is not necessary to change any of the first nine items in the
parameter file, as the user will be prompted for these whenever appropriate.
The values listed there at any time are simply the most recent entries, and is
what ICE uses to offer as default values when you hit [CR], as you may remember
from the previous example of using observe (refer back to
Parameters that you may wish to alter:
- rootname and sequence: These control what the next picture
will be called, e.g., n30001 in this example. You may wish to change
the rootname from night-to-night (see Section C below on
``Keeping Your Data Organized"), but remember to keep this short---you
will have to type this every time you refer to the image. The sequence
number allows you to reset the picture counter to whatever number you
want, although you must first explicitly get rid of any images with
the same name using imdelete.
- setfilters and setfocus: These two
parameters control whether
the user will be prompted for the correct setting of the filter and/or focus
value at the beginning of each exposure. The filter parameter has proven
to be invaluable for direct imaging; it both reminds the astronomer what
filter is currently in place, and offers an opportunity to change it at
that time. Since different focus values are sometimes required for each
filter, it is also sometimes useful to set the focus prompt-and-set as
well; otherwise you (or the telescope operator) may set the telescope
- setscanrows: This parameter controlls the ``short-scan" option
with the scan-table at the 4m P/F. A new scanning table, capable of
contending with the 2048 chips, is now in use, and ICE makes using this
option fun and easy to use. Set setscanrows to ``yes" in order
to be queried for the number of rows to scan (``1" is equivalent to not
scanning). Note that the instrument name must be set to ``pfccd" in
instrpars for scanning to work.
- nscanrows: This parameter determines the number of rows you
are scanning if you are using the scan table at the 4-m. If this
parameter is ``1" the scan table is not used. Note that the instrument
name must be set to ``pfccd" in instrpars for this parameter to
actually do anything.
- observers and propid: These
are put in the image headers and are used
by the Save-the-Bits data archive for record keeping. (See Sec. 4.3.)
- comments and comfile: These two parameters allow you to add
even more information to your header. The parameter comments may be
edited to contain a single line of additional comment. The parameter
comfile may contain a file name that contains multiple lines of
comments. Each line of this file is automatically formatted into
a FITS COMMENT record. You should not include the COMMENT
keyword in this file. Since this file is read at the beginning
of the read-out, you may edit this file any time during the
exposure. The comfile is automatically set if you are using
the automatic logging software (Sec. L).
- command: This is a very powerful (and potentially dangerous)
feature: any IRAF task placed here will be executed immediately after
the chip is read-out. The default is to execute the script postproc.cl
in background mode. This file will causes the terminal to ``bleep" at
end of the integration, and will automatically display the new image
in the ximtool window and activate the automatic logging, if in use
(see Sec. L).
You can edit the postproc.cl file to execute any
command you so choose, but be careful to add new commands only at the
end of the file.
One could, in principle,
automatically tape each new exposure and then, say, run the data through
ccdproc, but we are not recommending this.
- preallocate: This switch controls whether or not diskspace is
``reserved" for your image. If there is insufficient space for the new
image at the beginning of the integration, a warning will be issued and the
exposure won't begin. If there is sufficient space at the beginning of the
exposure, preallocate guarantees that space will be there at the
end of the exposure; it accomplishes this by writing a dummy image of the
same size but with a ``." stuck in front of its name in order to make this
an ``invisible" file.
Upon read-down, the new data replaces the old, and the image is renamed.
There is a slight
time penalty incurred in preallocated disk space.
Thus, rather than insisting that preallocate always be on or off,
the parameter can be set to a minimal integration time for preallocation.
The default value is 60, meaning that preallocation will only be in effect
for integration times greater than 60 seconds.
to 1 will result in preallocation happening for all images; setting
this to 0 turns off any disk space checking.
- longexposuretime: This parameter determines whether the Unix
system is controlling the length of the exposure, or whether it is controlled
by the CCD controller. Historically the exposure times have always been
controlled by the CCD controller; this time should be extremely accurate.
However, in order to implement the ability to change the exposure time,
it was necessary to let the Unix system take over the timing. The default
value of 300 seconds means that for exposures longer than 300 seconds, the
Unix system is doing the timing; this is believed to be good to or 2
seconds (regardless of exposure time) but we don't know this for a fact, yet.
times shorter than this value cannot have their exposure times lengthened.
If you are never going to lengthen your exposure times ``on-the-fly"
(and why would you?) you might want to set this to a length greater than
your longest exposure time; this will assure accurate exposure lengths.
Tue Feb 14 07:48:00 MST 1995