Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

measureIQ display messed up... sometimes... #420

Open
KathleenLabrie opened this issue Feb 20, 2023 · 3 comments
Open

measureIQ display messed up... sometimes... #420

KathleenLabrie opened this issue Feb 20, 2023 · 3 comments
Labels
bug 🐛 Something should be working but it isn't component - gemini gemini_instruments and geminidr severity-routine Needs to be fixed urgency-low Do when we have a breather

Comments

@KathleenLabrie
Copy link
Contributor

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.

    p.prepare()
    p.addDQ()
    p.addVAR(read_noise=True)
    p.overscanCorrect()
    p.biasCorrect()
    p.ADUToElectrons()
    p.addVAR(poisson_noise=True)
    p.findAcquisitionSlits()
    p.skyCorrectNodAndShuffle()
    p.writeOutputs()
    p.measureIQ(display=True)

However, if I run measureIQ on the _skyCorrected file (the one produced by the writeOutputs, the display works fine.

When it fails (when the full recipe is run), the logs look like this:

   PRIMITIVE: measureIQ
   --------------------
      PRIMITIVE: tileArrays
      ---------------------
      WARNING - N20070718S0095_skyCorrected.fits has nothing to tile, as tile_all=False but each array has only one amplifier.
      .
   
      Filename: N20070718S0095_skyCorrected.fits
      4 source(s) used to measure IQ
      ----------------------------------------------------------
      FWHM measurement:                   3.585 +/- 2.930 arcsec
      Zenith-corrected FWHM (AM 1.69):    2.619 +/- 2.140 arcsec
      IQ range for OG515-band:              IQAny (>1.05 arcsec)
      (Requested IQ could not be determined)                          
      ----------------------------------------------------------
   
      PRIMITIVE: display
      ------------------
         PRIMITIVE: tileArrays
         ---------------------
         Array maps to [1:512,1:2304]
         Array maps to [1043:1554,1:2304]
         Array maps to [2085:2596,1:2304]

When I run it manually on the _skyCorrected file, I get:

   PRIMITIVE: measureIQ
   --------------------
      PRIMITIVE: tileArrays
      ---------------------
      WARNING - N20070718S0095_skyCorrected.fits has nothing to tile, as tile_all=False but each array has only one amplifier.
      .
   
      Filename: N20070718S0095_skyCorrected.fits
      4 source(s) used to measure IQ
      ----------------------------------------------------------
      FWHM measurement:                   3.585 +/- 2.930 arcsec
      Zenith-corrected FWHM (AM 1.69):    2.619 +/- 2.140 arcsec
      IQ range for OG515-band:              IQAny (>1.05 arcsec)
      (Requested IQ could not be determined)                          
      ----------------------------------------------------------
   
      PRIMITIVE: display
      ------------------
         PRIMITIVE: tileArrays
         ---------------------
         Array maps to [1:512,1:2304]
         Array maps to [522:1033,1:2304]
         Array maps to [1043:1554,1:2304]

Very odd.

@KathleenLabrie KathleenLabrie added bug 🐛 Something should be working but it isn't severity-routine Needs to be fixed urgency-low Do when we have a breather component - gemini gemini_instruments and geminidr labels Feb 20, 2023
@KathleenLabrie
Copy link
Contributor Author

Same thing happens with "S20140224S0024.fits".

@MichaelRFairhurst
Copy link

MichaelRFairhurst commented Mar 9, 2023

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.

@KathleenLabrie
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug 🐛 Something should be working but it isn't component - gemini gemini_instruments and geminidr severity-routine Needs to be fixed urgency-low Do when we have a breather
Projects
None yet
Development

No branches or pull requests

2 participants