PolishookDavid / LAST_OCS

Code controling the LAST project Observatory
0 stars 0 forks source link

pointing model is likely not included #27

Closed EranOfek closed 1 month ago

EranOfek commented 1 month ago

In the gledmagicwater branch, it seems that the point model is not included, while it was applied in the previous stable branch used in the LAST observing run in March.

We see that in the gledmagicwater headers, ADRA and and ARA (as well as ADDec and ADec) are equal, while in the previous run they were different. The difference between these two parameters is the pointing model offset (taken from LAST_config/obs.PointingModel). To verify this, it seems that the offset in astrometry between images taken in the March run and in the June run are consistent with the point model offsets.

Ruslan can add some examples.

RuslanKonno commented 1 month ago

I was writing the same issue, so I'll just copypaste it here:

The data taken during the June nights of 2024-06-03 to 2024-06-05 show misalignment with reference images taken in March 2024. This is at least confirmed for mounts M1, M3, M6, M8.

Inspecting the headers of the images, e.g.,

/marvin/LAST.01.06.02/2024/06/03/proc/220200v0/LAST.01.06.02_20240603.220150.321_clear_1209_000_001_010_sci_coadd_Image_1.fits

shows that the mount A and AD coordinates are the same, implying that the full pointing correction was not applied. Example for the image above:

M_ARA = 229.5725 /
M_AHA = 28.6867 /
M_ADEC = 20.9185 /
M_ADRA = 229.5725 /
M_ADHA = 28.6867 /
M_ADDEC = 20.9185 /

When registering the June images to the March reference images of the same field, the misalignment is clearly seen. Below is the reference image registered to the example new image.

Screenshot from 2024-06-06 18-41-47

Measuring the misalignment (green lines in the image above) gives similar values to the missing pointing offset

Measured misalignment: (Delta RA, Delta Dec) = ~(0.299, 0.428)

Offset given by the pointing model at (HA, Dec) = (26.668319, 27.098529) (Delta RA, Delta Dec) = ~( -0.220345, -0.451985)

Mind I'm only measuring the absolute misalignment, so I'm ignoring the sign. Also, the offset is taken from the nearest coordinates in obs.pointingModel.06_1.create.yml, which is not exactly the same as the image coordinates, so the shown measured misalignment won't closely match the expected offset, they do agree in the leading order floating point position.

This is consistent with the misalignment seen in at least M1 as well.

EastEriq commented 1 month ago

Code notes:

EastEriq commented 1 month ago

Note that there have been these two recent modifications to AstroPack, which could come (wrongly) into play here:

EranOfek commented 1 month ago

Can you please provide more details into: 437 and 442.

On Thu, Jun 6, 2024 at 10:06 PM EastEriq @.***> wrote:

Note that there have been these two recent modifications to AstroPack, which could come (wrongly) into play here:

— Reply to this email directly, view it on GitHub https://github.com/PolishookDavid/LAST_OCS/issues/27#issuecomment-2153226687, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABJUQ4N5O2AA5FDDACOF6WDZGCXMFAVCNFSM6AAAAABI46L3UOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNJTGIZDMNRYG4 . You are receiving this because you authored the thread.Message ID: @.***>

EastEriq commented 1 month ago

Details of what? The changes done and their original motivation are referenced there. This is why we use a linked ticked system and reference the commits pertinent to each issue.

EastEriq commented 1 month ago

Seems that the problem was in a typo in celestial.convert.j2000_toApparent and apparent_toJ2000 on the AstroPack side. We have now pushed the fix (https://github.com/EranOfek/AstroPack/commit/e4e875f0fd9ffd23fec30da2bb89f0a75dd77190), but the fix has still to be tested on sky. AstroPack should be pulled in the observatory but we are offline at the moment.

Please close when confirmed working.

EastEriq commented 1 month ago

Confirmed solved in last nights images by Ruslan