[Gmsh] suggested new meshing algorithm in Gmsh: hex gridding
John Blackburn
John.Blackburn at npl.co.uk
Thu Jul 30 13:55:37 CEST 2009
Hi Pierre
Yes, you do need to smooth the elements after you've snapped the nodes
to interfaces. This is quite easy to do, you just regard the lattice as
a balls-and-springs network with the nodes as balls and the element
edges as springs of natural length that of the original cubic mesh. You
then relax according Newton's laws with friction. The nodes will move to
the lowest energy configuration. When relaxing, the nodes which have
been snapped are constrained to stay on the surface they were snapped
to. This can be done using the Lagrangian formulation with Lagrange
multipliers for constraints. I would not use the finite element solver
to do this, just implement Newton's laws directly on the particles.
The hardest part is, in my opinion, snapping the nodes to interfaces. I
think I could write the whole code quite easily but interfacing into
Gmsh (200,000 lines of c++) would be beyond me. One, not-so-elegant
solution would be for me to write my mesh algorithm as a "solver" in
Gmsh. This would read in the .geo file and output the .msh file.
John Blackburn .
________________________________
From: Pierre JUILLARD [mailto:pierre.juillard at gmail.com]
Sent: 30 July 2009 06:15
To: John Blackburn
Cc: gmsh at geuz.org
Subject: Re: [Gmsh] suggested new meshing algorithm in Gmsh: hex
gridding
Hi John,
Just out of curiosity:
Don't you need to "smooth" the elements close to the "snapped" boundary
nodes?
If yes, doesn't it mean that you also need to reposition the nodes not
only close to the interfaces, but also those which are in the geometry?
Finally, isn't this algorithm like a morphing algorithm?
I actually sent a mail to the mailing list to know what are GMSH'
capabilities regarding morphing, but there were not much answer.
Regarding this smoothing function, it would make use of the GMSH finite
element solver part, and deal with the existing mesh, make it deformed
linearly with a given E modulus to make it fit a new shape.
You would then have all the nodes positioned accordingly their distance
from the originally "snapped" nodes.
Regards,
Pierre
2009/7/29 John Blackburn <John.Blackburn at npl.co.uk>
Dear Sir,
I have recently been trying out Gmsh and am most impressed with
its capabilities. I am writing an FE code of my own which uses
hexahedrons. I've noticed that, while Gmsh does generate hex's this is
quite a painful process and involves splitting the geometry into many
more parts than would be the case for tets. Hex meshes can only be
generated for transfinite volumes or ones which can be made from
extrusions. I would like to suggest another method to generate
(structured) hex meshes which is to have a "logical mesh", which is just
a cubic grid of nodes, and then "snap" the nodes onto nearby interface
points. You then end up with a mesh with the same topology as the
original but distored to fit the required shapes.
I would like to add this functionality to Gmsh as I think it
would greatly improve the program. However, I am mainly a Fortran
programmer. I can code in C with some difficulty but full OO C++ is
beyond me! I was wondering, if I send you a detailed write up of the
algorithm I have in mind (with all the maths/geometry written out
explicitly), could you code it in for me? I suspect this simple
algorithm would be easy to implement given Gmsh's existing capablities.
Basically two things are needed:
* a function to decide whether an arbitrary point (x,y,z) is
inside a given volume (defined, as usual by plane or ruled surfaces
themselves defeined by curves: just the way Gmsh works now). I'm sure
Gmsh already has a function like this?
* a funciton to "snap" a point to the nearest point on the
volume surface. Note that only points at the interface between two
regions are candidates for snapping.
I've written a little program to implement this algorithm as I
see (in 2-D for the moment but 3-D would not be much more difficult).
The program outputs a .MSH file which I've plotted using Gmsh and
attached. Notice how the algorithm involves INSERTING shapes into each
other: the orange square was defined first, then the green circle, blue
circle, and finally, yellow polygon. This is very different from Gmsh's
current approach but its a very powerful technique.
I also intend to write a final "relaxation" part to the meshing
so the unecessarily distorted nodes in the blue circle would return to
their original positions.
What do you think about incorporating this functionality?
Basically, the user would do everything he normally does to prepare the
GEO file. Then there would be an extra button on the Mesh menu, "Grid"
for example.
Best Regards,
John Blackburn
-------------------------------------------------------------------
This e-mail and any attachments may contain confidential and/or
privileged material; it is for the intended addressee(s) only.
If you are not a named addressee, you must not use, retain or
disclose such information.
NPL Management Ltd cannot guarantee that the e-mail or any
attachments are free from viruses.
NPL Management Ltd. Registered in England and Wales. No: 2937881
Registered Office: Serco House, 16 Bartley Wood Business Park,
Hook, Hampshire, United Kingdom RG27 9UY
-------------------------------------------------------------------
_______________________________________________
gmsh mailing list
gmsh at geuz.org
http://www.geuz.org/mailman/listinfo/gmsh
-------------------------------------------------------------------
This e-mail and any attachments may contain confidential and/or
privileged material; it is for the intended addressee(s) only.
If you are not a named addressee, you must not use, retain or
disclose such information.
NPL Management Ltd cannot guarantee that the e-mail or any
attachments are free from viruses.
NPL Management Ltd. Registered in England and Wales. No: 2937881
Registered Office: Serco House, 16 Bartley Wood Business Park,
Hook, Hampshire, United Kingdom RG27 9UY
-------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.geuz.org/pipermail/gmsh/attachments/20090730/08fa0922/attachment.html>