Conversation
We're going to need an extra find_neighbors() call after mesh redistribution to handle a corner case that unpacking neighbor information doesn't, so let's make that call as cheap as possible.
There's a corner case where a processor can receive 2 ancestor elements that are neighbors, but from source processors each of which only sees one of the two semilocally. This is necessary to fix that.
It's quite annoying to me to have to hunt down *why* a valid_is_prepared() call fails, which means it's got to be utterly intractable to too many users. So, instead of just asserting the final boolean results of an operator==, let's provide some way to get assertion failures that deliver more information about what wasn't equal.
This should give a more informative assertion failure message when needed.
When NDEBUG isn't defined, these should be no-ops, not unavailable, so we don't have to wrap them in ifdefs elsewhere.
We're trying to allow meshes to keep track of "half-prepared" status, for the sake of efficiency in large chains or webs of mesh generators, but at the very least user assembly kernels should be able to rely on a mesh being prepared for use - they're what we mean by "use"!.
This should be much better for debugging cases where the assert fails.
This is actually a big behavior change, considering it led to failed assertions in a half dozen of our own examples. Let's give users some time to get up to speed.
I haven't actually seen this fail yet but it does seem like the sort of thing we should be checking.
|
Everything worked on the first try, both in CI and on my workstation. That makes me suspicious; I'm turning on more recipes. |
|
Well, there's at least a performance concern. With the extra testing, |
|
No, not a performance concern after all. After scanning a zillion perf log reports trying to figure out why the new assertions might take so much longer than expected, I just kicked the CI recipe, which finished in 45 minutes this time. I suppose it's possible there's an intermittent hang that triggered in one example on that first run, but I've never seen anything like that in my own testing. We should be good to merge. |
2 participants
Now that we're happy with the updated libMesh submodule in MOOSE and we can get access there to the new fine-grained mesh preparation APIs, it's probably time to start (at least in
--disable-deprecatedbuilds) testing for preparation status.This is the last swath of libMesh-level work that came out of #3759