[Gmsh] surface normal orientation - geo vs. mesh

[Christophe Geuzaine]

Philip Kelleners wrote:
> Dear Christophe,
> 
>   first my compliments, for producing such quality software and for releasing
> the sources under GPL. It compiles nicely under Irix 6.5 using the native mips
> compiler and even runs at decent speed on an older SGI-O2.
> 
>   I may have hit upon a bug, if not, I don't understand the result. The
> following lines are part of a bigger .geo file but mesh by themselves.
> 
> 
> 
> ***** begin  normal-ori.geo *****
> 
> // In gmsh 1.60.1;
> // the surface normal of the geometry, points in the opposite direction
> // of the surface normals of the mesh
> 
> dn = 0.6;
> dz = 100;
> 
> rcc = .1;
> rcb = .5*(94.6 - 89.3);
> rca = .5*(rcc*rcc + rcb*rcb)/rcc;
> 
> Point(1405) = { 89.30, 19.60,  0.00, dn};	// start tip
> Point(1406) = { 92.00, 19.60,  0.10 - rca, dz};	// Center of top circle
> Point(1407) = { 94.60, 19.60,  0.00, dn};	// end tip
> 
> Line(1404) = {1405, 1407};
> Circle(1405) = {1405, 1406, 1407};
> 
> Line Loop(1404) = {1405, -1404};
> Plane Surface(1404) = {1404};
> 
> ***** end   normal-ori.geo *****
> 

Hi Philip - Indeed, it's a tiny bug in the routine that draws the
normals of the geometry: the actual orientation of both the geometry and
the mesh are correct, but the displayed normal can be wrong when the
surfaces are very "thin" and the boundary curves are not straight lines.
This should be fixed in the next cvs snapshot.

>   In the main-graphics window of GMSH, the surface-normal of the geometry,
> points downwards in negative y-direction, whereas the surface-normals of the
> triangle-mesh point in the opposite direction. On other surfaces I mesh, the
> normal directions of the geometry and the mesh are consistent. Can the strange
> behaviour in the case be related to the small curvature of the circle?
> 
>   other points/questions:
>   
> -  I like to point out that when using the gui-options or gui-visibility menu's
> I am troubled by the need to press 'apply' every time I change settings. Is
> there a way to switch off this behaviour (in GMSH or FLTK) and make changes
> come into effect the moment you've clicked on them? Otherwise I would welcome
> such a possibility in future releases.

It's actually a bit tricky to get this right: if we were to apply
changes directly, it would prevent us to apply multiple changes at once,
which can be irritating with very large models (where applying each
change can require several seconds to regenerate the things to display).

I'm not sure what the best solution is. The road we've taken recently is
to try to mitigate the effects of having to click on "Apply" by
providing a way to use the keyboard to apply the changes. In recent
versions, for example, you can select entities in the Visibility Browser
and press <Enter> to recompute the visibility and apply the changes.

> 
> -  Memory use of the 3D netgen algorithm seems so much larger compaired to the
> isotropic algorithm. To the point of netgen exceeding the 2gb barrier
> (resulting in an abort of the program) for a geometry which when meshed
> isotropic, results in 24957 nodes and 139848 elements. Does this comaire with
> your experience?

Pretty much, yes.

> 
> -  Is it correct for GMSH to output meshes, containing nodes which are not
> referenced by any of the elements in the mesh?
> 

Yes, the output file will for example contain control points for
circles, which might not be part of any elements.

Thanks for the bug report!

Christophe

-- 
Christophe Geuzaine
Applied and Computational Mathematics, Caltech
geuzaine at acm.caltech.edu - http://geuz.org