[Gmsh] gmsh meshing error when mesh file is read into the hmd solver
James Willie
jwillie2000 at googlemail.com
Tue Oct 30 09:02:07 CET 2007
Dear All,
I am new to this programme but i am having this problem. I repeated some
examples in the user manuel of the hmd solver (
www.lumanmagnum.net/physics/heldeneng) and the meshing works fine but when i
run the hmd solver, i am getting the following error message:
ERROR: MSH file had bad format (tmpstr = (ERRO))
ERROR:Load_Mesh: gmshread
The hmd user manuel, the author explains that it is possibly due to the
ordering of the nodes from gmsh.
Is there anyone who had similar problems?
Thanks for the help in advance.
James
On 10/29/07, gmsh-request at geuz.org <gmsh-request at geuz.org> wrote:
>
> Send gmsh mailing list submissions to
> gmsh at geuz.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://www.geuz.org/mailman/listinfo/gmsh
> or, via email, send a message with subject or body 'help' to
> gmsh-request at geuz.org
>
> You can reach the person managing the list at
> gmsh-owner at geuz.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of gmsh digest..."
>
>
> Today's Topics:
>
> 1. gmsh 2.0.8 aborts or segfaults (magpar)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 29 Oct 2007 13:37:45 -0400
> From: magpar <magpar at magnet.atp.tuwien.ac.at>
> Subject: [Gmsh] gmsh 2.0.8 aborts or segfaults
> To: gmsh at geuz.org
> Message-ID: <47261A69.5040104 at magnet.atp.tuwien.ac.at>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hello Christophe,
> Hello all gmsh users,
>
> I am the author of "magpar" a "Parallel Finite Element Micromagnetics
> Package"
>
> http://magnet.atp.tuwien.ac.at/scholz/magpar/
>
> and I am trying to use gmsh to generate the geometry and finite element
> mesh of a nanocrystalline magnetic thin film.
>
> First of all, my sincere thanks to Christophe for gmsh, which is a great
> meshing tool and very helpful for free open source finite element
> applications like my own. Especially its parametric and scripting
> capabilites are very useful.
>
> I use Qhull to generate a 2D Voronoi construction of random seed points
> (with minimum distance between the seeds), convert the geometry
> information (points and edges of the Voronoi cells) into a gmsh script
> with commands to generate the surfaces (in the x-y plane), extrude them
> (once in positive and once in negative z direction) and generate 2
> physical volumes for each Voronoi cell.
>
> I have to disable AutoCoherence because otherwise gmsh renumbers the
> unused points and duplicate points and lines while it imports the
> geometry, which messes up the definition of the lines in the remainder
> of my geo script. These duplicate points and lines are generated by
> Qhull/qvoronoi and am trying to avoid to write a script and remove them
> by hand myself.
> At the end of my geo script I delete all points (gmsh removes only the
> unused points anyway), call "Coherence" to remove all duplicate
> geometric entities and generate a png snapshot (see attached examples).
>
> The procedure outlined above works very well with both mesh generators,
> Tetgen and Netgen, up to 200 cells. When I try to generate 300 or more,
> gmsh unexpectedly aborts or I get segmentation violations.
>
> Interestingly, gmsh usually throws a segmentation fault after meshing
> the last volume with Tetgen (Mesh.Algorithm3D=1) while it fails much
> earlier with Netgen (Mesh.Algorithm3D=4).
>
> When I remove the commands after the last "Physical Volume" (deleting
> points, coherence command, printing) I get a simple "Abort" during
> meshing of the surfaces instead of the segmentation faults.
>
> Now my questions:
>
> What could cause these problems? The geometries do not get more
> "complicated" as I increase the number of Voronoi cells, I am just
> generating more cells (relatively simple extruded volumes). Thus, it is
> my suspicion that the problems are caused by gmsh itself rather than the
> meshers (Tetgen or Netgen).
>
> Are there any fixed size internal arrays which could cause these
> segmentation violations due to overflow? If so I would be grateful for
> any hints where in the gmsh code they are defined, so I can increase the
> array sizes.
>
> Or are these problems indeed caused by the meshers, which might have
> similar array overflow problems?
>
> I am using Gmsh 2.0.8
>
> gmsh-2.0.8-Linux.tgz
> precompiled Linux (Intel, glibc 2.3) binary from Gmsh website
>
> and also a gmsh version without GUI compiled from gmsh-2.0.8-source.tgzwith
>
> gcc (GCC) 4.2.3 20071014 (prerelease) (Debian 4.2.2-3)
>
> ./configure --disable-gui
> (including Tetgen)
>
> on Debian testing (lenny/sid).
>
> Both binaries throw the same errors.
>
>
> Any helpful comments or suggestions are greatly appreciated.
>
>
> Thanks and kind regards,
>
> Werner Scholz
>
>
>
>
> Description of attachments and error messages:
>
> media_o01.geo (this example works fine)
> -------------
> 298 volumes
>
> works with both Tetgen and Netgen:
> Mesh.Algorithm3D=4;
> Mesh.Algorithm3D=1;
>
> media_p01.geo (this example causes seg. faults)
> -------------
> 580 volumes
>
> Mesh.Algorithm3D=1;
>
> gmsh media_p01.geo -3
>
> Info : Meshing volume 580 (Delaunay)
> Fatal : Segmentation violation (invalid memory reference)
>
> Mesh.Algorithm3D=4;
>
> gmsh media_p01.geo -3
>
> Info : Meshing volume 59 (Netgen)
> Fatal : Segmentation violation (invalid memory reference)
>
> media_p04.geo (not attached)
> -------------
> deleting of points, coherence command, printing removed at the end
>
> Mesh.Algorithm3D=1;
>
> gmsh media_p04.geo -3
>
> Info : Meshing surface 236 (Plane, MeshAdapt+Delaunay)
> Info : Meshing surface 237 (Plane, MeshAdapt+Delaunay)
> Info : Meshing surface 1428 (Ruled surface, MeshAdapt+Delaunay)
> Aborted
>
> Mesh.Algorithm3D=4;
>
> gmsh media_p04.geo -3
>
> Info : Meshing surface 236 (Plane, MeshAdapt+Delaunay)
> Info : Meshing surface 237 (Plane, MeshAdapt+Delaunay)
> Info : Meshing surface 1428 (Ruled surface, MeshAdapt+Delaunay)
> Aborted
>
> --
> magpar - Parallel Finite Element Micromagnetics Package
> WWW: http://magnet.atp.tuwien.ac.at/scholz/magpar/
> email: magpar at magnet.atp.tuwien.ac.at
> list: majordomo at magnet.atp.tuwien.ac.at
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: media_o01.geo.gz
> Type: application/x-tar
> Size: 19072 bytes
> Desc: not available
> Url :
> http://www.geuz.org/pipermail/gmsh/attachments/20071029/c415f2c1/attachment.gz
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: media_p01.geo.gz
> Type: application/x-tar
> Size: 34231 bytes
> Desc: not available
> Url :
> http://www.geuz.org/pipermail/gmsh/attachments/20071029/c415f2c1/attachment-0001.gz
>
> ------------------------------
>
> _______________________________________________
> gmsh mailing list
> gmsh at geuz.org
> http://www.geuz.org/mailman/listinfo/gmsh
>
>
> End of gmsh Digest, Vol 57, Issue 25
> ************************************
>
--
James F. Willie
Turmstr. 16B, App. 54
Aachen D-52072
Germany
Home phone:+492411686707
Mobile:+4917624921240
Office: +492418025462
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.geuz.org/pipermail/gmsh/attachments/20071030/b9034904/attachment.html>