gwastro
Fix problem on pycbc live due to numpy 2
This fixes #4912.
I explictly convert the PSD to double precision before the division, as soon numpy 2.x is not doing it automatically anymore.
I also add another check of the XML files to make sure that the PSDs in there are valid.
Let me maybe propose a somewhat more difficult solution: Is there any reason for us to still use float32 precision in filtering/PSD estimation etc. as default? Can we just move all of this to float64? (Perhaps the potential to use GPUs might motivate keeping this)
Let me maybe propose a somewhat more difficult solution: Is there any reason for us to still use float32 precision in filtering/PSD estimation etc. as default? Can we just move all of this to float64? (Perhaps the potential to use GPUs might motivate keeping this)
To first order, I would expect that to roughly halve performance. Maybe more, if you move from the matched filtering inputs and outputs fitting in cache to no longer doing so. It's probably harmless to compute the PSD in double precision and then convert it to float (though you'd still have to include the dynamic range factor).
One potential concern if we move everything to double would be memory usage. PyCBC Live already uses quite a bit of RAM, which would presumably double if we did this. Using double just for the PSD would not be a problem of course, but then again, what do we gain?
Given that this is currently blocking a new release for PyCBC Live, I would strongly prefer that we use the fastest fix available. We can revisit larger changes like moving everything to float64 on a longer timescale.
@maxtrevor this only blocks PyCBC Live releases if you decide to run it under Numpy 2.
@maxtrevor this only blocks PyCBC Live releases if you decide to run it under Numpy 2.
Ah right. At this point we have to actively choose not to use numpy 2 when making an environment, so I'd still prefer to get this in but you're right its not necessarily a blocker.
@spxiwh The psd calculation itself is actually not problematic. It can be done in either float32 or float64 already just by choice of input (e.g. whatever the precision of the data is). The issue is just that float32 only can have exponents within 10^(+- ~38).
