trouble reducing GMOS-S longslit data with Hamamatsu chips

Home › Forums › Gemini Data Reduction › trouble reducing GMOS-S longslit data with Hamamatsu chips

Tagged: , , , ,

This topic contains 11 replies, has 3 voices, and was last updated by  jturner 4 years, 9 months ago.

Viewing 12 posts - 1 through 12 (of 12 total)
  • Author
    Posts
  • March 3, 2015 at 6:29 pm #824

    jesse.rogerson
    Participant

    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 3 years, 10 months ago by achene achene.
    Attachments:

    1. standardStar.png

    March 5, 2015 at 9:31 pm #826

    jturner
    Keymaster

    Hi 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 #827

    jturner
    Keymaster

    PS. 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 #888

    jesse.rogerson
    Participant

    Hi 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:
    1. standardRedux.cl
    2. gmosexamplesMOS.txt
    May 7, 2015 at 3:52 pm #891

    jturner
    Keymaster

    Thanks. Yes, that’s the example.

    James.

    May 28, 2015 at 1:49 pm #901

    Frank.Winkler
    Participant

    I 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!
    Frank

    May 28, 2015 at 3:52 pm #902

    jturner
    Keymaster

    Right, 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 #904

    Frank.Winkler
    Participant

    Hmmm … 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,
    Frank

    June 18, 2015 at 4:10 pm #923

    jturner
    Keymaster

    Frank,

    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 4 years, 11 months ago by  jturner.
    July 9, 2015 at 6:01 pm #941

    jesse.rogerson
    Participant

    I’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 #942

    jesse.rogerson
    Participant

    We 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?

    August 11, 2015 at 12:22 am #955

    jturner
    Keymaster

    Just 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.

  • Author
    Posts
Viewing 12 posts - 1 through 12 (of 12 total)

You must be logged in to reply to this topic.