November 19, 2014 at 2:01 am #726
I’ve been trying to reduce some new data from the GMOS-S IFU. I’m using ureka and have installed the patches for the new CCDs and have updated the headers as they say to do on this webpage: http://www.gemini.edu/?q=node/12227
I’m getting stuck in two spots. First, the fiber IDs — I keep getting an error in gfcube saying num image rows != num good fibres in MDF. I’ve copied over the MDF from gmos$data, told it which fibers should be on/off, and told iraf where the new mdf is. I’ve also hand marked each aperture when we get to that step in gfreduce. I’ve done this many times now and the MDF and my IDs seem to match just fine, but I’m still getting an error. Second — when using gfdisplay, I get an error saying ldisplay configuration does not match image. In the parameters for gfdisplay, config is set to default (I don’t think I’ve ever changed it from that…)
I’ve been able to successfully reduce data from previous semesters with my current iraf setup, so I don’t think it’s something with my installation.
Has anyone else seen these errors, or have any ideas on how to fix them?
Thanks in advance!
November 25, 2014 at 6:48 pm #740
- This topic was modified 4 years, 10 months ago by Joanna Thomas-Osip. Reason: adding tags
[Below is what I have just sent you in the HelpDesk ticket you had submitted, posting here for all users to see.]
Good news is that I reproduced your issues and have suggestions that should fix them.
Firstly, the gmos ifu example is very outdated (it is under review for updating). The gfdisplay call need not have the ‘config’ and ‘deadfib’ changed from the default value of “default”, assuming that is what you have done. With your current installation of the Gemini IRAF package (assuming v13_comm_patch1), leaving these parameters to their defaults, you should be able to display your data. From the available help of gfdisplay:
config = “default”
The name of the LDISPLAY configuration file with relative
lenslet positions. The default will use information in the the
MDF to construct the configuration file. The name will need to
be specified for data reduced with MDFs that do not have
columns XLDIS,YLDIS (see below).
deadfib = “default”
Name of the LDISPLAY dead fiber configuration file. The
default will use information in the the MDF to construct the
configuration file. The name will need to be specified for data
reduced with MDFs that do not have columns XLDIS,YLDIS (see
This leads me to your gfcube issue. Basically, the number of fibers that were extracted (the Y dimension, NAXIS2, of your extracted FITS file) does not match the number of good fibers recorded in the MDF. The MDF contains an entry for every fiber in the GMOS IFU, however, some of those fibers are ‘dead’ fibers. In the MDF they are recorded as so in the “BEAM” column by setting the value to -1. Unfortunately, the MDF is not updated by the scripts if you manually exclude (or apall excludes) a fiber. So, one way to fix this is to find the entries of the fibers in the MDF that were excluded by yourself and set their ‘BEAM’ value to -1. However, I’ve just created a new MDF specifically for Hamamatsu data IFU-R (taken from an MDF for Hamamatsu IFU-2 data made by a colleague) and reduced your data with it. The reduction completed without any errors. I used the commands you have written as part of this ticket, bar using the gfdisplay parameters commented on above. I will send you the new MDF (assuming IFU-R) and required files to use it, which excludes 6 additional (sky) fibers that fall off the top of detector.
Once again my apologies for the late response.
Instructions on how to use the new MDFs:
Unpack in a directory of your choice (or preferably in gmos$data/):
tar xvzf /path/to/download/ifu_mdf_HAM_fixes.tar.gz
Then reduce data as normal except in the gfreduce call:
set the ‘mdffile’ parameter to the appropriate MDF:
gsifu_slitr_mdf_HAM.fits for IFU-R
gsifu_slitb_mdf_HAM.fits for IFU-B
gsifu_slits_mdf_HAM.fits for IFU-2
And set the ‘mdfdir’ parameter to the directory to where you unpacked the files, e.g., gmos$data/ [which is technically the default].
Attachments:January 5, 2015 at 3:52 pm #767
I’ve been working on GMOS-S IFU data as well. Everything worked quite alright, however I found that my data is quite noisy. One feature is around 6000 AA, which I believe corresponds to amp#5 (it always looks funny in the raw images). Has anyone seen this feature also?
It can be suppressed to some extent by fitting the overscan with high order function, but cannot be perfectly removed. In the standard star data it’s quite negligible as the signal is strong, but in low S/N data this is rather annoying.
Hanin.January 26, 2015 at 2:01 pm #774
Sorry no-one has replied to this before now (at Gemini we have been rather busy preparing a new release of the IRAF package).
I’m not aware of a persistent artifact on amp #5; that could be where the IFU slits overlap in 2 slit mode or scattered light, but of course those things don’t disappear at high S/N. If you’d like me to look at the feature, would you send some more details, please — eg. an image or the programme number? You can, of course, contact the helpdesk if you prefer.
James.February 13, 2015 at 2:37 am #789
Thanks for your reply. Here is an example of a raw science exposure (displayed on ds9, 90º rotation using the IRAF command gdisplay):
As you can see the amp#5 looks strange with the patterns, and here is the overscan fit:
For the other amps, the fits look normal, with more less flat overscan, whereas for amp#5 there always this huge jump.
The noise in this amp is translated into the spectra around 6000AA region, as you can see in this plot of extracted spectra:
The program was GS-2014B-Q-53 (IFU 1-slit mode), and this problem shows up only for data taken with 4×1 binning (taken in December or after). I haven’t tried the new IRAF package but shall look into it.
Please let me know if you have any suggestions on this.
Thank you in advance,
Hanin.February 16, 2015 at 8:26 pm #790
It looks like this is a detector artifact associated with a saturated column (~1175) for spectrally-binned data. It’s also there for at least one other programme with 2×1 binning taken close in time. We do see a similar problem where detector rows coincide with saturated stars for Hamamatsu imaging but I had not seen a case before where the bias for the whole amp is knocked out by a bad column and I’m a bit surprised it wasn’t noted in the logs.
Unfortunately the instrument scientist has just left for a couple of weeks, so I can’t check what he knows about it, but someone else from the GMOS team is going to look into this a bit. I hope once the effect is characterized a bit better, we’ll have a slightly clearer idea what to do about it.
Do I understand from your last plot that the general pedestal on that amp isn’t subtracting out nicely? Also, how important is this region for your analysis (feel free to email us about that)?
James.February 16, 2015 at 9:24 pm #794
I see other cases where this saturated feature is much shorter (<200 rows) and does not affect the whole column, which probably explains why it isn't better known. I was thinking it might be dark current spilling over after some exposure time but from looking at a few more images it does not appear to vary consistently with exposure time -- rather, it affects all the December data I've looked at. I have also seen cases with the older GMOS detectors of saturated colums varying in extent between exposures (but without the knock-on consequences). Anyway, I'm not the detector expert and for the time being will leave it to the GMOS team to comment on further.March 2, 2015 at 3:32 pm #822
Thank you for looking into this. Hopefully there will be more updates on how to deal with this problem. Fortunately the spectral region is not so important for my purpose, so it’s quite OK. But of course it would be very nice to have the spectra without that noise.
Yes, the overscan pedestal cannot be subtracted cleanly using low-order functions. I had to use high order functions (~95) to subtract it, but it’s still not very clean. Overscan subtraction also only works along line, while the pattern is 2-D (line & column). Subtracting the bias also did not remove the noise.
Hanin.March 2, 2015 at 4:09 pm #823
You must be logged in to reply to this topic.