SATJUMP in PINT?

[abhisrkckl]

TEMPO2 has a jump parameter called SATJUMP that works similar to JUMPs, but applies a correction to the BATs instead of the phase. Are there plans to implement this in PINT? As far as I can see, there is a DelayJump component in PINT that seems conceptually similar to this, but is disabled.

(SATJUMP is a misnomer, I guess. They should better be called BATJUMPs according to the above definition.)

[abhisrkckl]

Here is a discussion on this from IPTA slack.

[paulray]

Interesting, I was not aware of that parameter in Tempo2. I see that the PINT JUMPs use PhaseJump. Of course the jump magnitude is specified in the par file as a time, and the PhaseJump converts it to a phase using model.F0.value, which can be really wrong for some situations. It would indeed be good to have real delay jumps.

[paulray]

Ah, I see the discussion with Mike Keith now. I agree with him that large backend-specific time offsets should be done in the data processing before TOAs are formed. In PSRFITS, there is a keyword called something like BE_DELAY that handles this.

[abhisrkckl]

Yes. Applying BE_DELAY indeed turned out to be the correct solution for the large delays I mention in the slack discussion above. But there still can be use cases for real delay jumps, such as when the FITS files are not available and the delay is expected to be small compared to the period so that the second-order effects don't matter.

[aarchiba]

PINT's DelayJumps are supposed to be this, but they have lain unused since they were implemented - there has never even been a way to specify them in a par file. It would not be too hard to get them working - let them be called SATJUMP and find everywhere JUMPs have been fixed and port the fixes across. And come up with some meaningful test cases so they don't passively break again.

I think the key thing SATJUMPs provide compared to adjusting TOAs is that they can be fit. I suppose this could be useful for determining backend delays?

[abhisrkckl]

Yes. A concrete use case will be GMRT data where the backend delays are corrected using be:delay flags. It will be useful to try fitting for a SATJUMP there to confirm that it is consistent with zero (i.e., the be:delay is correct).

[abhisrkckl]

I would like to try my hand at this just to get started with PINT development.

[aarchiba]

I'm afraid JUMPs are a little messy but I have some familiarity with the code and am happy to answer questions. Most of the messiness doesn't need to be replicated in the SATJUMPs.