<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="GENERATOR" content="GtkHTML/4.8.5">
</head>
<body>
Hello Chritophe, thanks for your kind response:<br>
<table cellspacing="0" cellpadding="0" width="100%">
<tbody>
<tr>
<td><br>
<br>
</td>
</tr>
</tbody>
</table>
On Wed, 2015-01-28 at 20:17 +0100, Christophe Geuzaine wrote:
<blockquote type="CITE">
<pre>
<font color="#737373">> This is nice, but it does not solve the issue of getting the outward normal in the sense needed to set neumann or robin boundary conditions. </font>
In what sense? All the data you need is there...
</pre>
</blockquote>
<br>
In the sense that I will try to explain in the attached geometry. Gmsh reports that the square at the bottom has normals that are not outward. It gets even worse if line 16 is replaced by<br>
<br>
Plane Surface(6) = {-5};<br>
<br>
I woukd like a mechanism for obtaining the normal pointing away from the bulk domain, not just following the face orientation.<br>
<br>
Moreover, the attached geometry files is composed of two blocks which correspond to different physical groups (say they are made of different materials). In the case that the boundary condition involves a bulk property (say the thermal conductivity in a neumann-type
bondary condition for the heat conduction equation) there is no way to directly link the surface elements in physical entities 101 and to the the corresponding attached volume element, which is the one that belongs to either physical entity 204 or 205 that
refers to the actual material. <br>
<br>
Not only a mechanism for writing directly the list of first-neighbors for each element may solve the link between surface and volume elements for setting BCs, but also would ease the implementation of solvers based on finite-volumes spatial discretizations.<br>
<br>
BTW, for 2D problems (say a square confined to the x-y plane) Gmsh does not compute (or at least does not show) the normals of the line elements where boundary conditions are to be applied, so this computation has to be done from the solver side.<br>
<br>
<br>
<br>
<blockquote type="CITE">
<pre>
<font color="#737373">> BTW, I think that there is some valuable information about the meshed geometry that should be optionally included in the resulting mesh file. For example, I do not see the point of having to compute the outward normals (or the face areas or the element's neighbors) from the solver side. Moreover, with the information Gmsh has in its administrative structures it should be far more efficient to compute the geometric properties at the time of the mesh generation, let alone if the same mesh has to be used several times in different runs.</font>
The best is probably for you to design a file format that contains all the info you need. Have a look at all the Geo/GModelIO_*.cpp routines to get some examples.
</pre>
</blockquote>
<br>
What about adding optional sections like $Normals$/$EndNormals$, $Neighbors$/$EndNeighbors$?<br>
<br>
<blockquote type="CITE">
<pre>
<font color="#737373">> I tried to follow step-by-step the mesh() method but I am not so fond to C++ so I could not completely understand what is going on behind, but maybe someone here may be able to tell.</font>
You can also use the Python bindings if you're more familiar with that language.
</pre>
</blockquote>
<br>
Neither, but I can get along with it. <br>
Can you point out where in the source tree where the normals are computed?<br>
What about face areas and element neighbors? Is the ANN library only used for the nearest-neighbor plugin or Gmsh uses it when computing the mesh?<br>
<br>
<br>
Thanks again!<br>
<br>
<table cellspacing="0" cellpadding="0" width="100%">
<tbody>
<tr>
<td>-- <br>
<b>Germán Theler :: </b><i>CTO Eng & IT</i><br>
<br>
<b>CITES</b> – Centro de Innovación Tecnológica Empresarial y Social S.A.<br>
Dirección General Sancor Seguros<br>
Grupo Sancor Seguros<br>
tel +54 3493 –428 500 – Int.:<i> 3374</i><br>
<a href="mailto:ccipolatti@cites-gss.com">gtheler@cites-gss.com</a><br>
<u><a href="http://www.cites-gss.com">www.cites-gss.com</a></u> - <a href="http://www.gruposancorseguros.com">
www.gruposancorseguros.com</a><br>
<br>
<br>
<br>
<br>
</td>
</tr>
</tbody>
</table>
<br>
<hr>
<font color="#336600" size="2">Imprima este mensaje <strong>sólo si es absolutamente necesario</strong>.<br>
Para imprimir, en lo posible utilice el papel de ambos lados.<br>
El Grupo Sancor Seguros se compromete con el cuidado del medioambiente.</font><br>
<br>
<br>
<p style="font-size:8pt; color:gray; font-family:'Arial','Calibri','Cambria','garamond','serif';">
************AVISO DE CONFIDENCIALIDAD************<br>
<br>
El Grupo Sancor Seguros comunica que:<br>
<br>
Este mensaje y todos los archivos adjuntos a el son para uso exclusivo del destinatario y pueden contener información confidencial o propietaria, cuya divulgación es sancionada por ley. Si usted recibió este mensaje erróneamente, por favor notifíquenos respondiendo
al remitente, borre el mensaje original y destruya las copias (impresas o grabadas en cualquier medio magnético) que pueda haber realizado del mismo. Todas las opiniones contenidas en este mail son propias del autor del mensaje. La publicación, uso, copia
o impresión total o parcial de este mensaje o documentos adjuntos queda prohibida.<br>
<br>
Disposición DNDP 10-2008. El titular de los datos personales tiene la facultad de ejercer el derecho de acceso a los mismos en forma gratuita a intervalos no inferiores a seis meses, salvo que acredite un interés legítimo al efecto conforme lo establecido en
el artículo 14, inciso 3 de la Ley 25.326. La DIRECCIÓN NACIONAL DE PROTECCIÓN DE DATOS PERSONALES, Organo de Control de la Ley 25.326, tiene la atribución de atender las denuncias y reclamos que se interpongan con relación al incumplimiento de las normas
sobre la protección de datos personales. </p>
</body>
</html>