lower_dimensional_block gives _mesh.isLowerD = true in Moose

[jmeier]

Dear Community,

I hope I'm right here with this...

Please consider the simple mesh shown below from an gmsh MSH file. It consists of 1x6 TET10 and 2x1 EDGE3 elements in 3 blocks:

When I import this mesh into Moose using FileMesh and show_info=true I get as expected (shortend)

FileMeshGenerator 'file':  Mesh Subdomains:
FileMeshGenerator 'file':   Subdomain 1 (lineBeamB): 1 elems (EDGE3, 1 active), 3 active nodes
FileMeshGenerator 'file':   Subdomain 2 (lineBeamA): 1 elems (EDGE3, 1 active), 3 active nodes
FileMeshGenerator 'file':   Subdomain 3 (Base): 6 elems (TET10, 6 active), 27 active nodes

But to my surprise, _mesh.isLowerD(*it) (e.g. as in MooseVariableBase.C) gives:

  'lineBeamB' higher dimensional block
  'lineBeamA' higher dimensional block
  'Base' higher dimensional block

Why lineBeamA and lineBeamB are marked as "higher dimensional" despite the fact they are marked "lower_dimensional_block" in the MSH file? Apart from this, the import and model seems fine. Please find the complete MSH file below.

Disclaimer: I got another but bigger MSH file, where _mesh.isLowerD(*it) marks some of the blocks having only Beam-Elements as "lower dimensional block" and some "higher dimensional block". This in turn produces new problems downstream e.g. as (not yet fully discussed) in idaholab/moose#28204. But I hope resolving my question for the simple model will also shed some light here.

MSH-File

$MeshFormat
4.1 0 8
$EndMeshFormat
$PhysicalNames
13
1 1 "lineBeamB" lower_dimensional_block
1 2 "lineBeamA" lower_dimensional_block
3 3 "Base"
2 4 "Base_YMin_0"
2 5 "Base_XMin_0"
2 6 "Base_XMax_0"
2 7 "Base_YMax_0"
2 8 "Base_ZMin_0"
2 9 "BoundaryXMin"
2 10 "BoundaryXMax"
2 11 "BoundaryYMin"
2 12 "BoundaryYMax"
2 13 "BoundaryZMin"
$EndPhysicalNames
$Entities
0 2 10 1
1 -14 0 2.999998 -14 0 7 1 1 0
2 -14 -10 2.999998 0 0 2.999998 1 2 0
1 -14 -10 0 0 -10 2.999998 1 4 0
2 -14 -10 0 -14 0 2.999998 1 5 0
3 0 -10 0 0 0 2.999998 1 6 0
4 -14 0 0 0 0 2.999998 1 7 0
5 -14 -10 0 0 0 0 1 8 0
6 -14 -10 0 -14 0 2.999998 1 9 0
7 0 -10 0 0 0 2.999998 1 10 0
8 -14 -10 0 0 -10 2.999998 1 11 0
9 -14 0 0 0 0 2.999998 1 12 0
10 -14 -10 0 0 0 0 1 13 0
1 -14 -10 0 0 0 2.999998 1 3 0
$EndEntities
$Nodes
1 29 1 29
3 1 0 29
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
-14 0 2.999998
-14 0 0
0 0 2.999998
0 0 0
0 -10 2.999998
-14 -10 2.999998
0 -10 0
-14 -10 0
-14 0 7
-14 0 1.499999
-7 0 2.999998
0 0 1.499999
-7 0 0
-6.99999999999998 -5.00000000000001 2.999998
-7 -10 2.999998
-14 -5 2.999998
0 -5 2.999998
0 -5 0
0 -10 1.499999
-14 -5 0
-7 -10 0
-14 -10 1.499999
-14 0 4.999999
-7 0 1.499999
0 -5 1.499999
-7 -5 0
-14 -5 1.499999
-7 -10 1.499999
-7 -5 1.499999
$EndNodes
$Elements
13 28 1 28
1 1 8 1
1 1 9 23
1 2 8 1
2 1 5 14
3 1 11 6
3 4 3 1 7 12 11 24 18 29 25
4 1 8 7 6 27 21 29 16 28 22
5 3 5 1 7 17 14 11 25 29 19
6 1 8 2 7 27 20 10 29 26 21
7 5 6 1 7 15 16 14 19 29 28
8 1 2 4 7 10 13 24 29 18 26
2 1 9 2
9 5 6 7 15 28 19
10 6 8 7 22 21 28
2 2 9 2
11 1 2 8 10 20 27
12 1 8 6 27 22 16
2 3 9 2
13 7 4 3 18 12 25
14 7 3 5 25 17 19
2 4 9 2
15 2 1 4 10 24 13
16 4 1 3 24 11 12
2 5 9 2
17 4 7 2 18 26 13
18 7 8 2 21 20 26
2 6 9 2
19 1 8 6 27 22 16
20 8 1 2 27 10 20
2 7 9 2
21 4 3 7 12 25 18
22 3 5 7 17 19 25
2 8 9 2
23 6 8 7 22 21 28
24 5 6 7 15 28 19
2 9 9 2
25 3 4 1 12 24 11
26 2 1 4 10 24 13
2 10 9 2
27 7 8 2 21 20 26
28 7 2 4 26 13 18
$EndElements

[roystgnr]

I hope I'm right here with this...

You're in the wrong place: isLowerD() isn't a libMesh method ... and it doesn't look like it's a shim of a libMesh method either, it's querying an internal MooseMesh data structure. So you might have better luck asking there.

But let me try to help anyway: looking into MooseMesh::cacheInfo(), where the data structure is being set, it looks like isLowerD() isn't returning what the name says ("is this lower-dimensional than the rest of the mesh"), it's trying to return what the Doxygen comment says ("do elements in this subdomain have interior_parent() values assigned"). By that definition, it can absolutely be correct for some blocks of beams to return true (because they're boundary elements of 2D or 3D elements) while others return false (because they're free-standing beams).

If you just want to know the dimension of an element, query elem->dim().

If you want GMSH files to assign interior_parent() links everywhere it can, though ... that's not an reasonable feature request, we just don't have anything of the sort right now. We read their tets as tets and their edges as edges but we don't do anything to auto-connect the latter to the former (e.g. the way we connect neighbor_ptr() links) automatically.

[jmeier]

Dear @roystgnr,

Thank you very much for the detailed explanation. It gives valued puzzle fagments for my problem discussed in idaholab/moose#28204. This clearly closes the discussion.