Explicit Absolute Phase

[paulray]

Traditionally, there is a hidden overall phase offset in TEMPO timing model fitting. It would be better in PINT to make this an explicit parameter that can be fitted for, or not, as desired.

One possibility is to have TZRMJD, TZRSITE, TZRFRQ define the phase 0 and make TZRMJD explicitly a fittable parameter. In this case, the site and frequency could be chosen by the user and would not be chosen according to the strange rules that govern TEMPO and Tempo2's handling of these parameters.

An alternative, suggested by @demorest is to make a new parameter (with a different name!) that is an MJD(TDB) specifying phase 0.0 at infinite frequency at the barycenter. This is simpler from a conceptual standpoint, since the phase model for the pulsar spin is defined in TDB units (modulo issue #37). This new parameter could be fitted or not, as desired by the user. This is somewhat the way it is currently done in PINT, but the parameter name is TZRMJD, which is confusing.

So, we need to make a choice for PINT's implementation and put this functionality in.

[paulray]

Here is a summary of the discussion on the PINT telecon 2016 Dec 5:

What we discussed was not trying to overload the current usage of the TZR* parameters or trying to make them fittable, but rather adding a new parameter (tentatively called PHASE0EPOCH) that is included in the par file and is fittable. This parameter would specify the MJD(TDB or TCB) of phase 0.0, similar to the current PEPOCH, DMEPOCH, and POSEPOCH that specify the 0 points for expanding those values as polynomials.

We mentioned that it should be straightforward to write out the TZR parameters as well, since the delays can be computed to get the TOA arrival time at a particular site and frequency. We thought that probably PHASE0EPOCH would be identical to TZRMJD as long as TZRSITE was SSB and TZRFREQ was 0.0 (infinity), but we weren't 100% certain of this. Still we kept PHASE0EPOCH separate from the TZR parameters because we want it treated differently as a fittable parameter and the origins of the TZR names are obscure.

With PHASE0EPOCH as part of the model, there is no need for sticking an extra column in the design matrix to account for an arbitrary phase. And the residuals can be computed directly from the model, with no need to subtract any kind of mean (weighted or unweighted).

[paulray]

There is an interesting issue here with using a phase 0 epoch specified at the barycenter. If you change the planetary ephemeris, it won't move. So in a sense the phase 0 epoch specified in TDB depends on the ephemeris, while one specified at a topocentric observatory is a direct measurable and will flow through the delay calculations using the chosen planetary ephemeris.

[scottransom]

You mean that if you change the ephemeris, it will move, right? i.e. the SSB shifts and therefore, so does phase 0.0 (by a tiny amount, <~ a couple hundred meters, so of order a microsec).

[paulray]

@scottransom, what I mean is that there is an implicit ephemeris in any specification of a barycentric TDB time. So, if you change the ephemeris you are using, then presumably that barycentric TDB time of phase 0 should move, but it won't.

[kerrm]

I've always kindof understand this as a drawback/caveat of using a TDB phase reference: you remove all of the observatory cruft, but you are tied by necessity to an ephemeris. Are you suggesting that we should encode that (e.g. BARY_DE421) and adjust it automatically if a new SSE is used? Or warn (ugh) that it's possible it will shift whenever it's loaded?