Hanging nodes on TET4 elements

[doquang]

When performing mesh refinement on TET4 elements. Sometimes I see multiple hanging nodes one edge/face.
Is it normal? Do we have any options to force the mesh refinement to create only one hanging node on each edge/face?

[GiudGiud]

Hello

You have one element refined twice next to an unrefined element.
This is not supposed to happen. Is the mesh well stitched (no non-conformalities, no duplicate nodes)? Did you pass parameters to allow this?

Guillaume

[doquang]

Mesh created by netgen. So I assume that there are no non-conformalities and no duplicate nodes. The results look okay to me. Contour lines are continuous between those elements.

[GiudGiud]

@roystgnr do we support two levels of adaptivity difference across a side?
and

Do we have any options to force the mesh refinement to create only one hanging node on each edge/face?

[roystgnr]

Theoretically we support any number of levels of adaptivity difference across a side. In practice, though, I don't think we have any test coverage of it (because our standard MeshRefinement usage does a number of smoothing steps which include one that restricts mismatch to one level between neighbors), so I wouldn't trust it before adding some analytic or manufactured tests.

Note though that just because you see two levels of adaptivity difference across an edge doesn't mean there's more than one level of adaptivity difference across a face. In 3D it's quite common for refinement to create multiple hanging nodes on an edge, because you commonly have 4 (or 5, or with tets 6 or more) elements around that edge, and so the coarsest of them might have neighbors' neighbors with 2 more levels of refinement or neighbors' neighbors' neighbors with 3 more levels of refinement. We do have a decent amount of test coverage of these sorts of cases.

With a tet there's no way to create one hanging node on a face; one level of refinement between Tet4 gives you 3 hanging nodes on edges with 0 non-edge hanging nodes on the face interior; between Tet10 one level of refinement gives you 3 hanging nodes on coarse-face+fine-edges. To create meshes with no more than one level of mismatch on a face, you just use the default libMesh settings; you have to set MeshRefinement::face_level_mismatch_limit() = 0 to get unlimited levels of mismatch instead.

The default libMesh setting for edge mismatch is unlimited, though. MeshRefinement::edge_level_mismatch_limit() = 1 would be the option to use to change that.

I'm not seeing any MOOSE interface to either setting, but it wouldn't be hard to add one if we wanted.

[roystgnr]

Oh, man. Here's something that just clicked with me too late:

created by netgen

You mean the refinement pattern too, not just the coarse mesh?

If you're reading a tet mesh that's non-conforming from a file format that doesn't have an inheritance tree leading down to a conforming coarse mesh (i.e. pretty much any format except our own .xda/.xdr/.cda/.cdr), we do NOT support that. We will calculate INCORRECT RESULTS on that. I'll elaborate in another comment.

[roystgnr]

Generally mesh formats do not have any direct information about the element-to-element topology. You do not see any a priori specification that element A is a neighbor of element B. This is an issue for a finite element code, which needs to know e.g. whether solutions are supposed to be continuous between those elements or are allowed to go discontinuous between them.

What we have to do is reconstruct the element-to-element topology from the element-to-node topology. If we see that side 1 of A has the same nodes (up to a rotation/flip) as side 3 of B, then we conclude that neighbor 1 of A is B and neighbor 3 of B is A. All is well.

If we refine B, so now it has children B0, B1 ... B7, but we're using our own file formats so we still know that B exists and that it's the parent of those children, all is still well. This is a non-conforming mesh, but it comes from a conforming mesh that we can reconstruct the topology of. Since we still know that neighbor 3 of B is A, we can look at the 4 children on side 3 of B and we can determine which of those should also have A as a neighbor. When we're looking at each of those children later we can then see that it has a coarser neighbor on that side, so we know to calculate constraint equations for the "hanging node" DoFs on that side created by the refinement.

If we refine B, but we then discard it because we're using a file format that only stores B0 through B7, all is now broken. Literally, the connection between those elements is broken apart. As far as that mesh reader is concerned, you have defined a slit mesh, which is a perfectly valid sort of mesh to create, so we will happily construct it for you to compute on. We will then compute answers that will be correct for the slit mesh, and thus incorrect for the slit-free mesh you thought you were creating. The hanging nodes in between the refined elements and their coarse should-have-been-neighbor will be free to vary unconstrained by the coarse element nodes around them, and the resulting solution will be a disaster. If you're lucky it'll be an obvious disaster and you won't trust it; if you're unlucky the solution will look correct to the naked eye but will be like 10% off.

[doquang]

Oh, man. Here's something that just clicked with me too late:

created by netgen

You mean the refinement pattern too, not just the coarse mesh?

I used netgen to create the coarse mesh, exported it to MSH, and load it into moose. The rest (mesh refinement) is done by moose/libmesh.

[doquang]

@GiudGiud - Is there any news about MOOSE interface to use the libMesh options:

MeshRefinement::face_level_mismatch_limit() = 0
MeshRefinement::edge_level_mismatch_limit() = 1

[GiudGiud]

No we have not added those.

You could add a simple parameter to the Adaptivity action (AdaptivityAction.C) to set them. It would be 10 mins of work to set it up and 3 more minutes to recompile MOOSE