TEMPO2 Gives Wrong DM Values for Single-Epoch Observations

[Joe Glaser]

Summarized in an email that went out to the NANOGrav group today, researchers at WVU over the summer noticed a bug in tempo2 which resulted in incorrect DM values for short timescale observations. This effects in all tempo2 versions sense commit b7fdb86 with the minor changes in commit 23c9642 being the culprit.

You can replicate this issue by downloading the included tar file and running the following in the uncompressed directory:
tempo2 -f 2145_58457-Copy1.par 2145_58457-Copy1.tim

This seems to be caused by including RN in a single-epoch fit for the DM measurements, which causes issues due to the change in the FINISH - START difference. Paul Demorest has been made aware of this issue, but I am creating this official posting to allow for others to post any similar cases where this occurs.

This DOES NOT seem to effect longer base-line, multi-epoch observations, thus the minor priority level.

~ Joe G.

[Michael Keith]

Thanks for this bug report. From what I understand, you are fitting for a gaussian process red noise model with data that spans about 10ns. I’m not actually sure what the expected behaviour is in this case. For what is essentially a single pulse, I think that it is likely to be unavoidable that there is a degeneracy between the DM and “timing noise”.

Digesting this a bit:

Assuming the template has dealt with any frequency-dependent shape variation, we know logically that the pulse left the pulsar at the same time at all frequencies, but I think that the mathematics does not know this. As far as the algorithm is concerned for a single pulse, the fact that the pulse is dispersed maps frequency directly to time, so there is no difference between residual changing smoothly with time and residual changing smoothly with frequency.

I think that it only makes sense to fit for the red noise if you have data tracking more than 1 pulse.

So… I’m not really sure that this is actually a bug in the sense that the behaviour seems consistent with the algorithm. Perhaps tempo2 does not interpret the “RN” parameters in the way intended? I think internally it directly translates them into the TNRed parameters, but perhaps something else is intended?

[Michael Keith]

N.B. Likely the issue is more apparent since 23c9642 because the Gaussian process uses a Fourier basis with the step in frequency = 1/(FINISH-START). Before 23c9642 FINISH-START had a minimum value of 172.8s (0.002 of a day), but afterwards this minimum was reduced to 2us. This change was required to allow START and FINISH to be defined precisely enough to select individual pulses. So - I think the same issue would appear in the older versions, but because the Fourier basis defaults to 100 components at 1/172.8 Hz, the shortest timescale in your red noise model was ~2s, so could only absorb a tiny fraction of the DM.

I think the solution is probably to remove the RN parameters from your par file if you want to fit for a single-epoch DM.