New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FOF gives unstable results at lower number of ranks #409

merged 3 commits into from Oct 3, 2017


None yet
1 participant

rainwoodman commented Sep 27, 2017

FOF used to give unstable results when the boxsize is close to the size of domain and there are particles outside of the box.

I do not have an isolated test case but this seems to be related to the failure of a test case in fastpm-python.
The labels of a halo found from 4 ranks is broken into several when running with 1 rank.
However, run with 1 rank without periodic boundary these particles become 1 halo.
After adding the wrapping into the boundary these particles become 1 halo on a single rank as well.

@rainwoodman rainwoodman force-pushed the rainwoodman:fof-tests branch from 5dccc63 to 4dce497 Sep 27, 2017

rainwoodman added a commit to rainwoodman/fastpm-python that referenced this pull request Sep 27, 2017

update nbkit interface to latest nbodykit (0.2.7+)
The correctness of tests depends on bccp/nbodykit#409

It is a small effect but doesn't hurt to get it exactly correct.

@nickhand nickhand referenced this pull request Sep 28, 2017


Travis Error no 3pt code #410

rainwoodman added some commits Sep 27, 2017

Add stricter tests for FOF.
I noticed the output of FastPM fof catalog shows some variation
going from 1 to 4 ranks. The difference is concentrated near the
edges or domains, and it can affect even relatively large halos
to some extent. (though I was looking at a 5 step simulation.)

I still do not know what is causing the difference.

I checked that the position of particles are 1e-6 identical.

These FOF tests asserts the behavior of the parallel merging is
correct with simple cases that goes cross the domain boundary.
wrap the position into the box before calling FOF
kdcount silently produces strange results when the poistions are not
wrapped. I think it is because the distance computation assumed
points are within the boxsize.

@rainwoodman rainwoodman force-pushed the rainwoodman:fof-tests branch from 2f8c738 to 6ccf25b Sep 30, 2017

@rainwoodman rainwoodman merged commit 78647ed into bccp:master Oct 3, 2017

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
coverage/coveralls Coverage decreased (-0.009%) to 95.129%

@rainwoodman rainwoodman deleted the rainwoodman:fof-tests branch Oct 3, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment