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

TZRMJD doesn't round-trip to a par file exactly #519

Open
aarchiba opened this issue Sep 12, 2019 · 1 comment
Open

TZRMJD doesn't round-trip to a par file exactly #519

aarchiba opened this issue Sep 12, 2019 · 1 comment

Comments

@aarchiba
Copy link
Contributor

If I have a timing model that includes TZRMJD, and I then write it to a par file and read that back in, the value I read back in is not equal to the value I wrote out. The difference is less than a nanosecond but it should be a matter of writing a number to a file and reading it back in. Does this hint at a problem in our longdouble handling, or is it just a bug in how parameters are handled? Is it an issue of long double versus Time objects?

Test case in PR #518

@paulray
Copy link
Member

paulray commented Dec 2, 2019

This may or may not be the same thing, but I am worried that the clock corrections are not getting taken out of TZRMJD before it is written. The code in absolute_phase.py that makes a fake TOA out of the TZR parameters seems to apply the clock corrections when the TOA table is build with get_TOAs_list(). So, those clock corrections should be removed when writing the TZRMJD to a par file. I don't see where that gets done. Or maybe I'm wrong because the TZRMJD parameter is always the raw TOA time and the corrected time is only stored in the temporary TOAs object that gets created for calculations? @luojing1211 is that right?

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

No branches or pull requests

2 participants