Hi, I don't think you should underestimate the problem. Creating a good and conforming hex mesh is difficult. I can help you with the writing it in C or C++ if you want.
For cartesian approach you can find a very simple hex mesher I wrote: http://www.cfd-online.com/Forums/openfoam-meshing-opensource/61973-generating-unstructured-grids-stl-files.html Regards, Billy. On Wed, Jul 29, 2009 at 4:18 PM, John Blackburn<[email protected]> wrote: > 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 > [email protected] > http://www.geuz.org/mailman/listinfo/gmsh > > _______________________________________________ gmsh mailing list [email protected] http://www.geuz.org/mailman/listinfo/gmsh
