![](https://secure.gravatar.com/avatar/1530ae8f95d9f5dd944f8cf9caeaef98.jpg?s=120&d=mm&r=g)
It appears that Yt does not run Rockstar correctly. Here are 2 issues we discovered so far: 1. DM particle mass and hence halo masses are incorrect in a simulation with baryons. Here are lines from one of out_*.list for a simulation with 1024^3 particles in a 40 cMpc/h box: #Om = 0.303600; Ol = 0.696400; h = 0.681400 #Particle mass: 4.22991e+06 Msun/h The particle mass should be 2.77536623e11*0.3036/0.6814*40**3/1024**3 = 7370552 Msun Instead, the reported value is 4.22991e+06 Msun/h = 6207675 Msun, which is exactly 2.77536623e11*0.2557/0.6814*40**3/1024**3 and 0.2557 = Omega_{DM}, not Omega_M. The same incorrect value is reported independently of what I set for the dm_only argument to RockstarHaloFinder. In a DMO simulation with identical initial conditions the particle mass is reported correctly: #Particle mass: 5.02229e+06 Msun/h This is for the snapshot read by the artio frontend. 2. I tried to circumvent the previous bug by setting particle_mass=5.02229e+06 in the call to RockstarHaloFinder, but that dies with the following error: p['particle_mass'].convert_to_units("Msun / h") P002 yt : [ERROR ] 2021-06-01 19:17:19,937 AttributeError: 'float' object has no attribute 'convert_to_units' It appears that the argument of particle_mass keyword must be some class rather than a number as listed in the documentation. 3. When running on a simulation with a non-zero DC mode Yt sets the box size incorrectly:
fgrep '#Box size' out_* out_0.list:#Box size: 40.216236 Mpc/h out_1.list:#Box size: 40.216236 Mpc/h ... out_14.list:#Box size: 40.216236 Mpc/h
It appears that Yt uses the value Lbox*abox/auni for the first snapshot, and never recomputes it for the following snapshots. That corrupts halo positions, and, what is even worse, applies periodic wrapping incorrectly, so halos near the box boundaries are messed up. Nick Gnedin -- This email has been checked for viruses by AVG. https://www.avg.com