[Gmsh] gmsh1.65.0 Irix-patch

[Christophe Geuzaine]

Philip Kelleners wrote:
> 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

Yes, in Gmsh <= 1.65 we project on a mean plane, and back.

> documentation, on GMSH's internals, besides the source, or could you point
> briefly to publications/research you used in developing the surface meshing
> algorithm?

Too many to mention: look for anything by the group from George at 
INRIA. The next major version of Gmsh (2.0) will mesh directly in u,v 
space.


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

Let us know if you find a good one: we are in the process of rewriting 
the whole IO module.

Christophe



> 
> Cheers, Philip
> _______________________________________________
> gmsh mailing list
> gmsh at geuz.org
> http://www.geuz.org/mailman/listinfo/gmsh
> 


-- 
Christophe Geuzaine
Assistant Professor, Case Western Reserve University, Mathematics
http://www.case.edu/artsci/math/geuzaine