Open wfarah opened 2 years ago
Example of issue:
In [41]: from ATATools import ata_control
In [42]: ata_control.get_source_ra_dec('3c454.3')
Out[42]: (22.89900016784668, 16.148000717163086)
In [43]: print("Real 3c454.3 coordinates: 22.899374,16.148211")
Real 3c454.3 coordinates: 22.899374,16.148211
For whatever reason, the ra/dec return value was being rounded to 3 decimal places in Java-land. I have updated this class. Please restart the REST server whenever is an opportune time to reload the change and let me know the result.
Solved, closing issue
@tkoumrian opening this again.
I noticed the output of get_source_ra_dec
changes with every call.
In [1]: from ATATools import ata_control
In [2]: ata_control.get_source_ra_dec('3c273')
Out[2]: (12.485193252563477, 2.0523903369903564)
In [3]: ata_control.get_source_ra_dec('3c273')
Out[3]: (12.485194206237793, 2.052386522293091)
In [4]: ata_control.get_source_ra_dec('3c273')
Out[4]: (12.485193252563477, 2.052388906478882)
In [5]: ata_control.get_source_ra_dec('3c273')
Out[5]: (12.485193252563477, 2.052391767501831)
In [6]: ata_control.get_source_ra_dec('3c273')
Out[6]: (12.485193252563477, 2.0523948669433594)
another source:
In [7]: ata_control.get_source_ra_dec('IL_Aqr')
Out[7]: (22.888273239135742, -14.266688346862793)
In [8]: ata_control.get_source_ra_dec('IL_Aqr')
Out[8]: (22.888273239135742, -14.26668930053711)
In [9]: ata_control.get_source_ra_dec('IL_Aqr')
Out[9]: (22.888275146484375, -14.266692161560059)
In [10]: ata_control.get_source_ra_dec('IL_Aqr')
Out[10]: (22.888275146484375, -14.26668930053711)
In [11]: ata_control.get_source_ra_dec('IL_Aqr')
Out[11]: (22.888275146484375, -14.266690254211426)
In [12]: ata_control.get_source_ra_dec('IL_Aqr')
Out[12]: (22.888275146484375, -14.26668930053711)
I checked and the errors are around what is expected for rounding point errors if using IEEE float32 for the computations. Might that be correct?
I recall the return value from Java is float32 not sure about the computation. I’ll have another look.
I checked and the errors are around what is expected for rounding point errors if using IEEE float32 for the computations. Might that be correct?
— Reply to this email directly, view it on GitHubhttps://github.com/SETIatHCRO/ATA-Utils/issues/25#issuecomment-1082262867, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AM44SQIVDR3L643EJFRCNBDVCNHTZANCNFSM5RCUFNEQ. You are receiving this because you were mentioned.Message ID: @.***>
Good news, the ra/dec calculation is in double, so I just need to propagate that up through the layers instead of float.
@wfarah I've restarted the REST server and it should be returning Java double ra/dec values. See if that helps.
Inconsistancy addressed in https://github.com/SETIatHCRO/restgw/issues/2
ata_control.get_source_ra_dec
(https://github.com/SETIatHCRO/ATA-Utils/blob/master/pythonLibs/ATATools/ata_control.py#L162-L189) is returning values that are apparently only accurate to 3 decimal parts. Assuming a rounding is happening, a maximum error of 0.0005 would result in RA and Dec. RA is expressed in hours, and so the effect would be ~27 arcseconds, whereas dec would be 1.8 arcseconds. The digitizer board delay engine uses this utility function to phase center the array, thus these values have to be accurate to sub-arcsecond level.