Gmsh problems

Thu Jun 8 10:10:57 CEST 2000

Hello Christophe,

I am currently working in a Norwegian Electro-optic company, and for several
years I have been working with the modelling and simulation of lasers. I
find computer modellig both interesting and also useful for my work. During
the last couple of years I have also started to use the finite element
method, so far mainly for thermal and stress simulations. 

I have been using Matlab for many years, and for finite element simulations
I am mainly using the Diffpack library. I also do some mechanical model
drawing using Solid Edge. The missing link in this setup is the transfer and
meshing of mechanical models to Diffpack. I know that there are some
commercial solutions available, but they are too expensive for my budget. 

A year or two ago I came across your Gmsh program, which I have found quite
useful. I have been drawing some simple models directly in Gmsh, and I have
also generated some .geo files programmatically using Matlab. I have written
a mesh converter from the native .msh format to the Diffpack format. I now
want to transfer some mechanical models to Gmsh. I can save the models in
several formats, including .step and .stl. You have previously had some
.step file import facilities in Gmsh, but I think this has been experimental
and has never really worked for me. 

The .stl format is very simple - it basically describes the model's surface
by a set of planar triangles. I have written a Matlab routine which converts
a .stl file into a .geo file. The .geo file basically sets up the node
points, draws the vertices of the triangles, and defines a line loop and a
plane surface for each triangle. I have also tried to incorporate a
facillity of merging neighbouring triangles on a common plane, to reduce the
number of surfaces, but i'm not sure this routine is quite bulletproof yet. 

Now to the problems: At work I am running a Windows NT 4.0 PC, with Gmsh
version 0.93. With this version I have seen many problems, especially with
memory access violations. I have also tested the latest Gmsh Linux version
on my home PC. It may seem to work better, but I have also seen other and
similar problems with this one. I am attaching two (relatively large)
example .geo files which I have converted from .stl files. They are both
from the same part. "hold1.geo" is a converted file with all triangles
intact, and "hold1_merged.geo" is the same file with some of the planar
triangles have been merged. Below I will describe the Gmsh behavour that I
have seen with these files:

hold1.geo:
Gmsh - Windows: File loads OK. 1d meshing OK. 2d meshing => crash at surface
506. Attempt to generate a surface loop and a volume, normally crashes the
program so bad that it exits, but at one time it added some corrupt letters
in the .geo file which gave a parse error.

Gmsh - Linux: File loads OK. 1d meshing OK. 2d meshing goes through, but the
mesh is corrupt - parts of it extends far from the model (on one side).
Attempt to generate a surface loop and a volume produces a surface loop on
the command window, but then a segmentation violation occurs immediately and
the program exits.

hold2.geo:
Gmsh - Windows: File loads OK. 1d meshing OK. 2d meshing OK. Surface loop
and a volume are generated OK. 3d meshing goes through without errors, but
nothing is done - no mesh is generated.

Gmsh - Linux: Not tested, but several other test files have shown the same
general behaviour as for hold1.geo

Whether the windows version crashes or not during 2d meshing seems to depend
on the direction of the surface loop. The hold2.geo file which came through
OK  was tweaked by flipping the direction of some surface loops based on
information from the normal vector. I have, however, found no hard clue
concerning what the "crash-free" direction should be. The susceptibility to
crashes seems to be especially high when the z-component of the normal
vector is negative or especially 0. I have also tried to start the loop at
different points. This has not improved the situation, but the error
messages have changed: Access violation at FFFFFFFF, Access violation at
other adresses, atan2 domain error. An even more serious problem for me with
this is that even if I am able to do the 2d mesh and to create a volume, no
3d mesh can be generated. With another converted model, Gmsh was able to
generate a 3d mesh after I had defined some lines as Transfinite. Do you
have any clues concerning when Gmsh will and will not generate a 3D mesh?

I think Gmsh is a nice and useful program (if it only could work), but right
now, I am quite frustrated. I have struggled somewhat to make it behave as I
want, but I now feel that I have come to a dead end, and I if you don't have
any real good clues or fixes, I unfortunately think that I will have to
start working with other possibilities for my immediate file transfer and
meshing task. I hope, however, that the information that I am sending you
can help you to remove some of the glitches and improve Gmsh. What are the
current status and plans concerning the import of foreign file formats into
Gmsh?

Best regards,

Stig Landrø,
Simrad optronics ASA
P.O. Box 6114 Etterstad
N-0602 Oslo
Norway

Tel: +47 22 67 04 90
Fax: +47 22 68 07 04
mailto:stig.landro at simrad-optronics.no
Private: mailto:slandroe at online.no

 <<hold1_merged.geo>>  <<hold1.geo>> 

**********************************************************************
	This message has been virus checked by MIMEsweeper
			Simrad Optronics ASA
**********************************************************************
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hold1_merged.geo
Type: application/octet-stream
Size: 77015 bytes
Desc: not available
URL: <http://www.geuz.org/pipermail/gmsh/attachments/20000608/e14d56d3/attachment.geo>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hold1.geo
Type: application/octet-stream
Size: 123570 bytes
Desc: not available
URL: <http://www.geuz.org/pipermail/gmsh/attachments/20000608/e14d56d3/attachment-0001.geo>