Hi Nick,

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 <gnedin@fnal.gov> 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
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__ds.domain-5Fwidth.to&d=DwMFaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=7jSLZBQB_2gqGQ3elA922w&m=fmf18EFOt4Oc0B5-aA_e1fVsoWDaWKlZPazBYmvB2W8&s=uBgmmBk3375tZHOKlXSPQ3mxEKyxqLdN3B8Fx7GSpSw&e=>('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.