PINT is not as compatible with TEMPO/TEMPO2 as it could be

[aarchiba]

It would be valuable if PINT emitted .par and .tim files that TEMPO interpreted in as similar a way to PINT as it is able. A number of modifications on the TEMPO side have resolved some issues but Joe Swiggum and David Nice have identified the following points where PINT could do better:

• .tim files should start with MODE 1 as well as FORMAT 1 (to tell TEMPO to use TOA uncertainties?)
• TEMPO expects noise parameters with different names (for example EFAC -> T2EFAC, I think); TEMPO2 also needs the error parameters to start with T2.
• TEMPO is not as flexible about observatory names as PINT/TEMPO2 - specifically (I think) it only recognizes ao not arecibo
• TEMPO does not like SWM (and TEMPO2 and PINT only support one solar wind model)
• TEMPO does not like CHI2 (and no one needs it)
• TEMPO2 only supports ECL IERS2003 (and ignores ECL)

If we find others or want to clarify TEMPO's needs, we can put that here.

[pennucci]

For the record, MODE 1 --> yeah, tells tempo to use the TOA uncertainties in the fit and FORMAT 1 --> indicates that TOAs are in the modern tempo2 format without fixed-space allocation for each. Having these would be nice conveniences to avoid the need for a timing_analysis post-processing conversion step/

[aarchiba]

Thanks! I think it should be possible to do without a conversion step, although because of ephemeris and other differences we'll probably find that solutions that have converged for PINT haven't fully for tempo and tempo2. But they should be close.

[aarchiba]

Some notes from today's PINT meeting:

• I think that, even for TEMPO, putting MODE 1 in the par file (which we do, or can do), has the same effect as putting MODE 1 in the tim file, except that putting it in the tim file makes various programs emit warnings because it's the old way of doing things.
• PINT does, and TEMPO does, support different values of ECL, so emitting an ECL statement is a good idea and doesn't bother TEMPO2; if users want a TEMPO2-compatible par file they should use ECL IERS2003, which may just be a different coordinate system or may have some built-in inaccuracies, I'm not sure.
• PINT's DDK assigns a different meaning to the parameter KOM than TEMPO and TEMPO2 with the same model (if the position is specified using ecliptic coordinates); PINT's is always referenced to equatorial north while in this situation TEMPO/TEMPO2 reference it to ecliptic north. This inconsistency has already bitten users, requiring several steps of fitting to resolve. There are consistency-of-design arguments for PINT defining it the way that it does; it would be technically feasible for PINT's DDK to accept either KOM, which would be referenced to whatever astrometry system is in use, or to accept KOM_EQUATORIAL, which would be referenced to equatorial north regardless (and model validation would refuse models where both were set/unfrozen, and a conversion function could be made available); this proposal would ensure that PINT interpreted TEMPO/TEMPO2 models the same way they did but that it made available its native definition for users who preferred that.
• PINT does not support BINARY T2, and emitting a par file that contains that could only be appropriate in some sort of "export to other programs" mode. It is not clear to me when if ever that would be necessary; as I understand it all the major binary models PINT supports are also supported by TEMPO and TEMPO2.

Not from the meeting but other incompatibilities worth mentioning:

• PINT's BT supports multiple orbital frequency derivatives (e.g. FB3) which are not available from BT in TEMPO or TEMPO2 but which are available from (some versions of) BTX (I'm not clear at this moment in which program; BTX in TEMPO but not TEMPO2 can also be used to support multiple non-interacting Keplerian orbits).
• PINT's ELL1 may be accurate for larger eccentricities/higher accuracy requirements than that in TEMPO/TEMPO2; it is unclear whether the "it is good enough" calculation reflect the limitations of PINT's model or TEMPO/TEMPO2's.

[aarchiba]

Further notes about PINT vs. tempo vs. tempo2 observatory names in tempo2-format files:

• tempo2 is basically fine with PINT's long names and has a flexible enough system of aliases to probably cope fine with two-letter ITOA codes or one-letter tempo codes (to the extent that these are standardized).
• tempo takes the first two letters of what it gets as the ITOA code and can't accept anything else. This works fine for PINT's long names except for "arecibo" and "jodrell" which should be "ao" and "jb" respectively.

We could thus obtain tempo-compatible observatory names (in par files too, for TZRMJD, probably) by using "ao" and "jb" for these two, upon request or by default.

[aarchiba]

A few further incompatibilities:

• TEMPO doesn't understand A1DOT only XDOT.
• TEMPO doesn't understand STIGMA only VARSIGMA.

[aarchiba]

Also:

• EFAC -> T2EFAC, EQUAD -> T2EQUAD
• what about ECORR?

[pennucci]

I think it's ECORR-->TNECORR (not T2ECORR).

[aarchiba]

We definitely recognize TNECORR, I'm just unsure whether TEMPO has a preference.

[demorest]

Repeating some stuff I just put on the nanograv trello card:

For ECORR, tempo accepts ECORR only. tempo2 accepts either ECORR or TNECORR, they are treated identically. T2ECORR is not a thing.

Both tempo and tempo2 accept T2EQUAD/T2EFAC. Neither accepts EQUAD/EFAC in the par file. Using EQUAD in tempo2 results in some confusing behavior since the "QUAD" string is also used for other purposes and the parsing is buggy (this specific bug could of course be easily fixed if we wanted to but older versions would still have the issue so might be good practice to avoid EQUAD/EFAC).

tempo2 also accepts TNEF and TNEQ. These have different definition than T2EFAC/T2EQUAD. The order of application is different and I think TNEQ is given as log10(seconds). tempo does not support these. I think we should avoid these for nanograv purposes. If PINT wants to support them someone should double-check the definitions vs tempo2.

For red noise, tempo and tempo2 both accept RNAMP and RNIDX. tempo2 also accepts TNRedAmp and TNRedGam, but the units/definitions are different than RNAMP/RNIDX. As above I think we should avoid the TN params for nanograv, OK if PINT wants to support them more generally though.

[aarchiba]

Some deviations are summarized here: https://github.com/nanograv/PINT/wiki/PINT-vs.-TEMPO%282%29-par-file-changes

The TNRedAmp-family parameters were not-supported only by a bug #1286, resolved in #1335; whether PINT treats them compatibly to TEMPO2 I don't know.