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

Overly general logic for pulsar distance priors #13

Open
bencebecsy opened this issue Jul 26, 2024 · 3 comments
Open

Overly general logic for pulsar distance priors #13

bencebecsy opened this issue Jul 26, 2024 · 3 comments

Comments

@bencebecsy
Copy link
Collaborator

Sarah Burke-Spolaor raised this. In QuickCW.per_pulsar_prior, we check for DM distance first and only after look for PX. In reality PX is superior, so we should use that if we have it.

However, this logic is already applied when putting together the dictionary with pulsar distances. So if a pulsar has parallax we do not even bother putting DM information in that dict. And the dictionary itself has a 3-element list for each pulsar, like this: [mean, error, method_flag], such that method_flag is PX if we have parallax information, and DM if not. So the current code is actually a bit too generic. It shouldn't really look for DM and PX anywhere in that list. It should just check if the third element is DM or if it is PX.

@scottransom
Copy link
Member

Don't we always have PX values, though? In the 12.5yr and 15yr timing pipelines, we made it a policy to always fit for parallax, whether we can measure it or not. And that means that sometimes the distance constraints are terrible with parallax. Basically we need a 3-4-sigma parallax detection before you should think of it as being "good" or at least better than a DM distance. Also note that there are some pulsars with other distance constraints from dynamical effects (like the Kopeikin params) or VLBI parallax (which we do not track in the par files). In general, there should be a way to override both parallax distances and DM distances if we have that information.

@bencebecsy
Copy link
Collaborator Author

Yes, overriding the psr distance in the par file with the best available distance information is exactly the intention here. This was first explored by Caitlin Witt for the 12.5yr, and we followed a similar approach for the 15yr search too. We used Shami's list of known parallaxes (https://hosting.astro.cornell.edu/~shami/parallax/) plus the parallaxes in the par files. For pulsars where the error from that was lower than some threshold, we used that. For the rest we used DM based distance.

@bencebecsy
Copy link
Collaborator Author

Following Sarah Burke-Spolaor's suggestion, the only concern here is that if the dictionary with pulsar distances is not formatted right the code might interpret it wrong without giving any errors. So I will make this piece of code more specific, so that it actually gives an error if the formatting is not as expected. Plus I will add a description of the expected format in the readme

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