GMOS-S IFU – Aperture numbers changing while reducing

Home Forums Gemini Data Reduction GMOS-S IFU – Aperture numbers changing while reducing

This topic contains 10 replies, has 2 voices, and was last updated by  derrcarr 8 months, 3 weeks ago.

Viewing 11 posts - 1 through 11 (of 11 total)
  • Author
    Posts
  • #3254

    derrcarr
    Participant

    The error I get when using gfcube is number of rows in image does not equal the number of good fibres in MDF — Which I believe translates to the number of fibres extracted does not equal the number of fibres in the MDF.

    This is tricky, as the problem manifests itself in the middle of the pipeline somewhere. At the (erg+filename) step, the two flats have 1488 apertures, which matches the default MDF given. From there on, it seems the mdf and the flats then have different number of apertures later on. For reference, at the (eqxbprg+filename) step [meaning the flats have then been qecorr, cosmic ray removed, background light modeled and subtracted, and bad pixel repaired] the number of apertures becomes something different. For the two spatial dithers flats earlier there were 745 and 743 apertures, but now it seems to be 745 and 729 for one flat and 745 and 735 for the other.

    So then in the datacube step, gfcube sees that the mdf is still 743 and 745 while the two flats are different(!) meaning I don not think I could just simply change the mdf to fit both of them.

    Any ideas how to solve this problem? It may also be worth mentioning that our pipeline works well and I have ran it for 10 other galaxies just fine, but this particular object is problematic. I theorize some apertures are accidentally removed in the background subtraction step, but am not sure of how to remedy that situation anyways…. that’s not just not doing that step.

    #4073

    derrcarr
    Participant

    Has anyone else yet to encounter this problem?

    #4074

    Kathleen Labrie
    Keymaster

    Have you verified the MDF? Sometimes some fibers get vignetted. I recommend that you have a look at this tutorial:

    https://gmos-ifu-1-data-reduction-tutorial-gemini-iraf.readthedocs.io/

    in particular the section “Verify MDF”

    https://gmos-ifu-1-data-reduction-tutorial-gemini-iraf.readthedocs.io/en/latest/mdf.html

    This is a critical step. It can be tedious and frustrating but it is necessary. It seems clear that your data has vignetted fibers.

    #4076

    derrcarr
    Participant

    Hey Kathleen,

    Fortunately, I’ve been using the tutorial as a guide on for my reductions. I have IFU-2 data and in the MDF verification script I actually was able to catch a fiber that wasn’t being properly identified, but it still reached 1499 fibers at the end of all the bundles. After going into the MDF and changing its [‘BEAM’] to -1, I was hoping that would fix it, but it doesn’t seem like it did.

    I did a check in the MDF to sum up all the instances where [‘BEAM’] == 1 and found there should be 1487 good fibers. However, when I open up the science image with the c-prefix (so near the end), I count 1474 rows. There seems to be a 13-fiber discrepancy, which seems too many for me to miss in the MDF verification step.

    Do you have any ideas as to how this may be happening? I have on potential idea: I use a pipeline that was able to reduce a bunch of other galaxies this semester, but maybe this last galaxy has fiber issues different from the others. I think the only answer is that for other steps where fibers are removed for x,y,z reason, the MDF file is not properly being updated. Do you know of the top of your head what functions can modify the MDF?

    #4077

    Kathleen Labrie
    Keymaster

    I still think that the problem is with the MDF and the fibers. My recollection of doing this fiber inspection for the 2-slit data is that it was quite tricky. It is common for the fibers to be affected differently within a program.

    If you had a flat taken just before or after one of the science observations of the source that is giving you issue, then that’s the flat you want to use.

    Also, be careful that the correct/updated MDF gets picked up. You will need to re-run the “prepare” task I believe because that’s where the MDF gets added to the file and once it’s in the file, that’s what gets used. Changing the MDF on disk after than won’t change anything for the science frame.

    #4078

    derrcarr
    Participant

    Hey Kathleen,

    Ok you were totally right, I closely inspected like every bundle and the issues seem to be this…

    Fiber 1200 is gone and skipped over (so it’s bundle ends on 1199)
    Fiber 1399 is gone such that that bundle now ends on 1398 due to 1200 also being skipped
    The start of the next bundle is 1399, which then automatically skips to 1400 to 1401, despite there seeming to be no issue between fiber 1399 and the next fiber.

    So with that said, would the solution be to turn of fiber 1200 and 1400? I’m not entirely sure what to make of the numbers going from 1399 to 1401 (which in reality is fiber 1401 to 1403)

    #4080

    Kathleen Labrie
    Keymaster

    Good job!

    Here’s what I would do. Flag 1200 in the MDF, and run it again. Repeat the inspection. Make sure the ~1200 area is resolved (I expect bundle ends with 1199, and next with 1201). Then look how the ~1400 looks like.

    If removing 1200 does the trick, and ~1400 looks good, quickly checks the following bundles (to the right in the plot) and if they are also okay, go with that. If the ~1400 area still looks funny bug 1200 looks fine, you need to remove something around 1400. Then, rinse, repeat.

    Always start from the low number fibers, the fibers on the left in the plot, as it’s a domino effect.

    #4093

    derrcarr
    Participant

    Hey Kathleen,

    So I finally got around to doing the suggested change. The issue I am now having is that for some reason the changes I make to the MDF are just not as the MDF verification step. I will attach an image that shows 3 things: (1) a terminal with python code that verifies that the fiber should have BEAM = -1, (2) the actual execution of the GRPREPARE that at least shows that the MDF file I created is being read-in, and (3) the actual display of the fiber identification step showing that fiber 1200 is not actually being properly skipped.

    Do you know what may be happening here? I am fairly certain that I am using the MDF and that the BEAM that I want to have turned off is set to -1. I even checked the MDF-extension in the resulting rg flat and found that it also has the correct BEAM set to -1

    Thanks

    • This reply was modified 8 months, 4 weeks ago by  derrcarr.
    #4114

    derrcarr
    Participant

    Any ideas about this? I thought I did what was on the website…

    #4115

    Kathleen Labrie
    Keymaster

    This is just a community forum. You might have reached the point where you need to file a Gemini Helpdesk ticket and get in-depth support. All I can do here is handwaving possible solutions.

    From the plot in the screenshot, it is clear that there is something wrong with the MDF pre-fiber-1200. The bundle should start at 1201. Also, there might be something wrong with the actual image because that wide broad band in the gap is not normal.

    Have you tried wiping everything up and starting from a clean slate?

    Anyway, here is the link to the Gemini Helpdesk: http://www.gemini.edu/observing/helpdesk/submit-general-helpdesk-request. Use the “Gemini IRAF” category.

    Make sure that you include the program ID, the specific files (including calibrations) that you are using and anything else that you have learned or tried so far. Might want to add the link to this forum discussion.

    #4117

    derrcarr
    Participant

    Ahh I must have forgotten about the help desk. Thank you for all of your help so far!

Viewing 11 posts - 1 through 11 (of 11 total)

You must be logged in to reply to this topic.