obspars

  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 Fig. 1). 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 focus manually.

• 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 the 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. Setting this 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. Exposure 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.