Several data reduction recipes are provided for UIST with ORAC. The template observing sequences discussed above contain recipes appropriate to the associated observing mode. Please take care when changing DR recipes; many have specific requirements in terms of darks and flat fields, which must be acquired before a target observation is obtained and reduced on-line. Tables of available DR recipes – and links to detailed descriptions of them – are available. If a special reduction recipe would be useful to you, please contact your support scientist – we may be able to produce something specific to your needs, though we do need to be notified well in advance of your run at UKIRT.
To run ORAC-DR while at the telescope simply type
The software will then point to the current night’s data directories. (If you wish to reduce, say, the previous nights data, you can specify the UT date on the command line, e.g. oracdr_uist 20001031 .) The above command should be followed by
oracdr -loop flag
Two windows will open: an ORAC text display and – when the first exposure is completed – a GAIA window which will automatically display data frames. The pipeline will reduce the data as they are stored to disk, using the recipe name in the image header.
The pipe-line is meant to run without interference from the observer. Thus, although you can use the various GAIA tools to examine images, the pipeline should not need to be stopped and/or restarted. If, however, you do need to re-reduce a block of data, this is possible with the command
oracdr -loop flag -from 199
oracdr -loop flag -list 199:210
Specific calibration frames can also be used. For example, a 9-point jitter with a very short exposure should not use the “self-flat” from a JITTER_SELF_FLAT recipe, because of insufficient signal in the background for the flat-fielding. Instead, a separate sky-flat should first be acquired, and this later specified on the command line (when re-reducing the data), viz.:
oracdr BRIGHT_POINT_SOURCE -list 31:40 -calib flat=flat_J_7
Note this forces the DR to use the BRIGHT_POINT_SOURCE recipe and the frame “flat_J_7.sdf” for the flat-field division (BRIGHT_POINT_SOURCE would by default use the flat with the correct filter taken nearest to the target).
Help on this and other ORAC-DR topics is available by typing
To exit (or abort) ORACDR click on EXIT in the text log window, or type ctrl-c in the xterm. The command oracdr_nuke can be used to kill all DR-related processes, should you be having problems.
Reducing data at your home institute
To reduce data anywhere other than at UKIRT you must of course install orac-DR, which is part of the starlink collection. The software is (freely) available here: http://starlink.eao.hawaii.edu/starlink.
To run ORAC-DR you again specify the instrument with:
However, you must also tell ORAC-DR where the raw data are, and where the reduced data are to be written:
setenv ORAC_DATA_IN /export/data/cdavis/myrawdata/ setenv ORAC_DATA_OUT `pwd`
The second command tells ORAC-DR to write the reduced data to the current directory.
Finally, reduce your data in blocks as described above using the -list option. Note that you must always reduce the array test observations taken at the start of each night first, since ORAC-DR uses the readnoise measurements and bad pix mask created from these observations. Usually there are about a dozen observations taken as part of the array tests – check the night’s observing log for details.
If more than one co-add is used, then users should note that the “co-added” frames are in fact averaged. In other words, the data values, or counts, in each raw frame correspond to the exposure time of one co-add. Similarly, the frames that comprise a jitter pattern are also averaged by ORAC-DR. However, please note that if a jitter sequence is repeated the mosaics that result from each jitter pattern are added to give the final, “master” mosaic. As an example; if you expose with 10secs x 2 coadds, and you repeat a nine-point jitter pattern three times, the integration time equivalent to the counts in each of the three mosaics will be 10 seconds. The integration time in the final, master mosaic (the sum of the three seperate mosaics) will then be 30 seconds. In all cases the integration time written to the fits header always reflects the averaging or addition of frames described above. Division by the integration time given in the header will always give data calibrated in counts/second.