search

cosmodesi / pyrecon

package for BAO reconstruction
BSD 3-Clause "New" or "Revised" License
9 stars 7 forks source link

maintaining dtype consistency in reconstruction #7

Closed seshnadathur closed 2 years ago

seshnadathur commented 2 years ago

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 provided dtype='f4' as kwarg when initialising the mesh. However, when using IterativeFFTParticleReconstruction, the output shifted positions I obtain have dtype='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 and MultiGridReconstruction 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 the utils.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.

seshnadathur commented 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 ;))

adematti commented 2 years ago

Thanks Sesh for the report, I'm on it.

adematti commented 2 years ago

Commit 4664f33889f789f1ededd7447ba750db4817e7d4 should solve the issue

adematti commented 2 years ago

@seshnadathur May I close this issue?

seshnadathur commented 2 years ago

Yes!