Uploaded image for project: 'Data Management'
  1. Data Management
  2. DM-21241

Fix setting of boresight rotation angle for imsim data

    XMLWordPrintable

Details

    • Story
    • Status: Done
    • Resolution: Done
    • None
    • obs_lsst
    • None
    • 4
    • DRP F19-2, DRP F19-4
    • Data Release Production

    Description

      For individual obs packages, we are using "translators" to convert metadata from raw files into internally consistent conventions (as many telescopes have different sets of conventions and header naming).  Our convention for boresight rotation angle is:

      At boresightRotAngle = 0, the focal plane pixels are aligned:
      +x: E->W (-ve RA), +y: S->N (+ve Dec)
      

      (and see the documentation).

      Accordingly, the imsim translator in obs_lsst should reflect that:

      boresightRotAngle = 90 deg - ROTANGLE
      

      (where the ROTANGLE is the FITS card in the raw data).

      The reason data is currently being processed properly is due to a compensation (prior to the translator functionality) for this 90 deg shift in the lsstCamMapper here. This latter "correction" should be removed from there and accommodated in the imsim translator.

      This change will be validated by running a visit of DC2 data before and after and checking that we get consistent results.

      Attachments

        Activity

          lauren Lauren MacArthur added a comment - - edited

          This is almost ready to go (tjenness, I'm planning on sending it your way once I've finished my validations if that's ok).  It occurs to me that a similar addition may be required for the phosim translator, but I have no way of testing this. I'm also unsure what it means to have two FITS header cards identified for the boresight_rotation_angle in the phosim translator:

          "boresight_rotation_angle": (["ROTANGZ", "ROTANGLE"], dict(unit=u.deg))
          

          Do any of the watchers here know what (if anything) should be done here?

          And note that rhl confirmed that nothing should be done for the other cameras in obs_lsst as this will not be possible to get properly taken care of until real on-sky data from them materializes.

          lauren Lauren MacArthur added a comment - - edited This is almost ready to go ( tjenness , I'm planning on sending it your way once I've finished my validations if that's ok).  It occurs to me that a similar addition may be required for the phosim translator, but I have no way of testing this. I'm also unsure what it means to have two FITS header cards identified for the boresight_rotation_angle in the phosim translator: "boresight_rotation_angle" : ([ "ROTANGZ" , "ROTANGLE" ], dict (unit = u.deg)) Do any of the watchers here know what (if anything) should be done here? And note that rhl confirmed that nothing should be done for the other cameras in obs_lsst as this will not be possible to get properly taken care of until real on-sky data from them materializes.
          tjenness Tim Jenness added a comment -

          PhoSim translator first looks for header ROTANGZ and then tries ROTANGLE. It returns the value from the first it finds.

          tjenness Tim Jenness added a comment - PhoSim translator first looks for header ROTANGZ and then tries ROTANGLE. It returns the value from the first it finds.

          Ah, ok...and would it be safe to assume they both would require a "90 deg - XX" to translate them to the boresight rotation angle? (I'm not sure who to ask for confirmation on things in the land of phosim...perhaps jchiang knows?)

          lauren Lauren MacArthur added a comment - Ah, ok...and would it be safe to assume they both would require a "90 deg - XX" to translate them to the boresight rotation angle? (I'm not sure who to ask for confirmation on things in the land of phosim ...perhaps jchiang knows?)

          I have tested this fix by processing visit 441815 of DC2 data both pre and post-fix.  The catalogs produced are identical.  Direct comparisons of various quantities can be perused here – all files starting with "compareVisit" in the name are the comparison plots – but they all flatline at zero, so are not terribly interesting to look at!

          Additionally, this fixes an issue first noted (but never resolved) in DM-20188 where the wcs returned by the createInitialSkyWcs() function was clearly wrong (i.e. off by 90 deg - "ROTANGLE"). This is shown here in the pre vs. post plots. The yellow grid is said "initial wcs":

          Pre:

          Post:

          It also allows for a directional arrow to be printed on "sky" plots in focal plane "pixel" space based on the angle returned by visitInfo.getBoresightRotAngle().

          Pre (note direction arrows are wrong):

          Post (direction arrows are now correct):

           

          lauren Lauren MacArthur added a comment - I have tested this fix by processing visit 441815 of DC2 data both pre and post-fix.  The catalogs produced are identical.  Direct comparisons of various quantities can be perused here – all files starting with "compareVisit" in the name are the comparison plots – but they all flatline at zero, so are not terribly interesting to look at! Additionally, this fixes an issue first noted (but never resolved) in DM-20188 where the wcs returned by the createInitialSkyWcs() function was clearly wrong (i.e. off by 90 deg - "ROTANGLE"). This is shown here in the pre vs. post plots. The yellow grid is said "initial wcs": Pre: Post: It also allows for a directional arrow to be printed on "sky" plots in focal plane "pixel" space based on the angle returned by visitInfo.getBoresightRotAngle() . Pre (note direction arrows are wrong): Post (direction arrows are now correct):  
          lauren Lauren MacArthur added a comment - - edited

          Would you be able to review this?  I'm not sure what the correct answer for phosim is, but I suppose it could be the subject of another ticket if we don't have confirmation/way to test.

          Note that I also took the opportunity to remove the custom getWcsFromDetector() function in favor of using obs_base's createInitialSkyWcs(). I did it as a separate commit so as not to conflate the two changes, but can squash if you think it would be better as a single commit.

          Jenkins passed.

          PR: https://github.com/lsst/obs_lsst/pull/129

          lauren Lauren MacArthur added a comment - - edited Would you be able to review this?  I'm not sure what the correct answer for phosim is, but I suppose it could be the subject of another ticket if we don't have confirmation/way to test. Note that I also took the opportunity to remove the custom  getWcsFromDetector() function in favor of using obs_base 's createInitialSkyWcs() . I did it as a separate commit so as not to conflate the two changes, but can squash if you think it would be better as a single commit. Jenkins  passed . PR: https://github.com/lsst/obs_lsst/pull/129
          tjenness Tim Jenness added a comment -

          looks great. Thanks for the comprehensive analysis. Without phosim data I think we leave it as is. If krughoff knows the answer we can fix it on another ticket.

          tjenness Tim Jenness added a comment - looks great. Thanks for the comprehensive analysis. Without phosim data I think we leave it as is. If krughoff knows the answer we can fix it on another ticket.

          Sounds good to me.  Thanks for the speedy review...merged to master.

          lauren Lauren MacArthur added a comment - Sounds good to me.  Thanks for the speedy review...merged to master.

          If the question is ROTANGLE vs. ROTANGZ, I don't believe phosim images ever have both. At some point the header card changed. I think they both needs to be treated the same way.

          krughoff Simon Krughoff (Inactive) added a comment - If the question is ROTANGLE vs. ROTANGZ, I don't believe phosim images ever have both. At some point the header card changed. I think they both needs to be treated the same way.

          Great, that answers one part of the question.  The other is “how should they be treated?”  I.e. does the angle that exists need the same

          boresightRotAngle = 90 deg - ROTANGLE(or ROTANGZ)
          

          conversion in its translator?

          lauren Lauren MacArthur added a comment - Great, that answers one part of the question.  The other is “how should they be treated?”  I.e. does the angle that exists need the same boresightRotAngle = 90 deg - ROTANGLE( or ROTANGZ) conversion in its translator?

          I believe that same correction needs to be made to both imsim and phosim translators. The DC1 dataset had both imsim and phosim data and were both using the same mapper, so I believe that correction should continue to be applied to both.

          krughoff Simon Krughoff (Inactive) added a comment - I believe that same correction needs to be made to both imsim and phosim translators. The DC1 dataset had both imsim and phosim data and were both using the same mapper, so I believe that correction should continue to be applied to both.
          jchiang James Chiang added a comment -

          I think this correct: both phosim and imsim get that angle from the rotSkyPos parameter in the instance catalogs that both currently use for simulating specific visits.

          jchiang James Chiang added a comment - I think this correct: both phosim and imsim get that angle from the rotSkyPos parameter in the instance catalogs that both currently use for simulating specific visits.

          People

            lauren Lauren MacArthur
            lauren Lauren MacArthur
            Tim Jenness
            Eli Rykoff, James Chiang, John Parejko, Lauren MacArthur, Robert Lupton, Simon Krughoff (Inactive), Tim Jenness, Yusra AlSayyad
            Votes:
            0 Vote for this issue
            Watchers:
            8 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Jenkins

                No builds found.