[Gmsh] suggested new meshing algorithm in Gmsh: hex gridding

[John Blackburn]

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
-------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.geuz.org/pipermail/gmsh/attachments/20090729/a4da5ece/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mesh4.ps
Type: application/postscript
Size: 12633 bytes
Desc: mesh4.ps
URL: <http://www.geuz.org/pipermail/gmsh/attachments/20090729/a4da5ece/attachment.ps>