As a followup, this script (run on Mike's dataset):
gives results of:
5.793e+14 5.793e+14 5.640e+14 2.956e-14 1.336e-02
While the accumulated roundoff error here is ~1% (which is something to be concerned about, and which I think we can start addressing by mandating dtypes in our calls to things like .sum()) it's still not the significant errors that are being reported.
I think quantities are okay. (Which is good, because the testing system should have caught any problems that would be introduced with parallelism, and it did not.) Additionally, I tested in HaloFinder in both parallel and serial, and on line 2240 I inserted a print statement indicating the received total volume. I got the correct answer in serial and in parallel. Is this the issue you were seeing?
Could you please provide a small, minimally viable sample script that can show the problem?
On Fri, Feb 24, 2012 at 7:32 PM, Matthew Turk email@example.com wrote:
On Fri, Feb 24, 2012 at 7:25 PM, Stephen Skory firstname.lastname@example.org wrote:
when I was trying to work on Mike's latest halo finder problem, I tried swapping out the total_mass sum for a .quantities on this line:
but doing that seriously changed the answers. Digging a bit deeper I see that for some reason, the same value is being fed in twice (I'm using two cores) to mpi_allreduce, which gives the wrong total_mass out. I see different values going into mpi_allreduce, and the correct total_mass, when I use the original summing method. This has led me to conclude that the .quantities is not being done correctly here - there's something wrong with the multi-level parallelism here I think... or something. Does anyone have any ideas of what could be going on? Thanks!
I'm not sure I understand -- is something wrong with quantities-in-general, or with the way it's being called in halo_objects? Can you investigate with a small dataset if the answer changes based on manually calculating versus using quantities in serial & parallel?
-- Stephen Skory email@example.com http://stephenskory.com/ 510.621.3687 (google voice)
yt-dev mailing list firstname.lastname@example.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org