Details
-
Type:
Story
-
Status: Won't Fix
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: ts_aos
-
Story Points:16
-
Epic Link:
-
Team:Telescope and Site
-
Urgent?:No
Description
For the upcoming AOS testing, we will have non-zero rotator angles. We need to be able to handle the `de-rotation`.
Completion criteria:
Demonstrate that the AOS comcam closed loop converges with the following test.
With our simulations, we can set `rotTelPos` to be 30 degrees, and keep `rotSkyPos` at zero. The definitions of these angles can be found at various places, one of them being https://sitcomtn-003.lsst.io/#camera-rotator . We can continue to use a few isolated star on each CCD like we've been doing so far. We want the stars to be in the same pixel coordinates as before, which requires a sky rotated by 30 degree compared to what we used before. That is, we rotate the input catalog by 30 degrees.
With the above settings, the WEP and OFC should work exactly like before. But we need to add an extra piece of code at the end of OFC. Once we finish calculating the control commands, these commands are in a coordinate system aligned with the pixel grid. We need to do a de-rotation, to put them back to the telescope Optical Coordinate System (see https://sitcomtn-003.lsst.io/ for exact Definition). The de-rotation code has been developed and given at https://sitcomtn-003.lsst.io/#camera-rotator . If it goes well, we just need to incorporate these into the OFC.
On the last step, closing the loop - my understand of the PhoSim perturbation interface is the perturbed surfaces are interpreted as always in the telescope Optical Coordinate System. So, after the above de-rotation, it should just work. If we run into problem with PhoSim here, we should be able to easily resolve that by adding a temporary fix (another rotation) external to PhoSim. This is unlikely needed.
Attachments
Issue Links
Activity
Another thing needs to consider is the pivot position of hexapod in PhoSim. The following is the email record with John:
-------------------------------------------------------------
Te-Wei-
To change the correct pivot point for M2, I’d need to modify the LSST data. Its not as simple as a command option.
I’d also be happy to do this as well, but I’d need a small contract to do it though.
john
> On Aug 12, 2019, at 10:50 AM, Te-Wei Tsai <ttsai@lsst.org> wrote:
>
> Hi John,
>
> Thanks for your explanation!
>
> I does use the "move" command now and just want to make sure the reference points.
>
> The pivot of M2 hexapod is at the M2 mirror vertex by default, not the M2 hexapod vertex.
>
> When I say "by default", this implies there is the command for the M2 hexapod to change the vertex point. However, this action is dangerous and need to be careful.
>
> Thank you!
>
>
> Te-Wei Tsai
>
> On 8/12/19 6:11 AM, John Peterson wrote:
>>
>>> On Aug 9, 2019, at 4:16 PM, Te-Wei Tsai <ttsai@lsst.org> wrote:
>>>
>>> Hi John,
>>>
>>> I have the question of reference point of hexapod in PhoSim.
>>>
>>> In the PhoSim sys_eng branch, we could set the degree of freedom of telescope with 50 terms. For the first ten terms, they are the position of m2 and camera hexapods (dz, dx, dy, tilt-x, tilt-y). For the reference point of dz, dx, and dy, is it the same as the tilt-x and tilt-y?
>>>
>>> I asked this because I realized that for the real hardware of hexapod, there will be two reference points. The distance of dx, dy, and dz is referenced to the origin of hexapod. The angle tilt-x, tilt-y, and tilt-z are referenced to the pivot point. By default, the pivot point is located at the camera L1 vertex for camera hexapod and m2 mirror vertex for m2 hexapod.
>>>
>>> I just want to make sure the PhoSim simulation is consistent with the hardware design or not. Could you help to clarify this?
>>
>> In theory we have this, although I’m not sure how well tested this is. We have the “move" commands that do exactly what you say where the degrees of freedom are coupled to have the real degrees of freedom. And I do think we have the rotations of the camera relative to the L1 vertex. I think maybe the M2 pivot point is assumed to be the hypothetical center of the mirror shape, because I don’t remember doing anything special for M2 unlike the camera. So is that the same as the M2 hexapod vertex?
>>
>> john
>>
>>
>>> Thank you!
>>>
>>>
>>> Te-Wei Tsai
>>>
A notebook with simulations of different zk wavefront surfaces: https://github.com/suberlak/AOS/blob/main/AOS_DM-31532_actuators_summary.ipynb
This highlighted an issue with PhoSim so we won't fix it and open a new ticket to do the implementation of the coordinate transformation and its validation with another tool
Sandrine Thomas
added a comment - This highlighted an issue with PhoSim so we won't fix it and open a new ticket to do the implementation of the coordinate transformation and its validation with another tool 
This task should consider how to deal with the condition that PhoSim does not rotate the optical system correctly:
Closed-Loop Simulation with Non-Zero Camera Rotation Angle.
For the de-rotation of correction in OFC, the initial implementation is in:
camrot.py. However, it could not be verified because of the PhoSim problem mentioned above.
The following is the record of email discussion with John:
-----------------------------------------------------------------
> On Aug 9, 2019, at 11:30 AM, Te-Wei Tsai <ttsai@lsst.org> wrote:
>
> Hi John,
>
> Thank you for your kind and clear explanation!
>
> I have some questions for the second effect.
>
> 1. Although the lens will not rotate relative to the focal plane, how much will it affect the accuracy of OPD compared with the condition if we just rotate the OPD directly? Will the difference be as small as less than 5 %? When I play the lens on the optical table before, I only see little difference actually. My experiment before is pretty sensitive and measures the current magnitude in the nA level. But I should admit that is in a different field, not telescope.
Tei-Wei-
I don’t know the answer, for sure, but I think this would be a significant effect. I think the fact that focal plane would probably be more important than the lenses and a camera tilt would be one degree of freedom, for instance, would then affect the OPD in a way that is different than a simple rotation of the other things. So it would even be more complicate than the OPD rotating a pattern one way due to the mirrors, and another way due to the camera. In other words, by doing a simple rotation of the OPDs you would be assuming that the entire camera is always perfectly located, which clearly a bad assumption.
I’d be happy to implement this, but I need some funding to do it.
> 2. What we cared about now is to rotate the camera only and check the OPD or donuts. Not the spider and tracking. Why do you feel these two are important?
>
Yeah, these two would not affect the OPDs significantly, although there could be some subtle effects. They are more important in looking at diffraction spikes, astrometry of sources, ellipticity near the edge of the field, etc.
john
> Could you help to answer these questions?
>
> Thank you!
>
> Te-Wei Tsai
> On 8/9/2019 6:44 AM, John Peterson wrote:
>>
>> Te-Wei & Bo-
>>
>> I investigated this further. The two angles work as follows: 1) rotskypos rotates the sky with respect to the camera, 2) rottelpos rotates the rest of LSST (mirrors, spider) with respect to the camera. Thus, rotskypos would rotate the opds around the focal plane (as you have seen), whereas rottelpos would rotate the OPD patterns around their individual centers. However the second effect isn’t fully in phosim. There is the correct rotation of the spider & also tracking rotation is done correctly, but not the mirrors shapes relative to the camera which would give you the effect you should see on the OPDs. It wouldn’t be as simple as rotating the OPDs individually, because the lenses don’t rotate with respect to the focal plane.
>>
>> I am happy to implement this and get the system engineering repos fixed up, but I really need a contract to dive into this as OPDs & sys eng data are not even in the public version (hence, cc’ing Steve & Victor).
>>
>> Best Regards,
>>
>> John
>>
>>
>>
>>> On Aug 8, 2019, at 11:11 AM, Te-Wei Tsai <ttsai@lsst.org> wrote:
>>>
>>> Hi John,
>>>
>>> Please let me answer this question. The images are (1) rotskypos = rottelpos = 0, (2) rotskypos = 45, rottelpos = 0, and (3) rotskypos = 0, rottelpos = 45 from the left to right (R22_S11 is used).
>>>
>>> <imgRotMultiDonut.png>
>>>
>>> We are worried about we have no idea which command we should use in PhoSim to rotate the OPD image correctly. Although we could rotate the OPD by ourselves, it should be nice and helpful that the PhoSim has provided the related function to use.
>>>
>>> Thank you!
>>>
>>>
>>> Te-Wei Tsai
>>> On 8/8/19 7:58 AM, John Peterson wrote:
>>>>
>>>> Bo-
>>>>
>>>> well one of the angles should rotate around the focal plane (apparently, that is rotskypos) and then the other should rotate the opd image around. I can’t tell from the images you sent whether that is happening or not? Can you tell?
>>>>
>>>> I am worried that the second isn’t implemented fully.
>>>>
>>>> john
>>>>
>>>>> On Aug 2, 2019, at 1:35 AM, Bo Xin <bxin@lsst.org> wrote:
>>>>>
>>>>> Hi John and Te-Wei,
>>>>>
>>>>> According to this figure (attached, or can be found on this page
>>>>> https://confluence.lsstcorp.org/display/LTS/Closed-Loop+Simulation+with+Non-Zero+Camera+Rotation+Angle#/
>>>>> ) rottelpos seems not doing anything to the images on the CCD.
>>>>> Can you help me understand why?
>>>>>
>>>>> The real question is - In PhoSim, if I want to keep everything else same, only to add a rotation to the camera rotator, what command should I use?
>>>>>
>>>>> Thanks!
>>>>> Bo
>>>>>
>>>>>
>>>>> <image.png>
>>>>>
>>>>> On Tue, Jul 30, 2019 at 7:01 AM John Peterson <peters11@purdue.edu> wrote:
>>>>>
>>>>>
>>>>> Te-Wei-
>>>>>
>>>>> i believe “rottelpos” is what you need.
>>>>>
>>>>> You can find more here:
>>>>>
>>>>> https://bitbucket.org/phosim/phosim_release/wiki/Instance%20Catalog
>>>>>
>>>>> there is a lot new documentation in the past few months, so follow the links around.
>>>>>
>>>>> Regards,
>>>>>
>>>>> John
>>>>>
>>>>>
>>>>>
>>>>>> On Jul 29, 2019, at 11:46 AM, Te-Wei Tsai <TTsai@lsst.org> wrote:
>>>>>>
>>>>>> Hi John,
>>>>>>
>>>>>> May I know is there any instance command I can use in PhoSim to rotate the camera instead of sky?
>>>>>>
>>>>>> I knew there is a rotskypos instance command to rotate the sky. However, the optical system (optical path difference, OPD) keeps the same. This means the wavefront error calculated from the defocal image keeps the same between rotskypos=30 and rotskypos=0, for example. (I used the central donut image, which has the field position of (0, 0)).
>>>>>>
>>>>>> The reason for this is because I am dealing with the camera image that has a non-zero rotation angle now. You could imagine that the calculated OPD based on the CCD eimage should be rotated as well because of the readout x, y direction of CCD has been rotated.
>>>>>>
>>>>>> If there is no such camera rotation command in PhoSim, I could rotate the image by myself also. However, I am not sure if the rotskypos=30 and the sky rotates 30 degree, the OPD on camera by CCD eimage should rotate 30 or -30 or other angles. May I have some comments from you?
>>>>>>
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> Te-Wei Tsai
>>>>>>
>>>>>> Software engineer, LSST T&S team
>>>>>>
>>>>>
>>>>
>>