Details
-
Type:
Improvement
-
Status: Done
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: ts_aos
-
Labels:
-
Story Points:3
-
Epic Link:
-
Team:Telescope and Site
Description
- Turn off all perturbations again, but this time use the cmd file to add back 1 Zernike perturbation at a time to M1 only. I’d suggest an amplitude of maybe 250 nm.
- Single star on the boresight.
- For each Zernike index 4-22 (or some subset if this is too much), make a plot of the estimated Zernike coefficient vs input rotation angle. You should get sine waves for these, with periods as follows:
- Z4, Z11, Z22 estimated Zernikes are independent of input rotation angle.
- Z7, Z8, Z16, Z17 period is 360 degrees
- Z5, Z6, Z12, Z13 period is 180 degrees
- Z9, Z10, Z18, Z19 period is 120 degrees
- Z14, Z15, period is 90 degrees
- Z20, Z21, period is 72 degrees
- I predict that the above are periodic with rotTelPos, but not rotSkyPos.
- Note that phosim injects circular Zernikes, but ts_wep is estimating annular Zernikes, so we don’t expect to recover 2*250 nm (reflection so path length changes by 500nm!) if we inject a 250 nm perturbation.
Attachments
Issue Links
- is child task of
-
DM-33116 Validate AOS for a rotated camera
- Done
Activity
Each time a single `izernike` command inputs zk perturbation to M1. We explore all zk4-22, for various rotation angles. For `rotCamInDeg` passed as `rotSkyPos` in the `inst` file, there is no dependence on the angle when simulating a single star on the boresight - all rotation angles yield the same results . For example, results of inputting 250 nm of zk13, at various rotation angles (result are numerically the same). This is what the test assumed - that there is no dependence on the rotation with `rotSkyPos: 
Inputting different zk at a particular rotation angle is summarized below. There is a peak corresponding to each input zk (marked by a vertical dashed line with color matching the fit results). One panel for zk5:13:
and another panel for zk14:22:
However, there is a dependence of results for a given `izernike` perturbation with rotation angle if conveyed as `rotTelPos` in the inst file: 
Varying `rotSkyPos` with `rotTelPos` set to 0, is like rotating the entire telescope, while keeping the angle between the camera rotator and the telescope fixed (it is possible for smaller telescopes with telescope rotators https://telescopemount.org/alt-az-mounts-for-long-exposure-astrophotography-telescope-rotators/ , although not for LSST). It is case1 here https://jira.lsstcorp.org/browse/DM-34356 .
Varying `rotTelPos` without specifying `rotSkyPos` (i.e. allowing PhoSim to calculate it based on the parallactic angle) is like pointing the telescope at a given location in the sky, and then rotating the camera wrt telescope. This is more realistic for LSST, and is case3 here https://jira.lsstcorp.org/browse/DM-34356
Comparison of various zk - the number in the left column postage stamp corresponds to the zk number.
Comparison of donuts given a single zk for a variety of `rotSkyPos`, keeping rotTelPos=0. The number in each postage stamp is the value of 'rotSkyPos' in that simulation.
Comparison of donut postage stamps given a single input zk (18) for a variety of `rotTelPos`, allowing PhoSim to calculate `rotSkyPos`. As above, the number in each stamp is the value of angle input in the simulation, in that case `rotTelPos`:
In summary, as mentioned here https://lsstc.slack.com/archives/C9BEJU1T3/p1649452191399489?thread_ts=1649278238.043959&cid=C9BEJU1T3 , these tests prove that "rotTelPos in phosim_syseng4 is really just rotSpiderPos", i.e. the camera is kept at a fixed angle wrt M1M2, and the only thing that rotates due to changing "rotTelPos" is the spider.
In summary, I think we can say convincingly that this proves that there is no camera rotation imparted by 'rotTelPos', only the spider rotation. The camera is at a fixed angle wrt M1M3 assembly. This is similar to the findings of https://jira.lsstcorp.org/browse/DM-31532.
This one looks done.
Implementation with `CloseLoopTask` - using that class and its tools, while running only 1 iteration https://github.com/suberlak/AOS/blob/main/AOS_DM-34065_rotation_JM_test-02.ipynb (too slow due to refCat generation for each loop)
Implementation with custom-written functions - much faster b/c refCat and butler only generated once, thereupon same repo used for all data. https://github.com/suberlak/AOS/blob/main/AOS_DM-34065_rotation_JM_test-02_b.ipynb