[Yt-dev] minimum halo mass

[Brian O'Shea]

>> I'm okay with just coming up with something and then setting that as
>> the default and then allowing users to override.  Why not use an
>> overdensity of 200 (or, even, density_threshold?) and multiply that by
>> 4/3 pi radius^3?  Am I misunderstanding?
>
> Yes, I think you're misunderstanding. A threshold in itself doesn't define any length scale.
>
> In a 1 Mpc cosmology run, the biggest halo is 1e10 Msol and has a radius of 0.09 in code units.
> In L7, which is 512 Mpc on a side, the biggest halo is about 1e15 Msol and has a radius of 0.01 in code units.
>
> This is pretty much the scope of currently practical enzo cosmology runs that anyone will be doing. Sure, people run enzo on smaller scales, but they don't use 512**3 particles, so parallel hop isn't as much of an issue.
>
> I mean, even something simple like this could work:
>
> padding = 0.1 / (side length in mpc)^1/3
>
> so
> 0.1/(1)^1/3 = 0.1
> 0.1/(512)^1/3 = 0.01
>
> I mean, seriously, something chickenshit simple like this will be fine in my opinion.

I disagree.  The halo mass function doesn't change linearly, and
people actually do sims with tons of particles at very small scale.  I
do, at least.  Anyway, I would propose doing the following:

1.  Given the cosmological parameters from the Enzo parameter file,
calculate the theoretical halo mass function using Press-Schechter or
the equivalent (the Warren et al. mass function is actually the best
one to use).
2.  Figure out what the largest halo is that has at least a 50%
probability of being inside the halo volume (in other words, what is
the largest halo mass where you get 0.5 halos/box?)
3.  Use the relationship between virial mass and virial radius to
calculate a radius, and then scale it into box units.
4.  Double that number and call that the padding.

This is straightforward to do, and will always produce reasonable
results for any cosmology simulation.  There are two caveats:

1.  One needs to assume a value of \sigma_8, since it's not actually
in the Enzo parameter file.  This isn't a big deal - it's somewhere
between 0.8 and 0.9 for pretty much any simulation.  For safety, I'd
suggest we just pick 0.9, since that gives an overall higher mass
function (and is thus the more conservative choice).

2.  This method of estimating padding only works for cosmology
simulations.  If one does non-cosmology particle simulations (which I
could see happening in the future, if Enzo is adopted more widely)
then people will have to specify their own padding.  We can always
cross that bridge when we get to it.

I have a press-schechter code that I am happy to donate to the cause.
It's written in C, though, so somebody's going to have to mess around
with it a bit.  I don't have time, sadly, so I'd have to ask for
somebody else to volunteer...

--Brian