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 

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.