Closed joshuahansel closed 1 month ago
@roystgnr What do you think should happen if you try to uniformly refine a mesh that has a NodeElem in it? I would want that element to not be refined of course 😄 If you don't have a good idea off the top of your head, I can dig. Looks like some nonsense ID like 18446744073709551615
shows up in this case.
I'd want the NodeElem
to have a single child NodeElem
, so we don't get any new DoFs but we do still have a uniform elem->level()
for all active elements, which would be especially valuable if the NodeElem
has an interior_parent()
and the user has a level mismatch rule active for that.
I might be persuaded that "just don't refine the NodeElem
" is a better solution, but obviously "crash" is not.
I notice that our zillion INSTANTIATE_ELEMTEST(PRISM20)
unit test creations don't include any INSTANTIATE_ELEMTEST(NODEELEM)
. In hindsight that was probably a mistake ... let me rectify that and see whether the refinement tests catch a bug here ... as well as how many other bugs we catch alongside it.
as well as how many other bugs we catch alongside it.
Fun fact: when you fail enough tests in CppUnit, the ".E.E.E.E.E.E.E.E.E.E.E.E..." looks like your computer is screaming in agony.
Well, that's not going to help. After I fix the unit test itself, there are still 4 failures left, none from test_refinement
or test_double_refinement
. We're going to need to boil down the actual failure into a test case.
Thanks for looking into it! I think it's not unlikely that this is due to my implementation in THM, and I can see where it might happen.
When I first add the NodeElem to the mesh, I save its ID, which then gets passed to my side user object (which loops over the boundaries of the pipes connected to the junction) as an input parameter. I need to use variable values from this element, so I do this:
const Elem * junction_elem = _mesh.elemPtr(_junction_elem_id);
_fe_problem.setCurrentSubdomainID(junction_elem, _tid);
_fe_problem.prepare(junction_elem, _tid);
_fe_problem.reinitElem(junction_elem, _tid);
and then get my variable values.
So now since the mesh has been refined, should I be reinitializing a different element? You mentioned that it should be creating a child element even though it's just a NodeElem, so maybe I just need to update to the child element ID?
Did you disable renumbering? If not then don't expect either ID to definitely remain the same through refinement. You could save the Elem *
(if you're on a ReplicatedMesh
) but then you'd need to update it to be the child of the original after refinement.
What type (FEType) of variable(s) do you have on the NodeElem?
We did disable renumbering in THM. As for replicated vs. distributed, we usually use replicated but should probably keep distributed working too. I'm using 1st-order Lagrange for that NodeElem.
should probably keep distributed working too
Make sure you're running test sweeps over MPI processor counts. There are so many corner cases you can get into with different partitionings that it's not uncommon for a new distributed-mesh bug to show up on e.g. 6 ranks despite working fine on 1 through 5.
I'm using 1st-order Lagrange for that NodeElem.
This makes things a tiny bit more robust - the DoFs will be stored on the Node
rather than on the Elem
as in a Monomial FE family, so if you accidentally evaluate something on the parent NodeElem rather than the child it'll still give you the right value.
Bug Description
In THM, NodeElems will be used for 0D junctions, but when you try to uniformly refine the mesh, you get an error. See below.
Steps to Reproduce
Run the test (with https://github.com/idaholab/moose/pull/28514)
which uses the CLI args
-r 1
to uniformly refine. This causes the following error:Impact
Inability to use mesh refinement feature in many THM simulations (and possibly other future MOOSE simulations if others start using NodeElem).
[Optional] Diagnostics
No response