jturner

Forum Replies Created

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

  • jturner
    Keymaster

    jturner
    Keymaster

    Hello,

    An arc from 13 days later should still be usable, but you cannot expect its zero point to match the science data precisely if it was not taken as part of your night-time observation (even on the same day). Even when pointing continuously at the same target, you are likely to see noticeable flexure within a couple of hours.

    The right thing is to refer to the sky lines for zero-point correction, as you have done. Often you can just go through the reduction process as far as “gftransform” and then edit the CRVAL1 keyword in the SCI header for each exposure (eg. using “hedit”) so that the final WCS matches your expected line wavelengths.

    Of course you may additionally want to make some heliocentric / barycentric correction to those observed wavelengths. If your observation happens to be split over multiple epochs, you might need to do that before you can stack all your data accurately (in which case you won’t be able to use sky lines to verify the final alignment).

    The errors you mention do seem a bit larger than I’d expect. My recollection is that the grating re-alignment is supposed to happen to an accuracy of <=6 pixels and that flexure on the telescope is of the order of a couple of pixels, so perhaps it wasn't quite as good as normal, but it sounds like that arc should still be usable. Do double check, however, that it's really the best matching one available and you aren't overlooking a closer one (often there are several). Cheers, James.

    in reply to: GMOS Longslit reduction problem: Unable to open logfile? #2021

    jturner
    Keymaster

    Hello,

    Can you rename or delete your existing log file, do “unset LC_TIME LC_ALL” (or if you are using tcsh “unsetenv LC_TIME LC_ALL”) and then try again, please? I think it may be a problem with IRAF not liking Asian characters in your log file. If that doesn’t work, could you please send the output of “env |grep LC_”? Hope that helps.

    Thanks,

    James.

    PS. We do recommend using PyRAF, which is what we’re primarily testing on nowadays.

    in reply to: gqecorr for IFU data #2020

    jturner
    Keymaster

    Yes, you should include QE correction for your flats, standard star and science data. The “refimages” parameter should be provided with the corresponding extracted arc lamp exposure(s) (beginning with an “e”). These arc(s) should have been wavelength calibrated beforehand (with wavelength calibration and aperture trace entries still present in the database subdirectory). You can run gqecorr directly or via gfreduce.

    You can find an example from a tutorial at a recent meeting at http://jastro.org/GMOS_IFU_2017 (this URL might change at some point).

    Hope that helps,

    James.

    in reply to: GSREDUCE error #1895

    jturner
    Keymaster

    Hello,

    You’re getting the same error because it’s re-using the existing gN20170927S0279.fits. Try deleting that file and also setting “mdfdir=./” (or wherever you put GN2017BQ050-01.fits, if not in the current working directory).

    Hope that helps!

    in reply to: GSREDUCE error #1874

    jturner
    Keymaster

    There isn’t an output file attached to your last post…

    Have you changed “mdfdir” to your working directory (eg. “./”) in which GN2017BQ050-01.fits is the newly-downloaded MDF file? You could also set “mdffile=GN2017BQ050-01”, though I think it should figure that out from the headers.

    in reply to: GSREDUCE error #1822

    jturner
    Keymaster

    It seems that a manual step involved in your MDF reaching the archive had been overlooked. You should now be able to find GN2017BQ050-01.fits there.

    in reply to: GSREDUCE error #1778

    jturner
    Keymaster

    Thanks for confirming that this is due to using the ODF file. I’ll ask GN why the MDF is missing.

    in reply to: GSREDUCE error #1768

    jturner
    Keymaster

    Someone reported seeing this message once before, but didn’t provide any follow-up information to help understand why it happened. I believe it indicates that your MDF file is missing a slitpos_mx column; is that the case? As on the previous occasion, your MDF files seem to be missing from the archive, for some reason. Where did you get this MDF file? Are you sure it isn’t really the ODF (from which the MDF is supposed to be generated)? I can’t see where it’s coming from because your log just has “Using already gprepared image gN20170927S0279”.

    Thanks,

    James.

    in reply to: Tips for precise stellar photometry with GeMS+GSAOI #1515

    jturner
    Keymaster

    Thanks for the pointer — looks useful. Any example data or scripts would also be welcome here, if & when you get to that point.

    in reply to: bug in PyRAF gemcrspec #1498

    jturner
    Keymaster

    Thanks for reporting this bug. Does this version do what you want?

    Sorry, the forum won’t let me upload a .cl file, so you’ll need to run gunzip on it. You can either copy it into gemtools/ (best save a copy of the original there) or re-declare it after loading the gemini package, eg. by adding this to your loginuser.cl:

    gemini
    gmos
    gemtools
    task gemcrspec=/path/to/new/gemcrspec.cl

    Cheers,

    James.

    Attachments:
    1. gemcrspec.cl_.gz
    in reply to: Problem with DQ extension from gsreduce #1479

    jturner
    Keymaster

    DQ=4 is supposed to be for saturated pixels. Are these flats? Are they definitely not saturated? I’m not sure off hand what would cause that flag to be set erroneously (perhaps some bad header keyword values), but the first thing is to verify the actual rough values.

    Cheers,

    James.

    in reply to: PyFU datacube mosaicking package (updated Oct 2016) #1425

    jturner
    Keymaster

    Here’s a new version that addresses the couple of problems that cropped up on NumPy 1.9 & 1.10 and now uses astropy.io.fits in place of pyfits. This one also finally has a setup.py & documented Python interface, for anyone wanting to use it directly as a Python module instead of via PyRAF. Sorry that took a while and thanks to nik for reporting the NumPy 1.10 change.

    in reply to: GMOS IFU data reduction scripts (updated Oct 2016) #1424

    jturner
    Keymaster

    Sorry, I completely forgot to mention that. Do you have a package of data to go with that tutorial (it looks quite comprehensive but I have trouble getting my bearings from the description there without enough time to sit down and work all the way through it)?

    James.

    in reply to: GMOS IFU data reduction scripts (updated Oct 2016) #1422

    jturner
    Keymaster

    Not really (do you mean for the IFU?), but if you look at my post from 8 April 2015 above, I have posted a link to an example reduction script, for which you should be able to obtain the data from the Gemini archive. (Sorry that script is quite laborious to adapt — I’ve been rewriting it in Python and the new one gets the data for you etc. etc.) You can also type “gmosexamples” in the Gemini package to see some simpler example reduction scripts for the other modes.

    Cheers,

    James.

Viewing 15 posts - 1 through 15 (of 54 total)