#1696 GmshReader inserting boundary segment in the wrong order?
Metadata
| Property | Value |
|---|---|
| Reported by | Jö Fahlke (jorrit@jorrit.de) |
| Reported at | Jul 11, 2015 21:04 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |
| Operating System | Unspecified / All |
| Last edited by | Jö Fahlke (jorrit@jorrit.de) |
| Last edited at | Jul 19, 2015 11:15 |
| Closed by | Jö Fahlke (jorrit@jorrit.de) |
| Closed at | Jul 19, 2015 11:15 |
| Closed in version | Unknown |
| Resolution | Not a bug |
| Comment |
Description
Sophie Schrader, a student here in Münster is trying to read in boundary physical entities from a gmsh file in order to determine where on the boundary Dirichlet boundary conditions should be applied. She had two .msh files: rec_fine.msh, which worked fine apparently, and rec_coarse.msh, a coarser version of rec_fine.msh used for debugging, which marked unexcected parts of the boundary as Dirichlet.
There is one complication: She was using UGGrid<2>, which does not support factory.insertionIndex(intersection). But UGGrid has intersection.boundarySegmentIndex(), so she was using that. In fact, when I asked Oliver about it, he told me that intersection.boundarySegmentIndex() does exactly what factory.insertionIndex(intersection) is supposed to do, so that should be OK.
I build a test program that reads in an .msh-file, iterates over all leaf boundary indersections, and for each one prints center position, orientation (normal), boundarySegmentIndex and physical entity number. This shows that the boundary segment index seems to be somehow permuted. Here is the output, sorted according to the index, and the same physical entity numbers grouped together:
| c0 | c1 | o0 | o1 | index | pe | | | | | | | | |-----+-----+----+----+-------+----| | 0.5 | 0 | 0 | -1 | 0 | 15 | |-----+-----+----+----+-------+----| | 0 | 0.5 | -1 | 0 | 1 | 16 | | 1 | 0.5 | 1 | 0 | 2 | 16 | | 1 | 1.5 | 1 | 0 | 3 | 16 | |-----+-----+----+----+-------+----| | 1 | 2.5 | 1 | 0 | 4 | 17 | |-----+-----+----+----+-------+----| | 0.5 | 3 | 0 | 1 | 5 | 18 | | 0 | 2.5 | -1 | 0 | 6 | 18 | | 0 | 1.5 | -1 | 0 | 7 | 18 |
This order should be the same as the one the boundary segments appear in rec_coarse.msh, but it isn't.
This also happens with rec_fine.msh, but it is not so obvious, because it always exactly one intersection per side the is classified wrongly.
Now why do I think this is a problem with the GmshReader, and not UG?
I tried to futher simplify the test case, namely to eliminate the GmshReader, and to translate rec_coarse.msh into direct calls on the gridfactory. I did note that the GmshReader reorders the vertices, inserting them only when needed, so I did the same reordering. But if I use the resulting grid to produce the same table as above, the problem goes away:
| c0 | c1 | o0 | o1 | index | pe | | | | | | | | |-----+-----+----+----+-------+----| | 0.5 | 0 | 0 | -1 | 0 | 15 | |-----+-----+----+----+-------+----| | 1 | 0.5 | 1 | 0 | 1 | 16 | | 1 | 1.5 | 1 | 0 | 2 | 16 | | 1 | 2.5 | 1 | 0 | 3 | 16 | |-----+-----+----+----+-------+----| | 0.5 | 3 | 0 | 1 | 4 | 17 | |-----+-----+----+----+-------+----| | 0 | 2.5 | -1 | 0 | 5 | 18 | | 0 | 1.5 | -1 | 0 | 6 | 18 | | 0 | 0.5 | -1 | 0 | 7 | 18 |
It is interesting to compare the indices in the gmsh and the factory case side-by-side
| iter | c0 | c1 | o0 | o1 | factory | gmsh | | | | | | | index | index | |------+-----+-----+----+----+---------+-------| | 2 | 0.5 | 0 | 0 | -1 | 0 | 0 | | 7 | 1 | 0.5 | 1 | 0 | 1 | 2 | | 3 | 1 | 1.5 | 1 | 0 | 2 | 3 | | 0 | 1 | 2.5 | 1 | 0 | 3 | 4 | | 4 | 0.5 | 3 | 0 | 1 | 4 | 5 | | 6 | 0 | 2.5 | -1 | 0 | 5 | 6 | | 5 | 0 | 1.5 | -1 | 0 | 6 | 7 | | 1 | 0 | 0.5 | -1 | 0 | 7 | 1 |
Index zero is unchanged, all other indices are shifted by one, with the last index wrapping around.
I guess I'll have to take a close look at the GmshReader, but I'm fed up for today and want to record what I found out so far.