[Gmsh] gmsh1.65.0 Irix-patch

[Philip Kelleners]

Christophe Geuzaine wrote:

> > next to that, the configure.in, contains an assumption regarding the name of
> > the C++ compiler under IRIX. When this is named differently in the environment
> > variables, (e.g. setenv CXX /bin/CC  instead of setenv CXX CC) configure does
> > not setup the right environment for the C++ pre-linker under IRIX. I don't
> > really have a ready solution for this.
> 
> I've tried to fix the configure script so that we detect the substring
> instead. Let me know if this works out.

I downloaded, unpacked gmsh-nightly-source (2006/06/21) this afternoon. It now
configures/compiles without a glitch; my compliments and thank you for the
inclusion of my patch/suggestions.

> > And finally I have part of larger .geo (bzrs.geo) attached. This surface is
> > built entirely of bezier-curves and highlights a weakness in the 2D surface
> > meshing algorithm I think. The triangles in the vicinity of point 6 are
> > stretched unfavourable I feel. Please give your opinion on this one.
> 
> I'll have a look at this a bit later.

I do know little about the internals of GMSH, as/and I don't have proper
knowledge of C++. (despite years of experience in ansi-C, I haven't crossed
the bridge to C++, that I consider a different language although its syntax
may seem derived) Is it correct that GMSH-3D-surface-mesh generation involves
a mapping stage from the 3D space to a 2D u,v parameter space, and back? Where
the triangular surface meshing operates in u,v parameter space? Is there
documentation, on GMSH's internals, besides the source, or could you point
briefly to publications/research you used in developing the surface meshing
algorithm?

In the past weeks I have been reviewing, a lot of publically available 2D and
3D meshing codes. Living in northern-europe this excludes a lot of
export-controlled codes available in the U.S.. Despite the large global
interest, and research investment, I feel a lot of the available codes suffer
from several kinds of drawbacks, major and minor ones, mainly by beiing bound
to an application in a particular science research direction. Next to that, in
our department I have access to commercial ICEM. It has a powerfull
GUI-interface and offers a myriad of functions, some very usefull, some
useless. In my experience it can crash on you, and e.g. ICEMs way of
prescribing a discretisation on geometrical defined shapes is plain bad and
restrictive. Delaundo's Ipol is the way to go in this respect; on the
downside, Delaundo is limited to 2D, and seems already longtime abandoned.
  Among these codes GMSH still stands favourably. I feel a lot can be gained
by a common interface/mesh format, that should allow to combine strong points
of different codes and packages (The old UNIX way of connecting tools).
However how that interface must be defined or shaped I cannot tell at present.

Cheers, Philip