More contains_vertex_of optimization #2957
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Added a couple distributed CI sweeps; if those pass this should be good to merge. |
|
|
|
It's not from this PR. Same failure with master. |
|
Thanks for working on this. For uniform refinement, we often do not need original coarse meshes. In other words, parents can be deleted after children's creations. I think this can reduce the cost of finding neighbors. We might consider that as a valuable option when a general solution is impossible. |
We have to default this to false to avoid breaking users who are testing intersections between elements of different meshes (or of different overlapping manifolds on the same Mesh), but when *we* use this function we can generally take advantage of the fact that both elements are coming from the same Mesh with a conforming coarse mesh.
roystgnr
force-pushed
the
contains_vertex_connected
branch
from
2e51452
to
a86b205
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I came up with this in a conversation with @jbadger95 a week ago, when he was asking about
contains_edge_of. Sadly I haven't yet actually improved the case he cared about (and probably won't soon; yes I'm still on vacation), but the question of "how much would this improve our point neighbor ghosting" kept nagging at me.Turns out the answer is: our
LIBMESH_BENCHMARKwith--enable-parmeshgets 5% faster, and 3D refinement-heavy cases (like the uniform refinement tests @fdkong pointed me to) can get over 50% faster; all this is on top of the previous optimization in #2942, so that's something like a 5x speedup overall for distributed 3D mesh refinement. I cannot fully express my embarrassment that we had performance that horrible in a common use case. (We actually still have bad performance here, sincedelete_remote_elements()is half the cost of the solve in my test case, but it's no longer a dozen times the cost, so yay?)