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

Residuals sorting issue in timing.py #222

Open
hquelquejay opened this issue Jan 4, 2024 · 0 comments
Open

Residuals sorting issue in timing.py #222

hquelquejay opened this issue Jan 4, 2024 · 0 comments
Labels
bug Something isn't working

Comments

@hquelquejay
Copy link

It appears that the tm_delay function in timing.py is not returning the expected residuals due to an additional sorting.

To calculate the TM deviation residuals, the code subtracts the new residuals (from the new TM set of parameters) and the old residuals (from the parfile solution) using residuals[isort] - new_res[isort].

However, the residuals array comes from the enterprise pulsar object property and is already sorted via _residuals[isort]. Reordering it again using [isort] results in incorrect ordering and, consequently, inaccurate TM deviation residuals.

As demonstrated below with the example of a 1 sigma F0 deviation for PSR J0030+0451, the get_delay function returns residuals that do not match the expected outcome (a straight line in the case of a F0 deviation).

TM_delayres_F0_J0030+0451_ENT_version

Replacing residuals[isort] - new_res[isort] with residuals - new_res[isort] solves this issue and produces the anticipated straight line.

Note: new_res must be sorted (to match enterprise ordering) since it is constructed using the tempo2 pulsar object.

@AaronDJohnson AaronDJohnson added the bug Something isn't working label Mar 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants