# AOS rotation: explore rotSkyPos and rotTelPos for a diffracted star and a galaxy

XMLWordPrintable

#### Details

• Type: Improvement
• Status: Done
• Resolution: Done
• Fix Version/s: None
• Component/s:
• Labels:
• Story Points:
1
• Team:
Telescope and Site

#### Description

Simulate an object that would show spider-related diffraction spikes (eg. a star) and an extended object (eg. a galaxy). Vary rotTelPos and rotSkyPos. Explore four test cases:

1: vary rotSkyPos = 0,30,60 ,  keep rotTelPos = 0

2.  keep rotSkyPos = 0 , vary  rotTelPos 0,30,60

3. no rotSkyPos, vary  rotTelPos 0,30,60

4.  vary rotSkyPos = 0,30,60,  no rotTelPos

#### Attachments

1. image-2022-04-06-14-37-31-813.png
597 kB
2. image-2022-04-06-14-37-56-043.png
704 kB
3. image-2022-04-06-14-39-14-993.png
805 kB
4. image-2022-04-06-14-39-46-754.png
700 kB
5. image-2022-04-06-14-40-25-742.png
700 kB
6. image-2022-04-06-14-43-04-397.png
806 kB
7. image-2022-04-06-14-43-23-839.png
705 kB
8. image-2022-04-06-14-45-55-227.png
800 kB
9. image-2022-04-06-14-46-15-925.png
706 kB
10. image-2022-04-06-14-47-07-277.png
801 kB
11. image-2022-04-06-14-49-32-909.png
463 kB
12. image-2022-04-06-14-50-33-747.png
467 kB
13. image-2022-04-06-14-51-12-739.png
437 kB

#### Activity

Hide
Andrew Connolly added a comment -

Can you write a summary conclusion from this work - what is it telling us. Is this saying that phosim doesnt model the camera rotation and so is not useful for testing WFS with a non-zero rotation?

Show
Andrew Connolly added a comment - Can you write a summary conclusion from this work - what is it telling us. Is this saying that phosim doesnt model the camera rotation and so is not useful for testing WFS with a non-zero rotation?
Hide
Krzysztof Suberlak added a comment -

Phosim models camera rotation as well as sky rotation. However, the rotTelPos, which is the angle of telescope relative to camera in decimal degrees (also called camtelangle) is considered a  "standard" input according to PhoSim documentation https://bitbucket.org/phosim/phosim_release/wiki/Instance%20Catalog . In contrast,   rotSkyPos which is the angle of sky relative to camera coordinates (from North over East) in decimal degrees  (also called camskyangle), is considered one of the "advanced" inputs (which can be calculated self-consistently with  PhoSim). Calculation of one or the other is invoked here https://github.com/lsst-ts/phosim_syseng4/blob/6105fcf9d65b37d2d157be1f99d70dc263da0e76/source/atmosphere/main.cpp#L315-L332 using the following functions https://github.com/lsst-ts/phosim_syseng4/blob/6105fcf9d65b37d2d157be1f99d70dc263da0e76/source/atmosphere/operator.cpp#L127-L138  . Thus case3 above seems most realistic - in the real world, we can't move the sky around (objects are fixed in the sky at a given moment), we can only slew the telescope (move "left/right" or "up/down" in the alt/az  fork mount like LSST), and then rotate the camera (so that the lower edge of the FOV is not aligned with the horizon, but follows the sky movement, see https://telescopemount.org/alt-az-mounts-for-long-exposure-astrophotography-camera-rotators/ ).

Show
Krzysztof Suberlak added a comment - Phosim models camera rotation as well as sky rotation. However, the rotTelPos, which is the angle of telescope relative to camera in decimal degrees (also called camtelangle) is considered a  "standard" input according to PhoSim documentation https://bitbucket.org/phosim/phosim_release/wiki/Instance%20Catalog  . In contrast,   rotSkyPos which is the angle of sky relative to camera coordinates (from North over East) in decimal degrees  (also called camskyangle), is considered one of the "advanced" inputs (which can be calculated self-consistently with  PhoSim). Calculation of one or the other is invoked here https://github.com/lsst-ts/phosim_syseng4/blob/6105fcf9d65b37d2d157be1f99d70dc263da0e76/source/atmosphere/main.cpp#L315-L332  using the following functions https://github.com/lsst-ts/phosim_syseng4/blob/6105fcf9d65b37d2d157be1f99d70dc263da0e76/source/atmosphere/operator.cpp#L127-L138   . Thus case3 above seems most realistic - in the real world, we can't move the sky around (objects are fixed in the sky at a given moment), we can only slew the telescope (move "left/right" or "up/down" in the alt/az  fork mount like LSST), and then rotate the camera (so that the lower edge of the FOV is not aligned with the horizon, but follows the sky movement, see https://telescopemount.org/alt-az-mounts-for-long-exposure-astrophotography-camera-rotators/  ).
Hide
Krzysztof Suberlak added a comment - - edited

This shows that the rotTelPos command does not fully rotate the camera, but only the spider . The camera is kept at a fixed angle wrt M1M2, and the only thing that rotates due to changing "rotTelPos" is the spider. This means that if we want to model camera rotation with PhoSim, we could  eg.  rotate the calculated grid surface for the mirrors (i.e. rotate the mirrors rather than the camera).

Show
Krzysztof Suberlak added a comment - - edited This shows that the rotTelPos command does not fully rotate the camera, but only the spider . The camera is kept at a fixed angle wrt M1M2, and the only thing that rotates due to changing "rotTelPos" is the spider. This means that if we want to model camera rotation with PhoSim, we could  eg.  rotate the calculated grid surface for the mirrors (i.e. rotate the mirrors rather than the camera).
Hide
Andrew Connolly added a comment -

Looks good - so the only option for phosim is to rotate the perturbations of the mirrors?

Show
Andrew Connolly added a comment - Looks good - so the only option for phosim is to rotate the perturbations of the mirrors?
Hide
Krzysztof Suberlak added a comment -

Yes, it appears so.

Show
Krzysztof Suberlak added a comment - Yes, it appears so.

#### People

Assignee:
Krzysztof Suberlak
Reporter:
Krzysztof Suberlak
Reviewers:
Andrew Connolly
Watchers:
Andrew Connolly, Krzysztof Suberlak
0 Vote for this issue
Watchers:
2 Start watching this issue

#### Dates

Due:
Created:
Updated:
Resolved:
Start date:
End date:

#### Jenkins

No builds found.