Open mattpitkin opened 6 months ago
Note that for some platforms (most notably Apple Silicon a.k.a. arm64) float128 it's either unavailable or defaults to a regular double. So on some platforms the change may break the code, or not fix the problem. On those platforms, tempo2 will also operate with double precision internally.
So I'm not sure what the way forward is. Is it a problem if this code breaks on arm64? It would signal that simulation is not doing what one thinks it is, but should we ship broken code? Will it even CI?
I've made a slight change to workaround np.float128
not being present on ARM64 systems.
Attention: Patch coverage is 33.33333%
with 4 lines
in your changes are missing coverage. Please review.
Project coverage is 37.30%. Comparing base (
d91baf2
) to head (d4afb9d
).
In the
tm_delay
function, the parameters to be varied are set asnp.double
precision values. The original values in thet2pulsar
object (in particular the frequency parameters) are stored asnp.float128
, so the recasting asdouble
's loses some precision. This isn't generally problematic, but it can be problematic if you are doing simulations with very low noise and truncation of, e.g., the frequency, caused by converting todouble
's throws off other parameters.I will show a concrete example. I generate some fake TOAs for J2145-0750 using the Tempo2
fake
plugin, with the very low noise of 0.1ns:where the
.par
file contained:Now, if I assume that
F2
is actually unknown and I want to estimate its value from the TOAs, I could set up a.par
, called, say,J2145-0750_no_f2.par
file containing:and run (the below assumes https://github.com/nanograv/enterprise_extensions/pull/226 has been applied to allow it to run with
white_vary=False
):it gives:
where the
F2
value is completely wrong (note that a fit with Tempo2 itself gets the correct value).From digging into why this is happening, I find that when the
F0
value gets converted fromfloat128
todouble
in timing.py, it gets truncated from:to
With the very low noise, this difference in frequency is enough to throw off the estimation of
F2
. If I apply the patch in this PR and run the above code again, I get:which has the correct
F2
value.