> On 29 Jan 2015, at 12:52, Theler German Guillermo <[email protected]> > 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. >> > > What about adding optional sections like $Normals$/$EndNormals$, > $Neighbors$/$EndNeighbors$? > 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 > [email protected] > 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. > > > ************AVISO DE CONFIDENCIALIDAD************ > > 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 > [email protected] > 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 _______________________________________________ gmsh mailing list [email protected] http://www.geuz.org/mailman/listinfo/gmsh
