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

Fix rotation error in ts_wep

    XMLWordPrintable

    Details

      Description

      When running test on vignetted donuts I noticed that the Zernike values for wavefront detectors in raft R04 and R40 are very wrong while those of R00 and R44 are close to non-vignetted values.

       

      After playing around with different settings I discovered that in the ts_wep code the postage stamps sent to the WEP for these detectors is not rotated the proper amount. When adjusting the EulerZ angle in the function lsst.ts.wep.WfEstimator.setImg for the rafts (which are rotated in the focal plane 90 degrees from the other two rafts) I correct the issue:

       

      And the remaining errors look like acceptable deviations due to the vignetting effects I was investigating.

        Attachments

          Issue Links

            Activity

            Hide
            jbkalmbach Bryce Kalmbach added a comment -

            Upon looking at the code and possible fixes it looks like this could be most easily fixed after finishing DM-30325

            Show
            jbkalmbach Bryce Kalmbach added a comment - Upon looking at the code and possible fixes it looks like this could be most easily fixed after finishing DM-30325
            Hide
            ttsai Te-Wei Tsai added a comment -

            Reviewed in github. Please consider to discuss with Chris for the field positions of corner wavefront sensors before the merge. Thanks!

            Show
            ttsai Te-Wei Tsai added a comment - Reviewed in github. Please consider to discuss with Chris for the field positions of corner wavefront sensors before the merge. Thanks!
            Hide
            ttsai Te-Wei Tsai added a comment - - edited

            In this PR, the field position of corner wavefront sensor is gotten by the use of DonutStamp instead of SourceProcessor. There is 180 degrees difference for the R04 and R40 sensors. After using the method of DonutStamp that comes from the obs_lsst, the calculation by cwfs module matches the result by OPD well.

            However, the Euler z angle in SourcePrcoessor comes from the focalplane.txt used in the phosim_syseng4 that was updated to match the obs_lsst in DM-30367. In this ticket, Krzysztof Suberlak also uses the functions in obs_lsst to get the focal plane of LSST camera. In this update, you can see the origins of R04 and R40 sensors have the 90 or 270 degree differences compared with the R00 and R44, that have the same orientation of origin of focal plane (0, 0):
            https://github.com/lsst-ts/ts_wep/blob/develop/python/lsst/ts/wep/SourceProcessor.py#L170-L186

            Based on this, I suspect there might be the inconsistency of obs_lsst APIs to get the Euler z angle on focal plane for the corner wavefront sensors. Bryce Kalmbach and Krzysztof Suberlak use the same obs_lsst package but get the different results of Euler z angle.

            In additional to this, there is another complexity of coordinate system of OPD on the corner wavefront sensors. The origins of corner wavefront sensors in ts_wep have been changed in the following commit:
            https://github.com/lsst-ts/ts_wep/commit/280162cab677882891e1b6ed08c281ef48b678b5#diff-b237361ed8111c3e51051b81696ae45821e8470f6ab54e3e053d1bee9d9cc900L232-R251

            This means we may need to check the coordinate of OPD in phosim_syseng4 to see the change of origins of corner wavefront sensors will affect the result or not. That coordinate of OPD was developed by Bo and John, which is inconsistent with the LSST camera now (assume the truth is obs_lsst, although it looks there is the inconsistency in itself). In addition, the rotation of wavefront images for the corner wavefront sensors also need to be considered. Actually, I suspected maybe the OPD in phosim_systen4 need to have a further investigation.

            To investigate the OPD of corner wavefront sensors with the updated focalplane.txt in phosim_syseng4, you may need to modify the perturbation of degree of freedom or the M1M3 bending mode and see the generated OPD on the corner wavefront sensor to make sure they give you the correct answer of orientation or wavefront error.

            Show
            ttsai Te-Wei Tsai added a comment - - edited In this PR, the field position of corner wavefront sensor is gotten by the use of DonutStamp instead of SourceProcessor . There is 180 degrees difference for the R04 and R40 sensors. After using the method of DonutStamp that comes from the obs_lsst , the calculation by cwfs module matches the result by OPD well. However, the Euler z angle in SourcePrcoessor comes from the focalplane.txt used in the phosim_syseng4 that was updated to match the  obs_lsst in DM-30367 . In this ticket, Krzysztof Suberlak  also uses the functions in obs_lsst to get the focal plane of LSST camera. In this update, you can see the origins of R04 and R40 sensors have the 90 or 270 degree differences compared with the R00 and R44, that have the same orientation of origin of focal plane (0, 0): https://github.com/lsst-ts/ts_wep/blob/develop/python/lsst/ts/wep/SourceProcessor.py#L170-L186 Based on this, I suspect there might be the inconsistency of obs_lsst APIs to get the Euler z angle on focal plane for the corner wavefront sensors. Bryce Kalmbach  and Krzysztof Suberlak  use the same obs_lsst package but get the different results of Euler z angle. In additional to this, there is another complexity of coordinate system of OPD on the corner wavefront sensors. The origins of corner wavefront sensors in ts_wep  have been changed in the following commit: https://github.com/lsst-ts/ts_wep/commit/280162cab677882891e1b6ed08c281ef48b678b5#diff-b237361ed8111c3e51051b81696ae45821e8470f6ab54e3e053d1bee9d9cc900L232-R251 This means we may need to check the coordinate of OPD in phosim_syseng4 to see the change of origins of corner wavefront sensors will affect the result or not. That coordinate of OPD was developed by Bo and John, which is inconsistent with the LSST camera now (assume the truth is obs_lsst , although it looks there is the inconsistency in itself). In addition, the rotation of wavefront images for the corner wavefront sensors also need to be considered. Actually, I suspected maybe the OPD in phosim_systen4 need to have a further investigation. To investigate the OPD of corner wavefront sensors with the updated focalplane.txt in phosim_syseng4 , you may need to modify the perturbation of degree of freedom or the M1M3 bending mode and see the generated OPD on the corner wavefront sensor to make sure they give you the correct answer of orientation or wavefront error.
            Hide
            jbkalmbach Bryce Kalmbach added a comment -

            Krzysztof Suberlak included an extra 180 degree rotation in his output for focalPlaneLayout.txt based upon his code here: https://github.com/suberlak/AOS/blob/main/update_focalplanelayout_lsst.py#L113-L125. This was done to get the final phosim output to look correct as demonstrated in his notebook for https://jira.lsstcorp.org/browse/DM-30367 shown here: https://github.com/suberlak/AOS/blob/main/AOS_DM-30367_summary.ipynb. 

             

            As for the location of the corner wavefront sensors I think we are okay based on the results of the notebook here that shows consistency between obs_lsst and the focalPlaneLayout.txt: https://gist.github.com/jbkalmbach/6840cede57b3fab4ec2542bc99780bac 

            Screenshot of results: 

            Show
            jbkalmbach Bryce Kalmbach added a comment - Krzysztof Suberlak included an extra 180 degree rotation in his output for focalPlaneLayout.txt based upon his code here: https://github.com/suberlak/AOS/blob/main/update_focalplanelayout_lsst.py#L113-L125.  This was done to get the final phosim output to look correct as demonstrated in his notebook for https://jira.lsstcorp.org/browse/DM-30367  shown here: https://github.com/suberlak/AOS/blob/main/AOS_DM-30367_summary.ipynb.     As for the location of the corner wavefront sensors I think we are okay based on the results of the notebook here that shows consistency between obs_lsst and the focalPlaneLayout.txt: https://gist.github.com/jbkalmbach/6840cede57b3fab4ec2542bc99780bac   Screenshot of results: 
            Hide
            ksuberlak Krzysztof Suberlak added a comment - - edited

            The location x,y of corner sensors was taken directly from `obs_lsst` (https://github.com/suberlak/AOS/blob/34e8ee7c6bd3eb2d3192102557e22b49f6a96b5e/update_focalplanelayout_lsst.py#L91) . As you can see `x_phosim_microns, y_phosim_microns = y_obs_lsst_microns, x_obs_lsst_microns`. This is only the difference between CCS and DVCS, but the numbers are exactly the same for the focal plane x,y position in microns.

            The original rotation angles of corner sensors in phosim `focaplanelayout` were found to be producing incorrect results for the SW0 sensors. This necessitated the 180 degree update, as Bryce points above (https://github.com/suberlak/AOS/blob/34e8ee7c6bd3eb2d3192102557e22b49f6a96b5e/update_focalplanelayout_lsst.py#L115)

            The exact numerical Euler z angle values between obs_lsst and phosim `focalplanelayout` were not the same after the update (despite producing the same effect if assuming the obs_lsst angles to be in the opposite direction to phosim), namely

            sensor   obs_lsst   phosim
             R00_SW0   180     179.995073
             R00_SW1   360       -0.002807
             R04_SW0   270      90.018394
             R04_SW1   450     -89.994904
             R40_SW0    90       89.992668
             R40_SW1   270      270.004585
             R44_SW0     0       0.01879
             R44_SW1   180     -179.991562
            

            I asked Bo, and he said that this was because "PhoSim is trying to simulate the imperfect positioning of the sensors. John obtained some data from the camera team, and randomly perturbed the sensor positioning based on that statistics." He suggested that if we want the two to be exactly the same we would need to to take `offset = phosim - round(phosim)`
            and use `obs_lsst + offset` . Quoting Bo: "This would preserve John’s offset, and still make sure the angle is consistent with obs_lsst (up to this small offset). Of course, if this in any way poses some difficulty with subsequent data processing, we should probably just forget it. It is not important."

            I decided to update the `phosim` angles with 180 degree added to SW0. Another option would have been to take the negative of obs_lsst angle and add the offset. Below is the comparison:
            old_phosim  = before any changes implemented in https://github.com/lsst-ts/phosim_syseng4/pull/9 
            new_phosim = after the update to SW0 angle by 180 degrees
            obs_lsst = detector.getOrientation().getYaw().asDegrees()
            offset = old_phosim - round(old_phosim)

            sensor      old_phosim   new_phosim  obs_lsst  -obs_lsst+offset  -obs_lsst+offset+360
            R00_SW1      -0.002807   -0.002807   360.00    -360.002807       -0.002807
            R00_SW0      -0.004927  179.995073   180.00    -180.004927      179.995073
            R04_SW1     -89.994904  -89.994904   450.00    -449.994904      -89.994904
            R04_SW0     -89.981606   90.018394   270.00    -269.981606       90.018394
            R40_SW1      89.992668   89.992668   270.00    -270.007332       89.992668
            R40_SW0      90.004585  270.004585    90.00     -89.995415      270.004585
            R44_SW1    -179.991562 -179.991562   180.00    -179.991562      180.008438
            R44_SW0    -179.981201    0.018799     0.00       0.018799      360.018799
            

            As you can see, the last column (-obs_lsst+offset+360) is numerically the same as third column (new_phosim), apart from R44 (where adding 360 is not needed, but adding 360 does not change the orientation).  Hope this makes things more clear!

            Show
            ksuberlak Krzysztof Suberlak added a comment - - edited The location x,y of corner sensors was taken directly from `obs_lsst` ( https://github.com/suberlak/AOS/blob/34e8ee7c6bd3eb2d3192102557e22b49f6a96b5e/update_focalplanelayout_lsst.py#L91 ) . As you can see `x_phosim_microns, y_phosim_microns = y_obs_lsst_microns, x_obs_lsst_microns`. This is only the difference between CCS and DVCS, but the numbers are exactly the same for the focal plane x,y position in microns. The original rotation angles of corner sensors in phosim `focaplanelayout` were found to be producing incorrect results for the SW0 sensors. This necessitated the 180 degree update, as Bryce points above ( https://github.com/suberlak/AOS/blob/34e8ee7c6bd3eb2d3192102557e22b49f6a96b5e/update_focalplanelayout_lsst.py#L115 ) The exact numerical Euler z angle values between obs_lsst and phosim `focalplanelayout` were not the same after the update (despite producing the same effect if assuming the obs_lsst angles to be in the opposite direction to phosim), namely sensor obs_lsst phosim R00_SW0 180 179.995073 R00_SW1 360 - 0.002807 R04_SW0 270 90.018394 R04_SW1 450 - 89.994904 R40_SW0 90 89.992668 R40_SW1 270 270.004585 R44_SW0 0 0.01879 R44_SW1 180 - 179.991562 I asked Bo, and he said that this was because "PhoSim is trying to simulate the imperfect positioning of the sensors. John obtained some data from the camera team, and randomly perturbed the sensor positioning based on that statistics." He suggested that if we want the two to be exactly the same we would need to to take `offset = phosim - round(phosim)` and use `obs_lsst + offset` . Quoting Bo: "This would preserve John’s offset, and still make sure the angle is consistent with obs_lsst (up to this small offset). Of course, if this in any way poses some difficulty with subsequent data processing, we should probably just forget it. It is not important." I decided to update the `phosim` angles with 180 degree added to SW0. Another option would have been to take the negative of obs_lsst angle and add the offset. Below is the comparison: old_phosim  = before any changes implemented in https://github.com/lsst-ts/phosim_syseng4/pull/9   new_phosim = after the update to SW0 angle by 180 degrees obs_lsst = detector.getOrientation().getYaw().asDegrees() offset = old_phosim - round(old_phosim) sensor old_phosim new_phosim obs_lsst - obs_lsst + offset - obs_lsst + offset + 360 R00_SW1 - 0.002807 - 0.002807 360.00 - 360.002807 - 0.002807 R00_SW0 - 0.004927 179.995073 180.00 - 180.004927 179.995073 R04_SW1 - 89.994904 - 89.994904 450.00 - 449.994904 - 89.994904 R04_SW0 - 89.981606 90.018394 270.00 - 269.981606 90.018394 R40_SW1 89.992668 89.992668 270.00 - 270.007332 89.992668 R40_SW0 90.004585 270.004585 90.00 - 89.995415 270.004585 R44_SW1 - 179.991562 - 179.991562 180.00 - 179.991562 180.008438 R44_SW0 - 179.981201 0.018799 0.00 0.018799 360.018799 As you can see, the last column (-obs_lsst+offset+360) is numerically the same as third column (new_phosim), apart from R44 (where adding 360 is not needed, but adding 360 does not change the orientation).  Hope this makes things more clear!
            Hide
            ttsai Te-Wei Tsai added a comment - - edited

            After the discussion with Bryce, we believe we should get ride of SourceProcesser class and use the DonutStamp to get the field position and euler angle directly. However, we may need to evaluate the values of field positions when we have any change of boresight or non-zero camera rotation angle. This is because the field position of donut is defined on the focal plane and is unrelated to the camera itself. Right now, the DonutStamp has the knowledge of sensor name and we are not sure this will affect the calculation of field position or euler angle or not.

            Show
            ttsai Te-Wei Tsai added a comment - - edited After the discussion with Bryce, we believe we should get ride of SourceProcesser class and use the DonutStamp to get the field position and euler angle directly. However, we may need to evaluate the values of field positions when we have any change of boresight or non-zero camera rotation angle. This is because the field position of donut is defined on the focal plane and is unrelated to the camera itself. Right now, the DonutStamp has the knowledge of sensor name and we are not sure this will affect the calculation of field position or euler angle or not.
            Hide
            jbkalmbach Bryce Kalmbach added a comment -

            To summarize our conversation Te-Wei Tsai and make sure I cover all your suggestions for the merging of the PR I will:

            1) Add a note in the `ts_wep` `README.md` about the offset in `focalPlaneLayout.txt` and `obs_lsst`.

            2) Add a unit test with the true OPD Zernikes for the DonutStamps from the wavefront sensors to make sure we are not getting things wrong if there is an upstream changes in `obs_lsst`.

            Does that sound right?

            Show
            jbkalmbach Bryce Kalmbach added a comment - To summarize our conversation Te-Wei Tsai  and make sure I cover all your suggestions for the merging of the PR I will: 1) Add a note in the `ts_wep` `README.md` about the offset in `focalPlaneLayout.txt` and `obs_lsst`. 2) Add a unit test with the true OPD Zernikes for the DonutStamps from the wavefront sensors to make sure we are not getting things wrong if there is an upstream changes in `obs_lsst`. Does that sound right?
            Hide
            ttsai Te-Wei Tsai added a comment -

            Yes. Thanks for the summary!

            Show
            ttsai Te-Wei Tsai added a comment - Yes. Thanks for the summary!

              People

              Assignee:
              jbkalmbach Bryce Kalmbach
              Reporter:
              jbkalmbach Bryce Kalmbach
              Reviewers:
              Te-Wei Tsai
              Watchers:
              Bryce Kalmbach, Krzysztof Suberlak, Te-Wei Tsai
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:

                  Jenkins

                  No builds found.