<html><head></head><body><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><pre>Thank you for your response. So, just to be sure we are on the same
page. Consider a 2D grid, it has vertices (points), faces (lines joining
points) and cells (polygons). Gmsh outputs the vertices, the cells and
the boundary faces only.
</pre></blockquote><div><br></div><div>Yes, this is correct. Strictly speaking, Gmsh treats all points, lines and polygons as "elements" and it only outputs those "elements" that belong to a physical entity. It does not "keep track" of the lines that separate two polygons that are located in the bulk of the domain.</div><div><br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><pre>My objective is now to generate the interior faces as well, and this is
the process which is slow for me. Is this the same process you are
referring to when you say it is an unresolved issue?
</pre></blockquote><div><br></div><div>More or less. I do not need to have information about actual "line elements" that separate two triangles (nor Gmsh does). For my FVM codes, what I need is a list of neighbors each cell has. For your 2D examples, I need to have for each triangle a list of three other elements. For bulk elements, this list will contain the id of three other triangles. For triangles in the border, I will have either 2 triangles and 1 line or 1 triangle and 2 lines. That's why at some point I suggested to add an optional section $Neighbors$ to the msh file:</div><div><br></div><div></div><div><a href="http://onelab.info/pipermail/gmsh/2014/008914.html">http://onelab.info/pipermail/gmsh/2014/008914.html</a></div><div><br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><pre>If yes, then thank you. You solved my question, since I see you
mentioning that you use a poorly designed algorithm to do this and I
think this is the best one can do straight from gmsh.
</pre></blockquote><div><br></div><div></div><pre>I agree the best way would be to compute this information from Gmsh. But this feature is not coded yet in Gmsh.</pre><pre>My approach is based on having a list of elements associated to each node and then trying to find common nodes between volumetric elements:</pre><pre><br></pre><pre><a href="https://bitbucket.org/seamplex/wasora/src/3dd04c3c1c236adae5799354114698112c46e232/src/mesh/neighbors.c?at=master&fileviewer=file-view-default">https://bitbucket.org/seamplex/wasora/src/3dd04c3c1c236adae5799354114698112c46e232/src/mesh/neighbors.c?at=master&fileviewer=file-view-default</a></pre><pre><br></pre><pre>--</pre><pre>jeremy theler</pre><pre><a href="http://www.seamplex.com">www.seamplex.com</a></pre><pre><br></pre><pre><br></pre></body></html>