![[Science Operations home]](../../generic-images/sciopshomebtn.gif){kind=small}
![[OSCIR home]](oscirhomebtn.gif){kind=small}
Summary of OSCIR Quickstart Run: November - December 2000 |
The Gemini North OSCIR Quickstart program was conducted during a single observing run between November 20 and December 10, 2000. The following is a summary of the run which will be useful to PIs and Co-Is reducing OSCIR data. These descriptions are not intended to be exhaustive and do not cover all the issues that may arise when reducing OSCIR data; please contact the Gemini Contact Scientist assigned to your program for further assistance.
The "raw" data files in the OSCIR Quickstart distribution are the exact files written by the instrument computer during the observations, except for modifications to a few header records made by Gemini personnel during post-processing to indicate data quality. The files are 6-dimensional FITS format (see a detailed description of the OSCIR data format). Gemini has developed an IRAF package for basic manipulation of the files; an alternative IDL package is also available from the University of Florida.
The OSCIR FITS headers list many observing parameters for the instrument (filter, integration time, etc.), telescope (pointing data), and observation (Program ID, Observing conditions, Data Quality). Processors should familiarize themselves with the information.
All the instrument parameters were written automatically by the OSCIR software based on the instrument settings at the moment of the observation. Telescope pointing data was also written automatically after being read by the OSCIR computer from the telescope control system (TCS) through a special interface. Therefore, the values of these parameters are reliable (within the uncertainties of the telescope pointing, etc.)
Some header records, such as the object name, the observing conditions, and the data quality, were set manually either during or after the observation. We have endeavored to verify that these header records are correct, but they may be in error and caution should be exercised. To verify an OBJECT keyword value of "Alpha CMa", for example, you can check that the automatically-written RA_TEL and DEC_TEL records actually contain the coordinates for Alpha CMa.
For each Quickstart observing program, we have included in the distribution all data taken for that program that appeared to be a valid observation. We have excluded files for which there were significant instrument- or telescope-related problems (e.g. the detector was saturated, or a large pointing error was evident). However, we have not excluded files with problems such as poor image quality, higher than usual noise due to detector problems or cirrus clouds, and so forth. Such problems are noted in the observing log and FITS headers. It is important for a data processor to understand the quality of the data and judge its scientific value carefully.
For good-quality OSCIR data, Gemini has supplied pipeline-reduced files. The pipeline reduction produces a single 2-D image, usually representing the average of all the chop & nod differences computed from the file. The file was generated using the IDL/UF routine F6GET.
In some cases, when one or more savesets in an integration were noted to be bad during the observations (e.g. due to clouds or a temporary instrument problem), the bad savesets were omitted from the average. Details on the omitted bad nod and savesets are contained in the BNOD and BSET parameters in the headers of the pipeline-reduced files.
PLEASE NOTE: The pipeline reduction is only a first attempt by Gemini personnel to provide an approximate reduced image. Better results are likely to be obtained by more careful analysis of the raw data to delete bad savesets, shift-and-add individual savesets, etc. It is the responsibility of the PI to reduce the raw data in the best possible way, although Gemini Contact Scientists and Instrument Specialists can provide assistance upon request.
Supplemental files are described in the GNQSdata_readme.txt file included with the data distribution. Here are a few additional notes on these files.
Background Plots: For each pipeline-reduced file there is a GIF file showing the signal level in the "reference" (off-source) frames throughout the integration (generated using the IDL/UF routine f6bstat). The "square-wave" steps visible in these plots occur when the telescope nods and the reference switches between chop beams A and B; they illustrate the so-called "radiative offset" between beams A and B. You may also be able to see smaller steps between individual savesets.
At Gemini, the radiative offset is usually less than one percent of the background signal. If it is larger than normal, one of the chop beams may have been partially on the dome. If the "square-wave" pattern is lost in very large random variations, there may have been clouds.
Processors of OSCIR data should be aware of the following issues pertaining to the December Quickstart run. Again, please consult the Gemini Contact Scientist assigned to your program for details.
An occasional problem during the OSCIR run was a loss of synchronization between the OSCIR detector and the chopping secondary, usually at the start of an integration when the chopping was turned on. The main symptom of this problem was "negative images", seen when the subtraction of the two chop phases in the OSCIR display software became inverted. When we saw negative images on the display, we typically aborted the integration immediately to reset the chopping, and such aborts are noted in the observing log. These files do not contain useful science data and therefore were not included in the QS distribution.
We believe that we have identified and rejected most of the data with chop-sync problems, but all data processors should be aware that such problems may still exist in their raw data. Careful examination of the individual savesets with respect to signal polarity and background level is the best way to ensure that the data are OK.
One of the 16 channels of the OSCIR detector electronics was inoperative during this run. This causes every other pixel in every 8th row to be bad - an effect clearly visible in most images.
The effect of the missing pixels can be mitigated by interpolating surrounding pixels or filtering the data. This was not done as part of the pipeline reductions.
On a few nights, we experienced pickup or interference in the detector electronics, which caused diagonal bands on the OSCIR detector. We currently do not have a way to eliminate these bands from the data.
Slight wedges in the filters cause images to move slightly on the OSCIR detector when the filter is changed. The largest wedge is in the 10.3 micron filter, which caused images to move 20-30 pixels toward the lower right of the detector. The exact difference between the filters can be measured from the sets of baseline calibration images that include all the filters.
Most QS programs did not list accurate pointing as a high priority, so we usually executed the following standard routine when acquiring sources.
On a star bright enough to see on both the Gemini Acquisition Camera (AC) and OSCIR, we measured the AC "hotspot" corresponding to the center of the OSCIR detector in the N-band filter (see the discussion of filter wedges above). Then, for each science target, we first slewed to its Peripheral Wavefront Sensor (PWFS) guide star and set it on the AC hotspot, and absorbed any offsets into the pointing model. Finally, we slewed to the science target, itself (~4-6 arcmin away) and set up the guiding as quickly and accurately as possible without further moving the telescope.
In a few test cases, this placed the science target on OSCIR to within about 1 arcsec, although on some science targets we felt that the error may have been up to ~2 arcsec. The main sources of error were probably telescope drift during the guiding setup, flexure between the PWFS and OSCIR, and perhaps differential refraction between visible and 10 microns. We did not have sufficient time during this run to characterize flexure at all zenith and Cassegrain Rotator angles.
All OSCIR science images were taken with the Cassegrain Rotator in "follow" mode, meaning that it rotated as the telescope tracked an object to maintain the science detector at a fixed position angle on the sky. East is ~ up and North is ~ to the right on the images. There was an approximately 9 degree angle between the OSCIR detector rows and columns and the cardinal directions (N,S,E,W) on the sky, so that the detector rows are at PA ~ 351 and the columns are at PA ~ 81. This angle was measured from images of the Orion-KL region. The observations of the Orion-KL region are released as System Verification (SV) data, program GN-2000QS-SV-5. The field rotation data are specified in the FITS header by the keywords PAX and PAY, which were added during post-processing.
All OSCIR data were taken with the telescope active optics (control of the M1 figure and the M2 position) in "open loop," meaning that the parameters were under control of an elevation-dependent lookup table. We occasionally tuned the M1 figure with a procedure using PWFS1 at the start of a night, but the active optics were never under real-time "closed-loop" control of PWFS1. As a result, various aberrations, usually a small amount of astigmatism, were visible in the point spread function, and the aberrations varied slightly with time and elevation due to imperfections in the open-loop model.
Data processors wishing to do critical PSF comparisons or deconvolutions should pay close attention to these issues and the stability of the PSF.
All QS science data were taken with the secondary mirror chopping and "fast guiding." Fast guiding means that the secondary was making "tip-tilt" corrections at a bandwidth of ~20 Hz under control of PWFS2. For stars down to V ~ 12-13, the PWFS2 frame rate was 200 Hz, its highest speed, with 2x2 rebinning of the sensor pixels. For fainter stars, PWFS2 was operated at either 100 or 50 Hz with no rebinning.
These guiding parameters were not automatically written to the FITS headers, so they were recorded manually in the obslog file.
The quality of the guiding is sensitive to the seeing and to the wind speed and direction. On most nights during the OSCIR run, the wind speed was not high enough to cause severe guiding problems.
Closing the focus loop with PWFS2 while chopping was not possible during this run. Instead, we took care to check and adjust the focus manually during most baseline calibrations, and on science targets themselves if possible. Changes in focus were often noted in the log and can also be determined from the TELFOCUS FITS header record.
Each night's observations included one or more Baseline Calibrations: a series of standard star observations taken for flux calibration purposes. A single Baseline Calibration data set often covered multiple science programs, so for each program Gemini is distributing a separate CD-ROM containing all available calibration data from at least the nights the program was executed. Because of time constraints, we often tailored the calibrations to the programs planned for the night (or the next few hours), so some calibrations included just one filter while others included all filters.
We obtained flat field data using two techniques: (1) Taking images of blank sky at two or more different airmasses, and (2) Taking images at a fixed airmass with and without a sheet of polyethylene over the OSCIR window. Both techniques change the background signal on the detector by a small amount, so that the relative responsivity of each detector pixel can be measured.
Several effects complicate the derivation of flat fields from these data. The main problem is that the flat field includes variations from both the detector and the OSCIR optics. Due to flexure in the instrument, the optical component moves on the detector as the instrument angle changes. To provide a correct flat field, the optical and detector components must be decoupled from the available flat-field data, then recombined for the instrument angle at each observation. We are still attempting to construct suitable flat fields and understand the limits on their accuracy.
In original form; Tom Hayward
Last update February 6, 2001; Phil Puxley