Dealii: Bug with dim = 1 codim = 2 gmsh reader

[drwells]

This came up on the mailing list (credit goes to Victoria W. for finding the bug!). It looks like we treat, in 1D, node material IDs as boundary IDs: this isn't going to work for a lot of gmsh files since (at least in this case) all nodes are given a material ID. The problem is easy to reproduce with step-34 when one switches to reading the following gmsh file:

$NOD
49
1 -6 -4 0
2 -6 -4 0
3 0 0 0
4 6 -4 0
5 -4 -4 0
6 -6 0 0
7 6 0 0
8 4 -4 0
9 4 -2 0
10 -4 -2 0
11 -4 -2.5 0
12 -4 -3 0
13 -4 -3.5 0
14 -4.5 -4 0
15 -5 -4 0
16 -5.5 -4 0
17 -6 -3 0
18 -6 -2 0
19 -6 -1 0
20 -5.25 0 0
21 -4.5 0 0
22 -3.75 0 0
23 -3 0 0
24 -2.25 0 0
25 -1.5 0 0
26 -0.75 0 0
27 0.75 0 0
28 1.5 0 0
29 2.25 0 0
30 3 0 0
31 3.75 0 0
32 4.5 0 0
33 5.25 0 0
34 6 -1 0
35 6 -2 0
36 6 -3 0
37 5.5 -4 0
38 5 -4 0
39 4.5 -4 0
40 4 -3.5 0
41 4 -3 0
42 4 -2.5 0
43 3 -2 0
44 2 -2 0
45 1 -2 0
46 0 -2 0
47 -1 -2 0
48 -2 -2 0
49 -3 -2 0
$ENDNOD
$ELM
58
1 15 0 1 1 1
2 15 0 2 1 2
3 15 0 3 1 3
4 15 0 4 1 4
5 15 0 6 1 5
6 15 0 7 1 6
7 15 0 8 1 7
8 15 0 9 1 8
9 15 0 10 1 9
10 15 0 11 1 10
11 1 0 1 2 10 11
12 1 0 1 2 11 12
13 1 0 1 2 12 13
14 1 0 1 2 13 5
15 1 0 2 2 5 14
16 1 0 2 2 14 15
17 1 0 2 2 15 16
18 1 0 2 2 16 1
19 1 0 3 2 1 17
20 1 0 3 2 17 18
21 1 0 3 2 18 19
22 1 0 3 2 19 6
23 1 0 4 2 6 20
24 1 0 4 2 20 21
25 1 0 4 2 21 22
26 1 0 4 2 22 23
27 1 0 4 2 23 24
28 1 0 4 2 24 25
29 1 0 4 2 25 26
30 1 0 4 2 26 3
31 1 0 5 2 3 27
32 1 0 5 2 27 28
33 1 0 5 2 28 29
34 1 0 5 2 29 30
35 1 0 5 2 30 31
36 1 0 5 2 31 32
37 1 0 5 2 32 33
38 1 0 5 2 33 7
39 1 0 6 2 7 34
40 1 0 6 2 34 35
41 1 0 6 2 35 36
42 1 0 6 2 36 4
43 1 0 7 2 4 37
44 1 0 7 2 37 38
45 1 0 7 2 38 39
46 1 0 7 2 39 8
47 1 0 8 2 8 40
48 1 0 8 2 40 41
49 1 0 8 2 41 42
50 1 0 8 2 42 9
51 1 0 9 2 9 43
52 1 0 9 2 43 44
53 1 0 9 2 44 45
54 1 0 9 2 45 46
55 1 0 9 2 46 47
56 1 0 9 2 47 48
57 1 0 9 2 48 49
58 1 0 9 2 49 10
$ENDELM

[bangerth]

Is there an easy testcase we could use with this file?

[drwells]

Yes. Here is a pared down version of step-34:

#include <deal.II/grid/tria.h>
#include <deal.II/grid/grid_in.h>

#include <fstream>

int main()
{
  using namespace dealii;
  constexpr int dim = 2;
  std::ifstream in("U_boundary_2D.msh");

  Triangulation<dim - 1, dim> tria;
  GridIn<dim - 1, dim> gi;
  gi.attach_triangulation(tria);
  gi.read_msh(in);
}

Edit: I pasted the wrong thing.

[bangerth]

Working on it!

[drwells]

This is what I like about GitHub: I can post an issue that I don't have time to work on and sometimes other people fix my problems for me :)

[bangerth]

I think I don't quite understand what gmsh is trying to tell us here. The lines in question are of the form

9 15 0 10 1 9

which has the format

elmnumber elmtype materialid ignored nnodes node_ids...

For elmtype==15, nnodes==1 and so node_ids has only a single entry.

The question is what the entry in the input file shown above is actually trying to tell us: That the vertex with index 9 has a particular boundary indicator "0"? But then gmsh shows this also for internal nodes, so it can't be a boundary indicator. Or a material_id? But it's a vertex, not a cell.

So I'm confused.

[bangerth]

I wished I could have actually fixed it. I'm confused :-(