Stephen,
Sorry for being dense; if you change (from latest SVN, you will have
to find the lines yourself in an older revision) lines 1616-1621 from:
(grid['x'] + 0.5 * grid['dx'] > self.left_edge[0])
to
(grid['x'] + 0.0 * grid['dx'] > self.left_edge[0])
(and so on, so that all of them are non-inclusive)
do you get identical *textual* results over your suite of tests?
Would it be possible to impose upon you to run this on 1, 2, 8, 16
processors, with some fixed padding, and then send the HopOutput.txt
from those four to the list? Plots would be added goodness, but not
necessary, since it seems there's a glitch. (You should feel free to
attach the plots to the emails, too. :)
Thanks!
-Matt
On Fri, Jan 23, 2009 at 2:10 PM, Stephen Skory
All,
I think I've figured out the particle deficits. In the parallel HOP routine, there is a total_mass calculation that adds up the mass of the particles on all the procs with padding=0.0 temporarily. If you run parallel HOP with padding 0.0, and add up the numbers of particles going to each proc, you'll get *more* than the actual number of particles. Quoting Matt: "This is a result of adding grid['dx'] onto the selection criteria for cells." So total_mass is being calculated with too many particles, which changes the density adjustments that need to go into each run of HOP.
Here's pictures and a more detailed explaination:
http://stephenskory.com/research/?p=1544
On the negative side, the periodic particles are still not being plotted. Which is odd since they appear to be included in the haloes with the total_mass fix.
So we need to make the total_mass calculation correct.
_______________________________________________________ sskory@physics.ucsd.edu o__ Stephen Skory http://physics.ucsd.edu/~sskory/ _.>/ _Graduate Student ________________________________(_)_\(_)_______________ _______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org