Creating geometry and Meshing

50 views
Skip to first unread message

phillip mobley

unread,
Aug 13, 2016, 4:57:42 PM8/13/16
to deal.II User Group
Hello everyone,

I have been looking into creating 2D geometry and meshing for sometime. I was reading the FAQ and came across this little paragraph:

  • If GridGenerator does not offer a mesh for the geometry you have, but if the geometry is simple, then you can often create one "by hand". Take a look, for example, at how we create the mesh in step-14 using the Triangulation::create_triangulation function. All you need to do is take a piece of paper, draw the geometry and a number of coarse cells that form quadrilaterals, identify the locations of vertices and the connectivity from cells to vertices, and pass the corresponding lists to the Triangulation. Something similar can be done for simple 3d geometries.

I was looking at step 14 in the  "Exercise_2_3 class". Please correct me if I am wrong but it appears that in the class, you are creating geometry by specifying the vertices and what vertices the cells relate to. And then, from there you have to pass the information into the triangulation which "auto" meshes the geometry. Is this a correct understanding from a high level? In short, I could in theory create all of my 2D geometry in Deal.II. It appears that this method is a good candidate for what I would like to do.

I am currently porting a FEM program from windows to linux and converting from triangles to quads. I am sticking to 2D at this time. I am getting hung up on how to mesh the geometry. I have the geometry setup such that each line/arc is it's own class. Basic geometry shapes are derived classes of the line/arc class. in the line/arc class, I have information relating to what two vertices connect them and if there is an angle (for the arc). For the vertices, I have information about their center point. In short, I have all relevent information about the geometry contained in classes. 

I am currently thinking of a way t create the mesh from the geometry. At first, I was thinking that I could utilize the mesh generator from gmsh and copy the source from gmsh to my program. I would then have to convert my geometry into a format that the gmsh mesh function(s) can utilize. However, one obstacle from this is that the documentation for gmsh could be better. I could then use Deal.II gridIn class to import the mesh generated from gmsh. However, I am wondering if I could create this mesh in Deal.II directly, if this would simplify the process? 

This then brings me to Deal.II triangulation, the note I posted above, and "Exercise_2_3 class". It looks like I could create the geometry directly in Deal.II and mesh in Deal.II. This would appear to be the better solution because if my simulation needed 2+ areas of different mesh densities, then Deal.II can simplify that issue by looking at the material_ID of the cell and refining based on this parameter. (please correct me if I am wrong but isn't there another parameter I would look at instead of the material_ID in the event the two areas have the same material?)/ However, the only issue is that I am not sure how the Deal.II triangulation will handle geometry such as this: http://www.flynnresearch.net/technology/motor_cartoon.gif. It looks like that right now, it can only handle the geometry if it is square (please correct me if I am wrong). So, there may be a need for some code development on deal.II end.

To me, both processes involve a number of different complexities. So, I am wondering, which method would have less complexities? Utilizing GMSH mesh source and importing the mesh into Deal.II or doing some code development for Deal.II and directly drawing the mesh into deal.II? I am all for developing Deal.II and I hope that one day, I will be able to contribute meaningful code. However, if I needed to get a system up and running in a matter of weeks, which path would be more practical?

Timo Heister

unread,
Aug 13, 2016, 5:03:50 PM8/13/16
to dea...@googlegroups.com
Phillip,

another option is to get your mesh somehow into a format gmsh
understands (defining vertices, lines, etc. is quite simple) and then
meshing&exporting it. This seems to be a lot simpler than what you
describe (using the gmsh source code). You might want to take a look
at http://www.dealii.org/developer/doxygen/deal.II/step_49.html too.
> --
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see
> https://groups.google.com/d/forum/dealii?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "deal.II User Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dealii+un...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
Timo Heister
http://www.math.clemson.edu/~heister/

phillip mobley

unread,
Aug 13, 2016, 5:17:32 PM8/13/16
to deal.II User Group
At first, this was my first train of thought. If I am understanding your post correctly, I have my program which spits out a file that gmsh can read. Then, gmsh can create the mesh which my program will then read into and then all done.

However, after thinking about it some more, it would be preferred if the mesh module was contained with my my program. So that people would only have to use 1 program rather then two. Hence, utilizing the source code. 

Here is a link to the repo of the program that I am currently working on: https://github.com/OmniFEM/Omni-FEM

It would be ideal if I could integrate the meshing into the program directly. I would like it to be as simple as clicking a button and it meshes the geometry. 
Reply all
Reply to author
Forward
0 new messages