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!
Upon looking at the code and possible fixes it looks like this could be most easily fixed after finishing
DM-30325