Closed seshnadathur closed 2 years ago
(I also know I promised to submit PRs instead of just always raising issues, and I will get around to it I promise ;))
Thanks Sesh for the report, I'm on it.
Commit 4664f33889f789f1ededd7447ba750db4817e7d4 should solve the issue
@seshnadathur May I close this issue?
Yes!
I have found some strange behaviour regarding the
dtype
. I'm running on input files which have single precision data only (as for some DESI mocks), and so I have provideddtype='f4'
as kwarg when initialising the mesh. However, when usingIterativeFFTParticleReconstruction
, the output shifted positions I obtain havedtype='f8'
. Apart from spuriously suggesting precision that doesn't exist, this is annoying because it increases the output file size.I checked that the mesh itself is f4 as expected, but the reconstructed positions are not.
I checked the performance of
IterativeFFTReconstruction
andMultiGridReconstruction
too: here the reconstructed Cartesian positions ('POSITIONS_REC') are f4 as they should be, but the output redshift is again in f8.My guess is therefore that the input dtype is not respected in two separate places: in the
read_shifts
method in iterative_fft_particle.py, and in theutils.DistanceToRedshift
method (or possibly in the call to astropy to get comoving distances). I haven't had time to check this in any further detail yet though.