EFAC and EQUAD
For pulsar timing purpose, ToAs can be created precisely by determining the phase offset between each observed pulse profile and a reference profile (known as standard template) through cross-correlation algorithms. Assuming that the intensity of the profile of an individual pulse, $P(t)$ is a shifted and scaled version of the template, $T(t)$, plus Gaussian measurement error $N(t)$, (for details, see Taylor 1992):
which can be expressed either in the time or in the phase domain within one folding period. $a$ is an arbitrary intensity shift, $b$ is the intensity scaling factor and $\tau$ is the phase offset.
The uncertainty in the ToA determination process is approximately the ratio of the pulse width, $W$, to the $S/N$, which is defined as the ratio of the power of a signal to the noise fluctuations. The ToA uncertainty can be expressed as (for further details, please refer to Lorimer & Kramer 2012):
where $S_{\textrm{sys}}$ and $S_{\textrm{mean}}$ is the system equivalent temperature and the pulsar’s mean flux density, respectively. Here, $t_{\textrm{obs}}$ is the integration time, $\Delta f$ is the bandwidth and $P$ is the spin period of the pulsar.
Once the ToAs and their related uncertainties have been determined, a linear least-squares method is normally performed to estimate the pulsar parameters and generate timing residuals by minimizing the reduced chi-squared value, $\chi_r^2$, which effectively describes the goodness of fit of the model:
Notice that the least-squares timing model fits are performed on the basis of assuming radiometer noise to be the only source of error in the ToAs. However, this is not always the case, for some pulsars, the ToA uncertainties tend to be too small and thus yield large $\chi_r^2$ values. In addition, some pulsars, would also show a noticeable red spectral pattern in their residuals which worsen the least-squares model.
A conservative way to solve this problem is to increase the size of each errorbar until the reduced chi-squared turn to unity. Generally, this can be archived by either multiplying a constant factor, EFAC to account for possible mis-calibration from a particular system, or adding in quadrature a constant additional uncertainty value, EQUAD, to make up additional sources of time independent noise, such as the intrinsic jitter noise inherited from pulse emission perturbations, which should be pulsar-dependent and observing-system-independent.
The revised ToA uncertainties, $\hat{\sigma}_{\textrm{ToA}}$, can then be expressed as:
Brief summary:
EFAC is introdueced to account for possible mis-calibration of this radiometer noise, acting as a multiplier for all the TOA error bars for a given pulsar, observed with a particular system.
EQUAD, added in quadrature, is used to represent some additional source of time independent noise, (i.e. jitter noise). A single EQUAD parameter is available to include for all TOAs
ECORR
ECORR, namely the ‘error correction factor’, describes short-timescale noise process that has no correlation between observing epochs, but correlated in frequency, data obtained simultaneously at different observing frequencies.
This parameter is only used by NANOGrav data and not applicable to EPTA and PPTA data.
Parameters applied to Tempo2 and Tempo
EFAC & EQUAD
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.
ECORR
tempo accepts ECORR only.
tempo2 accepts either ECORR or TNECORR, they are treated identically.
T2ECORR is not a thing.
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.
