Open KathleenLabrie opened 1 year ago
Same thing happens with "S20140224S0024.fits".
I thought I might be able to help on this one.
However, I wasn't able to reproduce, likely because of a missing MDF, which I don't know how to track down.
$ reduce --qa -r my_recipe.my_reduce N20070718S0095.fits
...
PRIMITIVE: addMDF
-----------------
No MDF could be retrieved for N20070718S0095_dataValidated.fits
...
PRIMITIVE: tileArrays
---------------------
Array maps to [1:512,1:2304]
Array maps to [522:1033,1:2304]
Array maps to [1043:1554,1:2304]
I think I've tracked down the ID of the MDF here, but don't know how to find the proper .fits for this mask.
MASKID = 10001803 / Mask/IFU barcode
MASKNAME= 'GN2007AQ018-03' / Mask name
MASKTYP = 1 / Mask/IFU type (0=none/-1=IFU/1=mask)
MASKLOC = 0 / Mask/IFU location (-1=unknown/0=FP/1=cassette)
If it's easy to link me to the MDF, and this seems like a decent issue for me to try to reproduce one more time, then I'm happy to give it a try and see if I can get anywhere on this.
Addendum...
Edit: I see now that when I bisected #419, it automatically found the MDF geminidr/gmos/lookups/MDF/NS0.75arcsec.fits
, rather than being attached to anything I'd downloaded from the archives. So this confirms that this addendum was following the wrong trail. Still not sure how to get the correct MDF.
_There are two ARC calibrations and one FLAT calibration files in the archives. I wondered if processing these would give me the MDF data I need. But if that's the case, they don't work with makeProcessedFlat
/makeProcessedArc
:_
$ reduce N20070718S0094.fits
...
WARNING - No recipe can be found in gmos recipe libs.
WARNING - Searching primitives ...
...
ERROR - GMOS recipes do not define a 'sq' recipe for these data.
My uninformed guess is that this may be because these calibration data don't have an LS (longslit?) tag, and perhaps I need to use IRAF in order to get the MDF. I didn't go through the steps of setting up IRAF on a whim of a whim, and thus stopped here.
Thanks Michael.
This issue might not be the best issue to work on for someone internal. It is related to internal processes. This comes from an integration test that has not changed The calibrations are not required in this case. The real mystery here is that the test (which hasn't changed) used to work on a previous version (I don't even know which version work last.) This one is quite a mess.
Version:
release/3.1.x
branch.--qa
only (this is MOS)Never seen this before. When the following recipe is run on N20070718S0095.fits (GMOS-N EEV, N&S MOS), the measureIQ display puts the 3 extensions in the wrong places.
However, if I run
measureIQ
on the_skyCorrected
file (the one produced by thewriteOutputs
, the display works fine.When it fails (when the full recipe is run), the logs look like this:
When I run it manually on the
_skyCorrected
file, I get:Very odd.