Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Status buffer RA and Dec values should be in J2000 epoch #15

Open
david-macmahon opened this issue May 25, 2020 · 2 comments
Open

Status buffer RA and Dec values should be in J2000 epoch #15

david-macmahon opened this issue May 25, 2020 · 2 comments
Assignees
Labels
metadata This involves metadata

Comments

@david-macmahon
Copy link

RA and Dec values that get published to the compute nodes' status buffers as RA, RA_STR, DEC, and DEC_STR should be in the J2000 epoch. If we are given RA/Dec in the current epoch, we will have to un-precess it back to J2000 epoch before publishing to the status buffers.

@david-macmahon david-macmahon added the metadata This involves metadata label May 25, 2020
@david-macmahon
Copy link
Author

I confirmed that the RA/Dec values stored in the RAW headers on 2020-08-13 are still in current epoch rather than J2000. Using blpn58:/datax2/20200813/test5/Unknown/GUPPI/guppi_59074_54336_004444_J1939-6342_0001.0000.raw as an example:

The calibrator catalog gives the coordinates as RA=19:39:25.05, Dec=-63:42:43.63, which are the J2000 coordinates of this object. The file contains:

DEC     =     -63.665638888888893
RA      =      295.33258333333333

These values correspond to RA=19:41:19.820, Dec=-63:39:56.300, which are far closer to the results of precessing the J2000 coordinates to 2020.67 (roughly the date of observation) than the original J2000 coordinates. I used http://www.bbastrodesigns.com/precession.html to perform the precession for this comparison.

@david-macmahon
Copy link
Author

I noticed that the bluse.yaml file created by the MeerKAT USE observing script generator, astorkat-use-observation.py, includes precessed RA/Dec values rather than J2000 RA/Dec values. I wonder if that's the right thing to be doing. It seems a bit strange that the observing script creator should be responsible for precessing the coordinates since that requires knowledge of when the schedule block will be run, but may be that's how it actually works???

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
metadata This involves metadata
Projects
None yet
Development

No branches or pull requests

2 participants