Allow children to have boundary conditions #3477
Conversation
grmnptr
force-pushed
the
grmnptr/boundary_on_child_elements
branch
6 times, most recently
from
5786158
to
bbd4274
Compare
grmnptr
force-pushed
the
grmnptr/boundary_on_child_elements
branch
7 times, most recently
from
dd7eeb7
to
ad40121
Compare
grmnptr
force-pushed
the
grmnptr/boundary_on_child_elements
branch
5 times, most recently
from
c57ecd1
to
309c9ec
Compare
grmnptr
changed the title
|
This is getting really close. We should probably turn on the distributed dbg checks right before we merge,rather than waiting for the devel->master merge, just to be safe. Modifying The one thing I'm still worried about there: we're not doing any communication after transferring BCs from children to parents, and strictly speaking we should be, because otherwise we might fall out of sync on newly coarsened ghost elements getting BCs transferred from newly deleted remote children. That alone wouldn't be a disaster for most apps, since we generally only query BCs on local elements ... but follow that up with a repartitioning (as we generally do after AMR/C) that turns an out-of-sync ghost element into a local element ... the element's original owner will send it to the new owner, but IIRC we generally ignore incoming communications of that sort (except to assert consistency in dbg mode) for data we already expect to have. |
|
Got it, thanks for the review! I'll push the changes later today. |
grmnptr
force-pushed
the
grmnptr/boundary_on_child_elements
branch
3 times, most recently
from
a7b5638
to
6f1ae70
Compare
There was a problem hiding this comment.
Only two remaining issues I could find. I wouldn't mind about a trillion more test cases, but this looks to be good enough as a starting point, assuming CI agrees with me later that those 4 lines are redundant. Pinging @jwpeterson in case he wants to take a look before we merge.
grmnptr
force-pushed
the
grmnptr/boundary_on_child_elements
branch
from
9124dcc
to
0b91772
Compare
Use case: moving boundary with AMR. Boundary needs to be defined on child elements
The motivaiton is that: "automatic" way might not work for cases. For example, if the flag is on on a subset of processor cores, and then we do reparitioning, and then we might hit trouble because the flag is off on the other processors I try to avoid having a global reduction to have everyone on the same page. In fact, we know when we want to allow children on boundary in MOOSE. In this case, we should set the flag to make the code more robust
…ing, if the child element has boundary info associated with itself
Co-authored-by: roystgnr <roy@stogners.org>
grmnptr
force-pushed
the
grmnptr/boundary_on_child_elements
branch
2 times, most recently
from
055d6e5
to
872b07e
Compare
grmnptr
force-pushed
the
grmnptr/boundary_on_child_elements
branch
from
872b07e
to
40a4dfc
Compare
grmnptr
force-pushed
the
grmnptr/boundary_on_child_elements
branch
from
36a1acf
to
daae23c
Compare
Otherwise we can get false positive errors; we don't want to disallow adding the same id twice, we only want to disallow (for now) adding ids redundantly between children and parents.
Taking over #3470 which took over #3094