search

transientskp / tkp

A transients-discovery pipeline for astronomical image-based surveys
http://docs.transientskp.org/
BSD 2-Clause "Simplified" License
19 stars 15 forks source link

altaz module produces incorrect values #554

Closed AntoniaR closed 2 years ago

AntoniaR commented 6 years ago

https://github.com/transientskp/tkp/blob/77f61ff025e3614ee409faebad8266846b2cf68f/tkp/utility/coordinates.py#L172

The altitude calculated by the altaz function (see link above) is incorrect. As the altaz function does not use the longitude of LOFAR in the calculation, I suspect that this is the issue...

Using this website: http://www.stargazing.net/mas/al_az.htm I checked the altitude and azimuth of an event at RA, Dec = 170.112, +24.956 (11h 20m 27s, +24d 57' 22") above the LOFAR core at latitude, longitude = 52.9088, -6.8689 (N,W) equivalent to: 52° 54' 19.19" N, 6° 52' 4.79" E. Using the time of the GRB as 18/04/18T06:44:06 UT (8:44:06 NL time, 5030750646.0 mjds).

The website gives: Alt = -11:58:27, Az = 354:37:20

The altaz module gives: (61.75228736901352, 190.38104601834004) (Alt,Az)

Even without conversion to sexigesimal, it's clear that one is well above the horizon and one is well below the horizon!

I think this function is only used in the LOFAR CASA image quality control, but these numbers should not be trusted until this is fixed... I will switch to astropy for my triggering use case.

AntoniaR commented 6 years ago

Apologies, made error on the website time as put in the local time instead of UTC. The website actually gives: Alt = -06:06:45, Az = 327:41:28

Using astropy I get a value consistent with the website of: ( 327.45312655, -6.12587808) (Az,Alt) Which is also clearly different to the LOFAR altaz function...

jdswinbank commented 6 years ago

As the altaz function does not use the longitude of LOFAR in the calculation, I suspect that this is the issue...

I know nothing about the problem with this particular function, but note that this isn't strictly true.

altaz calls mjds2lst calls mjd2lst which references IRTF_X, ITRF_Y and ITRF_Z, which “Should be a good approximation for anything refering to the LOFAR core".

jdswinbank commented 6 years ago

By the way — it looks like the altaz function has never been properly tested, so it's not altogether surprising if it's wrong. I suggest that a useful exercise would be to replace all the home-grown logic in coordinates.py with calls to AstroPy or pyrap.

AntoniaR commented 6 years ago

Thanks for clarification. Will add implementing astropy/pyrap onto the TraP to-do-list

AntoniaR commented 4 years ago

Implementation of astropy to replace these functions may be covered by the upgrade to Python 3, Mark can you investigate this and decide if best for release 5.0 or a target for release 6.0? Thanks!