Home › Forums › Gemini Data Reduction › trouble reducing GMOS-S longslit data with Hamamatsu chips
This topic contains 11 replies, has 3 voices, and was last updated by jturner 2 years, 8 months ago.
-
AuthorPosts
-
March 3, 2015 at 6:29 pm #824
Hey all,
I’ve been working with my data received over 2014B on Gemini South. It’s basic longslit spectroscopy, but since the chips have changed, I’ve been having trouble reducing the data. For example, I’ve attached a *.png of the extracted Standard Star data. There seem to be some large discontinuities in the extraction. Is anyone else seeing this kind of problem?
-
This topic was modified 1 year, 8 months ago by
achene.
Attachments:
March 5, 2015 at 9:31 pm #826Hi Jesse,
Are you using the latest v1.13 of the Gemini IRAF package and applying the new “QE correction”, as illustrated by “gmosexamples MOS” (sorry there isn’t an updated long slit example yet)? I’m not 100% certain this isn’t something else, but your discontinuities look at least qualitatively like the kind of thing one might expect due to differences in QE variation with wavelength between the chips; also see “help gqecorr”.
Thanks,
James.
March 5, 2015 at 9:34 pm #827PS. If you find gqecorr helps, I’d appreciate it if you could find time to post the same plot after correction, to see how well it does in this case.
May 6, 2015 at 7:49 pm #888Hi there JT,
I am indeed using v1.13 but I’m not applying the GQECORR you speak of. I’ve attached a txt file with the gmosexamples MOS you’re talking about, is this the correct one? I just want to make sure I’m not using an outdated example.
I’ve also attached my own reduction commands in ‘standardRedux.cl’ so that you can see how I generated the plot above.
best
Attachments:
May 7, 2015 at 3:52 pm #891Thanks. Yes, that’s the example.
James.
May 28, 2015 at 1:49 pm #901I am also having some issues reducing GMOS-S data–both imaging and spectra–with the new Hamamatsu chips. These look like they may be due to differing QE between the 3 chips.
Looking at the parameter files for both gireduce and gsreduce, the parameter fl_qeco (which turns on QE correction) has a note “not yet implemented”, so I have left it turned off. (I am using ver 1.13 of the gemini package). Is this wrong? or do I introduce QE correction somewhere else?
Thanks!
FrankMay 28, 2015 at 3:52 pm #902Right, those flags to apply the correction as part of the process are not available yet — you have to run the stand-alone “gqecorr” task separately. See its help page and the MOS example for how to do that (unfortunately there’s no updated long-slit example yet). For imaging it should be relatively trivial to add — you just need to make sure you either apply it to both the science and flat images or neither of them (in which case I believe the QE differences should come out in flat fielding anyway).
Cheers,
James.
May 28, 2015 at 7:41 pm #904Hmmm … I am not finding either the gqecorr task, nor the gmosexamplesMOS.txt file referred to in a previous post. When I try
gmos> gmosexamples MOS
I get an example from 2002, which clearly long predates the Hamamatsu chips, and has no mention of qecorr. What am I missing here?I’m also not able to download that .txt file from the previous post.
thanks,
FrankJune 18, 2015 at 4:10 pm #923Frank,
Are you sure you are not overriding the Gemini IRAF package version in your login.cl or loginuser.cl file? What happens if you do “mkiraf” in a new directory and start IRAF/PyRAF there? If you don’t have gqecorr or the revised example, you must somehow be seeing an older Gemini package version than 1.13.
File downloads are supposed to have been mended now but I still can’t get the above files so will look into it.
Sorry no-one commented on this sooner.
Cheers,
James.
-
This reply was modified 2 years, 10 months ago by
jturner.
July 9, 2015 at 6:01 pm #941I’m working through the MOS example from above, (though it’s on longslit data) and I’ve run into an error. Do we have any idea what could cause this. It occurred at the step AFTER the gqecorr. I re-mosaiced the QE-corrected data for gsflat as previously done, and then i ran the gsflat again to correct for the QE variations. This error came up:
$> gsflat mqgsgS20140827S0087.fits temp_flat.fits order=29 fl_over- fl_trim- fl_bias- fl_usegrad+ refimage=temp_flat_comb.fits fl_keep-
ERROR: Attempt to access undefined local variable `y1′.
“y1 = nint(y1 – l_yadd/ybin)”
line 935: gmos$gscut.cl
called as: `gscut (inimage=tmpcombflat1519oj, outimage=tmpscisec1519tj, secfile=tmpsecfile1519kj, fl_update=yes, fl_vardq=no, fl_oversize=yes, gratingdb=gmos$data/GMOSgratings.dat, filterdb=gmos$data/GMOSfilters.dat, gradimage=tmpcombflat1519oj, refimage=temp_flat_comb.fits, xoffset=INDEF, yoffset=INDEF, yadd=0., w2=INDEF, logfile=GS.standard.log, verbose=yes)’
“w2=l_upper_wave_limit, refimage=l_refimage, gradimage=l_gradimage)”
line 1254: gmos$gsflat.cl
called as: `gsflat (inflats=mqgsgS20140827S0087.fits, specflat=temp_flat.fits, fl_keep=no, fl_over=no, fl_trim=no, fl_bias=no, refimage=temp_flat_comb.fits, fl_usegrad=yes, order=29)’July 9, 2015 at 6:58 pm #942We think we might know where the error lies. Since we’re doing longslit, the modobs keyword in gscut would be set to ‘LONGSLIT.’ But when looking in the gscut.cl file (where we think the error happens), if the LONGSLIT mode is enabled, it runs this:
else if (modobs == “LONGSLIT”) {
dx = 0. # the distortion correction, IJ
specwid = real(nypix)
center = specwid/2.
xccd = xcen
yccd = center
priority = 1
}and there is no scan for ‘y1’ as is in the MOS mode.
So we added text from the MOS mode to the .cl file, it now looks like this:else if (modobs == “LONGSLIT”) {
if (l_refimage != “”) {
tprint (l_refimage//”[MDF]”, prparam-, prdata+, showrow-,
showhdr-, showunits-,
col=”SECX1,SECX2,SECY1,SECY2,EXTVER,REFPIX1,priority,\
SPECCEN”, rows=n_i,pwidth=160) | \
scan (x1, x2, y1, y2, n_j, refpix, priority, speccen)
printlog (“Read parameters for slit “//n_i,
l_logfile, l_verbose)
} else {
print (“refimage not defined, so I will crash”)
}
dx = 0. # the distortion correction, IJ
specwid = real(nypix)
center = specwid/2.
xccd = xcen
yccd = center
priority = 1
}This doesn’t break. which is good!
we’re going to move forward like this, could anyone indicate if this is a good patch?
-
This reply was modified 2 years, 9 months ago by
jesse.rogerson.
August 11, 2015 at 12:22 am #955Just catching up with the forum after travel…
This question also came up in the helpdesk and my understanding is that it happens when following the MOS example too closely for long-slit data (I know the long-slit one doesn’t include QE correction yet). When working with long-slit data, the fl_usegrad option should be set to “no” and “refimage” & “gradimage” left blank. Does that solve your problem? If the above patch works for you then great, but I’m told by the person that looked into this that it’s not a general solution. Thanks for posting it for other people though. We’ll change gscut in the next release to trap this condition properly.
Cheers,
James.
-
This topic was modified 1 year, 8 months ago by
-
AuthorPosts
You must be logged in to reply to this topic.