# Fix rotation error in ts_wep

XMLWordPrintable

#### Details

• Type: Story
• Status: Done
• Resolution: Done
• Fix Version/s: None
• Component/s:
• Labels:
• Story Points:
2
• Team:
Telescope and Site
• Urgent?:
No

#### 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

1. image-2021-09-02-15-54-12-339.png
104 kB
2. OriginalEulerZ.png
116 kB
3. Screen Shot 2021-09-09 at 11.10.46.png
1.00 MB

#### Activity

Hide
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Te-Wei Tsai added a comment -

Yes. Thanks for the summary!

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

#### People

Assignee:
Bryce Kalmbach
Reporter:
Bryce Kalmbach
Reviewers:
Te-Wei Tsai
Watchers:
Bryce Kalmbach, Krzysztof Suberlak, Te-Wei Tsai