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 a good idea. I like this idea. It's straightforward and *easy to justify*.
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).
I agree.
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 do agree, and I think that specifying one's own padding is acceptable, it just should be a reasonable guess for cosmo runs, I felt.
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...
I'll take care of it; if you can send it my way, I'll take a look at it, and it can ferment my mind grapes for a little while and I'll hit it hard mid-April. Until then, I think everyone who needs parallel hop has already figured out the padding issue, so we should be set. I think this could be a useful set of code to include in any event! Thanks, Brian! -Matt