You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
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?
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
The text was updated successfully, but these errors were encountered: