Forum Replies Created
June 12, 2019 at 9:33 pm in reply to: Wavelength shift in the sky lines from GMOS-S IFU, 1-slit, B600 data. #3238
You might also like to refer to these tutorials:
The second one discusses a bit about flexure correction.June 12, 2019 at 9:27 pm in reply to: Wavelength shift in the sky lines from GMOS-S IFU, 1-slit, B600 data. #3237
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.November 21, 2017 at 6:58 pm in reply to: GMOS Longslit reduction problem: Unable to open logfile? #2021
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.
PS. We do recommend using PyRAF, which is what we’re primarily testing on nowadays.
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,
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!
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.
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.
Thanks for confirming that this is due to using the ODF file. I’ll ask GN why the MDF is missing.
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”.
James.March 27, 2017 at 11:34 pm in reply to: Tips for precise stellar photometry with GeMS+GSAOI #1515
Thanks for the pointer — looks useful. Any example data or scripts would also be welcome here, if & when you get to that point.
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
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.
James.October 21, 2016 at 8:48 pm in reply to: PyFU datacube mosaicking package (updated Oct 2016) #1425
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.October 21, 2016 at 8:24 pm in reply to: GMOS IFU data reduction scripts (updated Oct 2016) #1424
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.October 21, 2016 at 7:31 pm in reply to: GMOS IFU data reduction scripts (updated Oct 2016) #1422
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.