[Gmsh] surface normal orientation - geo vs. mesh

[Philip Kelleners]

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



***** output of gmsh -info *****

Version        : 1.60.1
GUI toolkit    : FLTK 1.1.6
License        : GNU General Public License
Build OS       : IRIX64 6.5
Build options  : GSL TRIANGLE NETGEN JPEG PNG ZLIB MATHEVAL 
Build date     : Wed Mar 30 00:28:26 MEST 2005
Build host     : removed
Packager       : philip
Web site       : http://www.geuz.org/gmsh/
Mailing list   : gmsh at geuz.org

***** output of gmsh -info *****



  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.

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

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


Regards, Philip