You are here

Data Reduction Support

, Updated

  1. FAQ about the Gemini IRAF package

  2. Scisoft Problems related to the Gemini IRAF package

  3. Other Known Problems (and workarounds, where possible) in the current and previous versions of the Gemini IRAF package

Submitting a HelpDesk Ticket

If you come across a new problem while using the Gemini IRAF package, please check the FAQ, Scisoft Problems, other Known Problems above, and make sure your are using the latest version of the Gemini IRAF package before submitting a HelpDesk ticket via the Gemini HelpDesk. You may also want to check the Gemini Data Reduction User Forum (see below). When submitting a HelpDesk ticket, please select "Gemini IRAF" as the "Topic" in the drop-down menu and include the following information, where applicable, so that your request can be dealt with efficiently: 

  • The output from the install_check task (which contains information about the installation and the operating system)
  • The program ID
  • The text of the error message
  • The call to the task that produced the error message, including the number(s) of the input file(s)
  • A complete copy of the parameter settings (type "lpar <taskname>" at the IRAF prompt, where <taskname> is the name of the task)

For a complete list of what you will be asked for and to see what procedure your First Responder will follow, check this document:  Data Reduction Helpdesk First Responder Guidelines.

Gemini Data Reduction User Forum This Forum is intended as a user-supported location for trading ideas, scripts and best practices, and taking part in user-driven public discussions of data reduction processes and strategies. If you have written a script, procedure, tip or other description of your own process which you think other Gemini users may find helpful in reducing their data sets, please consider posting here.

FAQ

 1) Is the Gemini IRAF package compatible with PyRAF?
  • Yes. Version 1.10 (and all subsequent releases) of the Gemini IRAF package is fully compatible with PyRAF.
 2) I have just installed the latest version of the Gemini IRAF package and now I am getting "ERROR: parameter `some-parameter' not found" messages. What am I doing wrong?
  • Some tasks in the version that you have just installed may have new parameters that do not exist in the old parameter files, which are found in the uparm directory. The solution to this problem is to initialise the uparm directory by typing "rm uparm/*" in your iraf home directory (i.e., where you ran mkiraf / where your login.cl file is located). This will remove any old Gemini parameter files that may be causing the problem. NOTE: if you wish to make a note of any stored parameters, please do so before running this command.
 3) How can I use regular IRAF tasks with my Gemini data?
  • The fitsutil package provides some helpful tasks that can be used to manipulate Multi-Extension Fits (MEF) files.
4) I am using gsreduce with fl_over+ to reduce my GMOS data but the output image contains negative pixel values. What am I doing wrong?
  • The processed biases in the archive are created using gbias with the fl_over parameter set to no. This means that the overscan level has not been subtracted from the processed biases. The solution to this problem is to either use the processed biases in the archive and then process all of your data with the fl_over parameter set to no OR do not use the processed biases in the archive; download the raw biases and reduce them using gbias with the fl_over parameter set to yes.
 5) I am using imcoadd to combine NIRI data, but I am getting "ERROR: Non-boolean operand used where boolean expected" messages. What am I doing wrong?
  • This error is due to a corrupted parameter file. The solution to this problem is to initialise the uparm directory by typing "rm uparm/*" in your iraf home directory (i.e., where you ran mkiraf / where your login.cl file is located). NOTE: if you wish to make a note of any stored parameters, please do so before running this command.
 6) I am following the GMOS Long-Slit / Multi-Slit Tutorial from the NOAO Gemini Data Workshop held in Tucson in 2010, but I can't find the gscrspec task that calls the Laplacian Cosmic Ray Identification routine (lacos_spec; written by Pieter G. van Dokkum) that is mentioned in the tutorial. Can I get a copy of this task?
  • The task gscrspec was originally written by Bryan MIller and is not supported as part of the Gemini IRAF package. It comes with no guarantees but you can download a copy here (updated May 14, 2013).
 7) I am unable to determine a wavelength solution for my NIFS arc (I see e.g., "No solution found" messages). What am I doing wrong?
  • This problem can occur when using a non-default central wavelength with NIFS. The nsappwave task adds a starting guess for the central wavelength to the header of the data using, by default, a value determined from a lookup table (the starting guess values are 1.05 for the Z grating, 1.25 for the J, 1.65 for H and 2.2 for K). Unfortunately, these values do not reflect the central wavelength actually used when not using the default position and can fail to provide a robust solution. To circumvent this problem, use the "crval" parameter in nsreduce (which is internally passed to nsappwave) to provide the actual central wavelength that was used (in Angstrom). The central wavelength value specified for the observation is stored in the header keyword "GRATWAVE" (nsappwave will only use this keyword if there is no value in the lookup table).
 8)  Where can I find more information?
  • Each task in the Gemini IRAF package has an associated help file. You can read this file by typing "help <taskname>" at the IRAF prompt, where <taskname> is the name of the task, e.g., nsprepare.
  • Each instrument specific package in the Gemini IRAF package has an associated "information" file. You can read this file by typing "<instrument>info" at the IRAF prompt, where <instrument> is the instrument, e.g., gmos.
  • There are a number of example reductions in the Gemini IRAF package. You can look at these examples by typing "<instrument>examples" at the IRAF prompt, where <instrument> is the instrument, e.g., niri.
  • Finally, for general IRAF issues, iraf.net is a good resource.

Problems using the Gemini IRAF package in Scisoft OSX installations

Numerous problems have been reported by users of the Gemini IRAF package when using a Scisoft OSX installation. Versions of Scisoft OSX containing IRAF v2.15 (i.e., those versions beyond and including version 2011.7.1) are incompatible with the Gemini IRAF package, since Scisoft OSX forces the use of the 64-bit version of IRAF v2.15 (the Gemini IRAF package is not compatible with with 64-bit version of IRAF v2.15).

In addition, the Gemini IRAF package is not compatible with IRAF v2.16, which causes problems for users of the Gemini IRAF package using those versions of Scisoft OSX containing IRAF v2.16.

Finally, some versions of Scisoft OSX contain out of date versions of the Gemini IRAF package and also incompatible versions of the fitsutil package, which can also cause problems for users of the Gemini IRAF package.

Known Problems

13 April 2015
Bug in gscut under IRAF CL

A bug in gscut (when using IRAF CL rather than PyRAF) produces an "Array subscript error" when checking to ensure that the reference column does not fall in a chip gap. Until the next release of the Gemini IRAF package, you can avoid this by using the following version of gscut (or by using pyraf instead):

gscut.cl

To use this task, the user can either:

1) replace gmos$gscut.cl in their Gemini installation with the above file; or
2) place the above file in any directory and re-define the task by typing "task gareduce=/path/to/gscut.cl" at the IRAF / PyRAF prompt (or in loginuser.cl) AFTER loading the gmos package.

20 January 2014
Minor bug in gareduce when dark subtracting (for Mac OS X > 10.6)

A minor bug in gareduce causes problems when dark subtracting using Mac OS X > 10.6. An updated version of the gareduce.cl file is available below, which fixes this bug. This updated file will be included in the next release of the Gemini IRAF package.

gareduce.cl

To use this task, the user can either:

1) replace gsaoi$gareduce.cl in their Gemini installation with the above file; or
2) place the above file in any directory and re-define the task by typing "task gareduce=/path/to/gareduce.cl" at the IRAF / PyRAF prompt AFTER loading the gsaoi package.

4 March 2013
Incompatibility with PyRAF 2.0 and the nifcube task

A bug in PyRAF 2.0 is known to cause problems with the nifcube task. An updated version of the nifcube.cl file is available below, which provides a workaround to the PyRAF bug. This updated file will be included in the next release of the Gemini IRAF package. STScI have found the bug in question and are currently working on a fix.

nifcube.cl

To use this task, the user can either:

1) replace nifs$nifcube.cl in their Gemini installation with the above file; or
2) place the above file in any directory and re-define the task by typing "task nifcube=/path/to/nifcube.cl" at the IRAF / PyRAF prompt AFTER loading the nifs package.

8 June 2011
Incorrect value of the initial wavelength for the GMOS-N CaT_G0309 fitler

The initial wavelength for the GMOS-N CaT_G0309 filter is incorrect in the version 1.10 release of the Gemini data reduction software. This will affect users who are reducing GMOS-N spectroscopic data taken with the CaT_G0309 filter. A new GMOSfilters.dat file is available below. The updated file will be included in the next release of the Gemini data reduction software.

GMOSfilters.dat

To fix the problem, the user can either:

1) replace gmos$data/GMOSfilters.dat in their Gemini installation with the above file; or
2) place the above file in any directory and change the default parameters referencing gmos$data/GMOSfilters.dat in the GMOS tasks to point to the new version.

4 March 2010
Incorrect values of the Y offsets for the new B600 grating

The Y offsets for the new B600 grating for GMOS-N are incorrect in the version 1.10 release of the Gemini data reduction software. This will affect users who are reducing GMOS spectroscopic data taken with the new B600 grating. A new GMOSgrating.dat file is available below. The updated file will be included in the next release of the Gemini data reduction software. For more information about the new B600 grating, please see this web page.

GMOSgratings.dat

To fix the problem, the user can either:

1) replace gmos$data/GMOSgratings.dat in their Gemini installation with the above file; or
2) place the above file in any directory and change the default parameters referencing gmos$data/GMOSgratings.dat in the GMOS tasks to point to the new version.

6 November 2006
FITCOORDS bug in IRAF 2.13beta2

There is a known bug in IRAF 2.13beta2 FITCOORDS. This will affect users of the Gemini package who are reducing spectroscopy data. At this time we know that the problem shows up during the reduction of NIFS data. It is likely to affect the reduction of the other spectroscopy data at the fitcoords/transform step.

We recommend that you upgrade your system to IRAF 2.14.

For the Mac Intel users who have to use IRAF 2.13beta2 for some reason, we suggest that you download and install the unofficial patch below. The fixed code was graciously provided by the IRAF group. The binaries were compiled at Gemini. If you encounter problems with it, contact Gemini.

fitcoords213b2-macintel.tar.gz
fitcoords213b2.README

20 February 2006
GNIRS - 2005B and on : two new database files are needed (Files included in version 1.9 and up)

Due to a change in the GNIRS cameras, two new database files are needed for reducing 2005B and on GNIRS short camera data with the Gemini/GNIRS IRAF package (v1.8.1). More information is available in an email sent to the GNIRS PIs, and the two files are available below. The updated files will be included in the next IRAF release.

21 September 2005
Problem with GSFLAT when fl_detec=no and more than one input flats (version 1.7 and 1.8; fixed in subsequent versions)

When several flats are used as inputs, GSFLAT uses only the first input flat in the list rather than a combined frame to derive the output flat. This only happens when fl_detec=no; the fl_detec=yes is not affected by this bug. The bug affects GSFLAT in Gemini v1.7 and v1.8. Patches have been made available for both 1.7 and 1.8 versions of the Gemini package:

Version Patch Download Instructions
1.7 gemini_v17_patch2.tar.gz gemini_v17_patch2.txt
1.8 gemini_v18_patch1.tar.gz gemini_v18_patch1.txt

10 November 2004
nsprepare crashes with bad WCS or fl_checkwcs- fl_forcewcs+ (version 1.7, fixed in subsequent versions):

The task nsprepare will crash if fl_checkwcs=yes (the default) and the WCS matrix has a negative determinant. This can be avoided by using fl_checkwcs=no. However, this then means that fl_forcewcs=yes cannot be used to correct the WCS. To use fl_forcewcs=yes and fl_checkwcs=yes together you must zero the values of the CD_ij elements in the PHU (using hedit) which will allow fl_checkwcs+ to be used without crashing (and so allow fl_forcewcs to be used too). Alternatively, you can download this nsprepare.cl file and replace the version of it that came with v1.7.

4 November 2004
nireduce crashing when fl_autosky=no (version 1.7, prior to November 8):

The task nireduce will invariably crash if fl_autosky is set to 'no'. This problem is caused by a typo that has been introduced in v1.7. Previous versions are not affected. You can download and install this patch to remedy the problem (instructions). If you have downloaded the v1.7 software from the Gemini web site after November 8, the new version of nireduce.cl is already included and you do not need to apply the patch. To verify the version that you are currently running start the CL, load the gemini package, and type print(gemini.version); if the version date is '25Oct2004', it is recommended that you install the patch.

4 November 2004
giflat and gifringe having problems with data binned 4 by 4 (version 1.7, prior to November 8):

The tasks giflat and gifringe do not set the default 'statsec' and 'normsec' correctly for GMOS data binned 4 by 4. You can download and install this patch to remedy the problem (instructions). If you have downloaded the v1.7 software from the Gemini web site after November 8, the new giflat.cl and gifringe.cl are already included and you do not need to apply the patch. To verify the version that you are currently running start the CL, load the gemini package, and type print(gemini.version); if the version date is '25Oct2004', it is recommended that you install the patch.

5 June 2003
gmosaic and binned images (version 1.4, prior to June 5, 2003, and version 1.3):

The gmosaic task to mosaicing the GMOS-N detectors does not correctly handle binned images. The bug affects images that are binned in X as well as images that have different binning in X and Y. For images binned in X, chip 1 and 3 were placed too far from chip 2 in the mosaiced image. For images with different binning in X and Y, the rotations of chip 1 and 3 relative to chip 2 was incorrect. Processing of multiple images with binning in X was also implemented incorrectly. The bugs have been fixed. In addition, the mapping of chip 3 relative to the other chips has been improved. If you have installed the Gemini IRAF package v1.4 prior to June 5, 2003, you can download a new gmosaic.cl file and replace the old version. You will also need new versions of the bad pixel masks included with the software: mgmos_bpm11.pl and mgmos_bpm22.pl. These files should be copied to the directory "gmos$data/" If you have downloaded the software from the Gemini web site after June 5, 2003, the new versions of gmosaic and the bad pixel masks are included.

Should I re-reduce my data? Imaging data with small dither steps show no significant effect. Unless you are doing high precision astrometry there is no reason to rereduce imaging data. For spectroscopic data the answer to the question depends on your science. The effect of the bug on data binned by two in the X-direction is a misplacement of chip 1 and 3 relative to chip 2 by about two unbinned pixels. If you are measuring high precision radial velocities or measuring precise linewidths by fitting template spectra to a large spectral range you may want to rerun part of the reductions for testing purposes. However, for measurements of redshifts the effect is too small to cause any significant effects on the results.

5 June 2003
gnsskysub task missing (version 1.4 only, prior to June 5, 2003):

The task gnsskysub for reduction of Nod-and-Shuffle data from GMOS is missing in the Gemini IRAF package v1.4. If you have installed the Gemini IRAF package v1.4 prior to June 5, 2003, you can download the gnsskysub.cl file and the help page and copy them to the directories "gmos$" and "gmos$doc/" in your installation. If you have downloaded the software from the Gemini web site after June 5, 2003, gnsskysub is included.

5 June 2003
gireduce unstable under Linux/Redhat (version 1.4 prior to June 5, 2003, and version 1.3):

It has been found that the use of the keypar task to access the image headers is not stable under Linux/Redhat. gireduce has been updated to use imgets instead. Other tasks affected by this will be updated in a future release of the Gemini IRAF package. If you have installed the Gemini IRAF package v1.4 prior to June 5, 2003, you can download a new gireduce.cl file and replace the old version. If you have downloaded the software from the Gemini web site after June 5, 2003, the new version of gireduce is included.

8 October 2002
mkpkg file missing (version v1.4 only, prior to Oct 8, 2002):

The top level mkpkg file was missing in the released version v1.4. If you have downloaded that version and you need to compile the software, you can download the mkpkg file here. If you have downloaded the software from the Gemini web site after Oct 8, 2002, the mkpkg file was included, and you do not need to download this file separately. The file is also not needed if you do not need to compile the software. Compilation is not needed for Solaris/UNIX and Linux operating systems.

25 September 2002
imcoadd (version 1.3 only) - incorrect use of limit parameter:

In the development of the Gemini IRAF package version 1.4 it was found that imcoadd released with version 1.3 has a bug in the cosmic ray cleaning. The use of the limit parameter in the case where this is given as a sigma limit above background was not implemented correctly. Only for the first image in the stack was the implementation correct. For the remaining images in a stack the limit in counts was set too high. The result is that the cosmic ray cleaning is done too close to the cores of the objects. For bright objects and images with differences in the image quality, this can result in compromised photometry. The bug is fixed in version 1.4. The bug was not present in releases earlier than v1.3.

25 September 2002
Missing header keywords (version 1.4 and earlier):

The Gemini IRAF package relies on the header keywords for many of the processing steps. Occasionally, the various tasks will fail to update the headers of intermediate processing steps correctly. As a result, later steps will fail. The behaviour is intermittent and has been reported most often under various versions of Linux. In some cases, the problem can be solved by re-reducing the images for which the reduction failed the first time around. In other cases, it has been reported that manually editing the headers of the intermediate results and then proceeding was a possible work around. It is possible that the underlying problem is in the core IRAF. When the Gemini IRAF package is ported to IRAF 2.12, we will document the problem in more detail and work with the NOAO/IRAF group to get the problem solved.

25 September 2002
MDFs not found in images (gmos package version 1.4 and earlier):

Occasionally, IRAF will fail attach an MDF to image even though the required flags are set correctly and the MDF exists. As a result, later steps will fail. The behaviour is intermittent and has been reported most often under various versions of Linux. The problem can be worked around by manually re-attaching the MDF using the task fitsutil.fxinsert. It is possible that the underlying problem is in the core IRAF. When the Gemini IRAF package is ported to IRAF 2.12, we will document the problem in more detail and work with the NOAO/IRAF group to get the problem solved.