Right, I see now. Setting the particle mass manually may be the best way to fix this. I believe most frontends store particle masses and yt just reads them in and hands them to rockstar, so it may be tricky to do this generally. I can also imagine scenarios where one might not want to renormalize the particle mass to include baryons, for example with baryon-poor mini-halos at high redshift. We could potentially allow the user to pass a custom particle mass field with altered masses to rockstar.
For the box size issue, just let us know when you have a fix. You can either issue a pull request or just post it here and I'd be happy to apply it.
On Tue, Jul 13, 2021 at 2:33 PM Nick Gnedin email@example.com wrote:
Thanks for the answer.
I would have said that the particle mass calculation looks correct as is. If the simulation has gas, then the particle mass should be calculated with omega_dm, right?
No, RS only uses DM particles, so without correcting the particle mass all halos end up 15% less massive.
For a loaded snapshot or timeseries object, ds, you can try doing: mass = ds.quan(5.02229e+06, 'Msun/h') and passing that with the particle_mass argument. That said, it would be useful to allow the user to specify a float and assume units of Msun/h. We can do that.
Thank you for the fix, that works.
It's not clear to me whether this is happening in the yt frontend or in the halo finder. If you load any of the snapshots and do: print (ds.domain_width.to <
('Mpc/h')) do you get the correct answer at every snapshot? That will help narrow down what needs fixing.
I planned to look into that and had it fixed, but did not get a chance yet. I believe all that needs to be fixed is for Yt to use abox for the scale factor, not auni (which is just a label for convenience and in the majority of cases has no physical meaning).
-- This email has been checked for viruses by AVG. https://www.avg.com