gmsh2triangle renumbering is broken
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Fluidity |
Fix Released
|
Medium
|
Stephan Kramer |
Bug Description
The script gmsh2triangle tries to identify isolated nodes that are not attached to any elements (isolated nodes) and leaves these out of the output triangle files. This requires a renumbering of the nodes. However this renumbering is only applied to the .ele file but not .edge/.face file. Thus this renumbering only works correctly when the isolated nodes have node numbers that are bigger than any of the boundary nodes. Otherwise the node numbering of the surface mesh and the interior mesh no longer correspond leading to very onobvious errors in fluidity.
Question: what is the best way to fix?
Do we really want gmsh2triangle to be clever and take out isolated nodes? Would it not be better to maybe make it produce an warning/error to the user to tell them to fix their gmsh file? Are there cases where it's hard to do so (fix the gmsh file to prevent isolated nodes). In which case, since the default input for fluidity is now gmsh how do we deal with it when not using gmsh2triangle?
I'm tempted to get rid of the renumbering in gmsh2triangle all together. This also simplifies debugging in general. If asking the users to produce a gmsh mesh without isolated nodes is not feasible, then we should deal with it in some other way.
Related branches
- Cian Wilson: Approve
-
Diff: 87 lines (+10/-30)1 file modifiedtools/gmsh2triangle.py (+10/-30)
Changed in fluidity: | |
status: | New → In Progress |
Changed in fluidity: | |
status: | In Progress → Fix Committed |
Changed in fluidity: | |
status: | Fix Committed → Fix Released |
I agree that it's probably best to remove the renumbering but are there any test cases that depend on it so we can get an idea of why it's necessary? What fails if it is removed?