Tempo2 uses TNRedCorner even if not set

[Michael Keith]

I would like to disclose a bug I have recently found in tempo2 relating to the interpretation of “TempoNest” style red noise models produced from temponest or enterprise. Specifically it relates to the red noise models used when adding parameters like TNRedAmp, TNRedGam into the par file.

The bug is that tempo2 always used the form of the red noise PSD where there is a corner frequency (which can be set with TNRedCorner) rather than the pure power-law model that is by default used in enterprise or temponest. The default assumed corner frequency is 1/100yr, so the effect is relatively small for datasets of timescale ~20-30 years, but it could affect the uncertainties when fitting for long-timescale parameters like F2.

Tempo2 also did not quite correctly deal with the TNRedFLow parameter, that allows setting the lowest frequency (or equivalently the frequency spacing) for the Fourier-basis Gaussian process. Specifically, although it uses the correct frequencies, the conversion from PSD to power did not take into account the change in delta-frequency. This leads to a small error in the model power when TNRedFLow is used.

I don’t think these bugs will directly affect any GW experiment, but may lead to small errors in the parameter estimates (actually likely incorrect uncertainty estimates) if using tempo2 to do the least-squares fitting of parameters with a fixed input red noise model.

The offending line of code:

        double rho = pow((1+(pow((1.0/365.25)/RedCorner,RedIndex/2))),2)*(RedAmp*RedAmp/12.0/(M_PI*M_PI))/pow((1+(pow(freq/RedCorner,RedIndex/2))),2)/(maxtspan*24*60*60)*pow(f1yr,-3.0);

A fix is pending, but will put this bug report in case someone searches for it in the future.