PINT doesn't recognize P0

[tcromartie]

PINT doesn't recognize P0 (as opposed to F0) (discovered when running event_optimize with a parfile that contains P0)

[luojing1211]

We will fix this. Is it necessary to have higher-order of spin period derivatives (higher than P1)?

[tcromartie]

Hmm... I'm not sure. Since basically everyone will be using F0 instead, I would be surprised. But probably worth asking @scottransom. Thanks!

[scottransom]

I don't think it is necessary. I'm not sure what tempo2 does, but I think that in TEMPO it is just a convenience and it converts P0 to F0 internally and then outputs that. So it could even be something in model_builder that just does the same conversion. Although P1 might be recognized as well. Anyway, internally frequencies are used and only frequencies are output.

[kstovall]

tempo2 and tempo handle it in the same way. Both recognize P0 and P1, but P2 and above are ignored. Both of them immediately convert P0 and P1 to F0 and F1 and use that for calculations and then output F0 and F1. I think it would be good to have PINT work the same way. We could think about giving a warning if P2 and above exist, saying they are being ignored. tempo and tempo2 just ignores them and uses F0 and F1, but don't say that this is what is happening. But, I have never put in a P2 myself and don't think I would ever do this, so I don't think this would be needed very often, if ever. Kevin

…

On Thu, Aug 9, 2018 at 9:51 AM, Scott Ransom ***@***.***> wrote: I don't think it is necessary. I'm not sure what tempo2 does, but I think that in TEMPO it is just a convenience and it converts P0 to F0 internally and then outputs that. So it could even be something in model_builder that just does the same conversion. Although P1 might be recognized as well. Anyway, internally frequencies are used and only frequencies are output. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#410 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAJ2oHze7L5hMIhU0nm7iBXlZPKVsS3rks5uPFqYgaJpZM4V14ZB> .

-- Kevin Stovall NANOGrav Physics Frontier Center Postdoctoral Fellow National Radio Astronomy Observatory Socorro, NM (P) (575) 835-7098 (E) [email protected]

[paulray]

I think it should throw an error (not just a warning) if P2 or higher is in the par file (if that is not supported and thus is being ignored). I'm timing a ULX pulsar where P2 is often used in published ephemerides. Just because us fast pulsar people rarely use P2 doesn't mean it isn't a valid use case.

[kerrm]

What's the status on this one? Sounds like we have a plan (convert P0 and P1, error on P2). Or if P2 really is used, why not implement it, too? Just a few more lines of algebra.

[luojing1211]

It dropped out from my radar. I think we can make a translator for the parameter converting. -Jing

…

On Wed, Feb 17, 2021 at 11:30 AM kerrm ***@***.***> wrote: What's the status on this one? Sounds like we have a plan (convert P0 and P1, error on P2). Or if P2 really is used, why not implement it, too? Just a few more lines of algebra. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#410 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABIUBA6PYWARBXUJHVKCHGLS7PVMDANCNFSM4FOXQZAQ> .