-
Notifications
You must be signed in to change notification settings - Fork 280
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
[BUGFIX] Fix particle selection for corner cases of morton index values #2575
Conversation
Thanks to Meagan Lang for debugging this with me. We discovered there was a corner case for filling subregions of mi1 and mi2, which showed up in yt-project#2574. This corrects that by choosing the region correctly.
I would like to get reviews on this (the tests should pass as I had originally pushed backwards logic for |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are a few minor issues (unused variable needs removed and upper range for the method filling coarse cells would need increased), but I also added a few suggestions which might improve performance.
Co-authored-by: Meagan Lang <cfh5058@gmail.com>
Co-authored-by: Meagan Lang <cfh5058@gmail.com>
Co-authored-by: Meagan Lang <cfh5058@gmail.com>
After merging this to 2577 tests still fail for me:
|
The failing test is |
OK, I've changed my mind, it is related to smoothing length, indirectly. Overriding the smoothing length in the io-handler causes this to work. I believe what is happening is that the periodic smoothing lengths are not being selected inside (This is precisely the kind of bug this test was supposed to ferret out, too!) |
The current commit reworks the smoothing length bitmap indexing at the coarse level for periodic boundary conditions. It will not be ready to go in until I've both addressed this in the refined level and tested this. At present for my test case, this fixes the problem, but it also throws errors for computing the bitmap indices, as it is now setting a few refined cells that are not on the coarse level. Until at a bare minimum that is addressed this cannot go in. |
OK, now that I've explicitly cast to |
One thing I would note is that I've snuck in an update to using bionic, as per @Xarthisius 's suggestion, on Travis. |
The travis answer test failure is itty bitty, and likely a result of a minor compiler change. I'd like to propose that review commence, and then I update the answer tests. |
PR for answers is here: yt-project/answer-store#4 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a couple of questions and one super minor nit. LGTM!
reg._set_refined_index_data_file( | ||
sub_mi1, sub_mi2, i, nsub_mi) | ||
nsub_mi, coll = reg._refined_index_data_file( | ||
coll, pos, hsml, mask, sub_mi1, sub_mi2, i, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you use None
on l182 here like you did at 218? Or am I missing something subtle that coll needs to be defined here on l179 but not there?
@@ -1,5 +1,5 @@ | |||
language: python | |||
dist: xenial | |||
dist: bionic |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I must have missed the reason for switching dists in travis. What was that for?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ups, this slipped through and caused a regression: older GCC (<6) need explicit C++11 flags in the build system, otherwise they will fail to build: #2892
It's not clear to me why this is not set though, because setup.py
sets extra_compile_args=["-std=c++11"])
... 🤔 Does it need to be added to further Extension
s that include the same header?
@@ -3,6 +3,6 @@ available at: | |||
|
|||
https://github.com/lemire/EWAHBoolArray | |||
|
|||
Currently this is at revision 80881379f8a582f45dda1be9edfc84d244846427. | |||
Currently this is at revision 88b25a3345b82353ccd97a7de6064e6c179a7cc2 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ahhh I see this got updated
More details about the test failure can be found at the URL: http://use.yt/upload/84bbfca3 answer(s) for failed test at URL: http://use.yt/upload/bc305b8c
Thanks to @langmm for debugging this with me and for identifying the precise problem. We discovered there was a corner case for filling subregions of mi1 and mi2, which showed up in #2574. This corrects that by choosing the region correctly.
This is a bug identified by some work I'm doing that will add comprehensive testing to particle
selection.
This fixes #2574.