Basic GMOS-IFU data reduction is done through the Gemini IRAF package. In general this is well designed, fully functional and well documented. It will process your data through bias subtraction, flat fielding, extraction, sky subtraction, CR rejection, flux calibrating, and converting to cube format.
In total, there are eight basic steps to reducing a single object frame in order to get it to the point where the signal to noise is high enough, and may be converted to a data cube for extraction of the kinematics. Briefly, these steps are as follows: bias subtraction, diffuse light correction, cosmic ray removal, spectrum extraction from the ccd, flat fielding, wavelength calibration, sky subtraction, and the flux calibration. Before these can be completed on the science frames, the flat, bias, sky, flux, and arc frames all need to be reduced and extracted from the CCD. In general GMOS-N and GMOS-S instruments are identical, but the calibration data are unique to each instrument as is the field-to-slit mapping. GMOS-S is Nod and Shuffle capable which changes the field-to-slit mapping significantly. More information about this can be found at: GMOS IFU Field-to-slit mapping
New things:
New Gemini package release: about data processing software
Some things to watch for:
- The GMOS instrument has developed a problem where one fibre drops off every now and then (possibly to do with flexure and the elevation of the instrument). The pipeline does not deal with this automatically. Since the missing fibre does not get identified in the 'extract' task, there is a mismatch between the number of identified fibres/apertures and the the number in the position table (MDF file) which is attached with the gfprepare task. The solution is to manually remove (switch off) this fibre in the MDF file before attaching. To work out which one is being dropped run the gfextract task interactively (fl_inter+) and check at on the screen which fibre isn't being recognised (2 slit mode usually around fibre 420 or 750). To switch off the offending fibre in the MDF file (e.g. fibre 750 for 2-slit mode), type this:
> copy gmos$data/gnifu_slits_mdf.fits .
> tcalc gnifu_slits_mdf.fits BEAM "if NO == 750 then -1 else BEAM"
- For 2-slit mode, small pixel offsets between the two pseudo slits have been found that are not removed by the wavelength calibration. The reason for this is not understood but one workaround is to use the arc to determine the shift and then apply it to the science data. If you think this is a problem for your data, you should contact the Gemini helpdesk for more information. If you want to look for this effect, the best way to check for it is to extract the kinematics from some twilight flats. Many times the shift between the two pseudo-slits is not more than around 2-3 km/s but could be as much as 5-10 km/s. Check what this offset might be and if it is outside your errors, then the best way to handle it is to convolve one half of the spectra up to the resolution of the other. Not correcting for this beforehand could lead to errors down the line in subsequent analysis maps. Below is an example of what this extraction would look like.
- It is also a good idea to do the wavelength calibration manually. Sometimes the automatic routine to find the arc lines incorrectly identifies strong but spurious lines which will ruin the solution. The best way to handle this is to stop the routine at the wavelength calibration and choose the interactive mode. From here, you can delete all the arc lines iraf has tried to fit and only choose the 20 or so strongest ones. An example of this follows:
- Another thing to check for in two slit mode is any signature of a color term difference between the three chips. Sometimes this is referred to as a quantum efficiency correction. As the spectra are read out onto 3 CCDs from the two pseudo-slits, the flux calibration does not always do a great job. The reason is that one pseudo-slit is read out onto 1 CCD and a half. Since you normally only get a response curve for just one of the slits which you then apply to both, the color terms from each chip might cause one half of one spectrum to be more sensitive in the blue and the same half of another spectrum to be more sensitive in the red making it hard to flux calibrate them both with the same curve. This can be solved by using the central CCD as a reference and do a first order flux calibration to get the spectra aligned. Once this is one, the levels of two adjacent spectra in the FOV but which come from different pseudo-slits should have approximately the same shape which can then be corrected to a higher order by the standard flux calibration.
- gfcube should be run with a minimum ssample=0.1. If you want to convert to cube format, you're going to have to resample anyway since you need to convert from hexagonal to square spaxels, and a value of 0.1 avoids losing data at the edges of the field. The downside is that you've now doubled the number of spaxels per field!
- An unofficial modified pipeline exists (ifuproc) that includes lacosmic CR rejection, quantum efficiency correction, an updated set of BPMs, and other bug/parameter fixes. Unfortunately this is only available from Gemini support scientists on request.
- gfreduce weights="none": A postdoc (who shall not be named) was analyzing the Gemini GMOS-IFU 2-slit mode data for a sample of quasars. Following the standard example script of data reduction (task "gmosexamples" in the gmos package), he find that the output science image of the main reduction task "gfreduce" always show increased noise in the upper-right quadrant, downgrading the quality of our science data when the source emission happens to be there (see figure). The higher noise also exists in the bottom-left quadrant in this figure, although it does not seem to be as harmful.
After suffering lots of painful requests and waiting which bothered him for several weeks, the solution turns out to be, however, very simple. GMOS guru Mark Swinbank pointed out that if the parameter gfreduce.weight is set to be "none" instead of the default "variance", the problem will be solved. The following figure was created with all the same parameters as the above except for the weighting, and no weighting leads to a much cleaner result (note I did not remove cosmic rays here).
