# [Gmsh] RE The direction of normal vectors on the surface elements

Christophe Geuzaine cgeuzaine at ulg.ac.be
Thu Jan 29 19:32:15 CET 2015

> On 29 Jan 2015, at 12:52, Theler German Guillermo <gtheler at cites-gss.com> wrote:
>
> Hello Chritophe, thanks for your kind response:
>
>
> On Wed, 2015-01-28 at 20:17 +0100, Christophe Geuzaine wrote:
>> > 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.
>>
>> In what sense? All the data you need is there...
>>
>
> 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
>
> Plane Surface(6) = {-5};
>
> I woukd like a mechanism for obtaining the normal pointing away from the bulk domain, not just following the face orientation.
>

The problem is that if this surface is now shared by two volumes, the orientation will be "wrong" for one of those volumes. So the only way is really to keep track of the orientation in the definition of the volume... which is what we do.

> 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.

Mathematically, your Neumann condition is expressed on a surface (and not on a surface element). The right level to define the condition is thus at the level of the geometrical entity (the physical group) ; not at the element (or even worse at the node) level. We leave it to the user to name the surface physical groups that are needed by the mathematical problem at hand.

>
> 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.
>
> 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.
>

Indeed, everything in Gmsh is 3D.

>
>
>> > 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.
>>
>> 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.
>>
>
>

Sure, why not. Some file format store such information (see e.g. GModelIO_CELUM, which keeps track of normals at vertices).

>>
>> > 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.
>>
>> You can also use the Python bindings if you're more familiar with that language.
>>
>
> Neither, but I can get along with it.
> Can you point out where in the source tree where the normals are computed?

There are different levels: normals to the CAD (geometry) can be obtained using GFace::normal() (Geo/GFace.h) ; normal to mesh elements can be computed trivially.

> What about face areas and element neighbors?

We construct these on-demand (see e.g. MElement::getJacobian()); never store them.

> Is the ANN library only used for the nearest-neighbor plugin or Gmsh uses it when computing the mesh?
>

It's used at several places in the code when we need to perform nearest neighbor calculations.

Christophe

>
> Thanks again!
>
> --
> Germán Theler :: CTO Eng & IT
>
> CITES – Centro de Innovación Tecnológica Empresarial y Social S.A.
> Dirección General Sancor Seguros
> Grupo Sancor Seguros
> tel +54 3493 –428 500 – Int.: 3374
> gtheler at cites-gss.com
> www.cites-gss.com - www.gruposancorseguros.com
>
>
>
>
>
> Imprima este mensaje sólo si es absolutamente necesario.
> Para imprimir, en lo posible utilice el papel de ambos lados.
> El Grupo Sancor Seguros se compromete con el cuidado del medioambiente.
>
>
>
> El Grupo Sancor Seguros comunica que:
>
> 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.
>
> 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.
>
> <normals.geo><normals.png>_______________________________________________
> gmsh mailing list
> gmsh at geuz.org
> http://www.geuz.org/mailman/listinfo/gmsh

--
Prof. Christophe Geuzaine
University of Liege, Electrical Engineering and Computer Science
http://www.montefiore.ulg.ac.be/~geuzaine