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

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

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.

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: 

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!

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.

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?

Yes. Thanks for the summary!