Master Degree Grid/Mesh Generator
 

hello :)

I am making a grid generation program to earn my master degree with it,

I was hoping for some help
- Current software of Grid Generation (open source, or commercial)
- Known problems that needs solving or enhancements
- may be use cases also that is hard to be implemented by current solutions.

I am attaching a snapshot of my program that I've made so far

I am new to CFD world and very interrested to learn
but my professor said that Grid Generation is most hard part in CFD

I've gained many knowledge now in curvilinear coordinates and tensors in general

my software is written in C# and OpenGL

however as I consider myself good at programming but I lake the required knowledge to go to the right direction in grid generation (specially that I don't recognize the challenges in this track neither in research nor in industrial field)

I appreciate your help and supporting

Thank you,

Hi Ahmed,

It sounds like an interesting project.

- Current software of Grid Generation: there is a dedicated link on this website to mesh generation. My personal experience: free software: Gmsh, snappyHexMesh (part of openFoam), EnGrid - commercial stand-alone software: harpoon.

- Known problems that needs solving: Being able to automatically mesh (or repair) a bad CAD - i.e a CAD with gaps, holes, duplicated surface, too much details, etc.

From my perspective, a useful mesh generator needs (at a minimum) the following:
- a command line interface so that it can be run without starting the GUI (it therefore needs a writable input file);
- be able to import and export in useful formats.

Do you plan to release it open-source or free and are you going to maintain it after your thesis?

I hope this help.

Julien

Yes, I am wondering, anyone has done a code survey on current open mesh generator with GUI?

Gmsh is not using the elliptic method I am looking for, so I am looking for the other most updated one.

But besides, this, if for example, if I have the numeircs ready, what is the best way to develop a GUI interface. I really wanna a try, it's fun.
Anyone could give an recommendation of which opensource that I could start a GUI with concerning mesh building related functionality.

I agree with Julien's perspectives, and I have more to say, though it is quite personal,

I just hate there are so many buttons on the GUI windows, like building verteice, and then building the connections, and then blahblah..


I think any mesh generator developer should understand that certain operations are best go with macros or run in a batch mode, instead of clicking one's mouse.

BUT, certain operations DO need mouse clickings.

So I dont like some commercial software who has so many buttons there, just a show-off, to show that they are comprehensiveness, but without a clean interface. That's why my votes goes to GridGen and GridPro.

Well I am not an expert but I can say moving mesh is definitely burning issue. If you can try and address this issue it would be great. Generally it is part of solver but if somehow it can be incorporated in grid generation software users can have a lot of advantage.

Moving mesh can be viewed as part of mesh enhancement, and mesh enhancement can be (traditionally speaking) viewed as part of mesh generation.

IMHO, So technically speaking, just write the mesh solver based on a good numeric (elliptic of cause) and then you will have them all available.

Hi Julien,

yes you are helping a lot, the problem I have now is that I am developing in CFD without using it already (so I have many issues in realizing all concepts)

I actually avoided the concept of CAD importing because I was fearing that I sink in CAD files formats (there is a lot out there, like SpaceClaim, Inventor, and Creo Elements)

so I am adopting the concept of making my program a CAD design itself (I know it may be a not optimal solution in industry, but I can't take a risk of learning to import specific format, then to make a conclusion about the intent of the designer. I believe for now that modeling the part itself in my program will be helpful in deciding the required mesh algorithm for filling it [I think so])

I already can draw line or bezier curve then rotating it around x, or y axis.

regarding open source or free, it is very early to decide that, specially that I can't decide without my professor approval (however the whole thing is a one man show, so I really may release it as an open source [I know this will help a lot] )

about maintaining it after thesis, (my professor says that he can let met work on solver also then gives me the PhD) (frankly :D from what I see it is easier to say than to work, very very long waaaaay)

hiDaniel

my professor showed me his meshing program and it was a disaster because he should define every point, and in Dos mode.

and you are telling me that :( this behavior (user experience) still exist even in modern programs.

I will try to see GridGen.

regarding GUI, it depends on your programming language

C++ --> use QT or GTK+
C# --> Microsoft Windows Application, or WPF Application like mine
--> better mono with gtk# if you will run it on linux

for 3D you will have to use OpenGL, or DirectX (I perefer opengl because of the standards and all of this stuff)
also there is visualization libraries (but I didn't dare to try one of them) OpenGL.org have a nice resources.

by the way I don't know what is the elliptic method (I will search for that), I will implement Structured Grid Only (this is also because I am really still in the early digging, and the view of the unstructured grid is overwhelming for me)

The 7th chapter in Farrashkhalvat Basic Structured grid Generation book mentioned this.
he took the time as fourth dimension and deduced all the equations again.

really very interesting
I will try to implement that if things didn't go mad with me

:)

Hi Ahmed,

Interesting thesis you are writing! Two notes, that coming through my mind...

• Philosophy:
  As it was already said, you firstly should think of your intended project in general. There are mainly three options, I see:
  1. You are a amazing code developer for geometric problems and your tool will be straightforward, then you may will be a rich person someday.
  2. You are developing a specific code to the needs of your thesis and some people would succeed with using your program, you will probably get lined in the list of good meshing tools, e.g.
     http://www.robertschneiders.de/meshg.../software.html.
  3. You are start a project, that will be breathing after you reach the master degree and probably this meshing tool find its way to a huge community of users.
  
  The latter one should imply that you share your experience, progress and consequently code.
  
  
• Technical viewpoint:
  When you go through the list above or looking right here http://www.cfd-online.com/Links/meshing.html you will find a lot of tools for unstructured grid generation and a few for structured. So you can guess, what is the difficult part of meshing complex geometries with high quality results.
  In general you want to have a good mesh with as less as possible effort and of course cells, because that saves money in simulation process. One hex = several tri (you already know this: http://www.numericana.com/data/polycount.htm)! That's why multi-block structured meshes are still preferable for CFD, but very tough for complex geometries.
  
  GUI is fun, but should not be needed for reliable meshing, especially thinking of automatic generation process. The main problem from practical side is the input of a CAD-based geometry description (or you need to create it on your own). I do not want to bother with geometric entities, faces and so on, when doing a mesh, if the geometry already exists.
  Most critical part: How to describe the geometry for your meshing program without running into trouble with bad geometry descriptions (e.g. nurbs/tri faces with gaps, double entities/faces and so on...) from CAD? The long list of available formats and consequently work around of cleaning CAD files mirrors the difficulty.
  The easiest way to start a mesh from is a unique cloud of points (offsets). Starting from these points and finish with a good quadrilaterally-faced hexahedral mesh will be the key to success in my understanding, because that program is still missing from my limited point of view.

I am looking forward for your program ;-)
Good luck!

/Stefan

Hi Stefan,


I would really like to be a rich man :) however I am sure that life reality will force its parameters over my intention
my project should be able to do meshing in general, however as you said, it will be more likely that my dreamy expectations lower itself to my real abilities.

I find your view about sharing my progress is very important, I will try my best to achieve such a behavior.

glad to know that structured mesh is more complex than unstructured mesh. (because I will focus on the structured one)

also that I should make less cells, due to less calculation time is a new information for me.

currently I am trying to make axis-symmetric models and meshing it. ( I know it can be done by 2D mesh then integrating it in some way) but its a start

I've read a lot of mesh algorithms, and I still try to grab the required information.

Why is the automatic meshing?
 

Now after all your valuable replies, I really wish to ask Why is automatic meshing is needed ??

I understand from your feedback that you want to be able to mesh a batch of fmodels (parts)

something like this

c:\> Mesh *.models -output *.msh -otheroptions

did I get it right ??

sorry again for my limited experience, it may be intuitive to the experienced CFD users, but unfortunately I am still in learning phase :)

Grid generation takes much effort during simulation process. So reducing this time is one of the main objectives.

My understanding for 'automatic meshing' is more like (typical outer fluid flow problem):

• Take my geometry (mostly closed surface)
• Take my/define boundary domain (closed, too)
• Define mesh topology
• Mesh enclosed volume between these surfaces with appropriate count of default blocks, i.e. 10x10 cells per block for pure hex grid
• Check topology (inconsistency, etc.) -> correct, if needed (iterative process)
• Smooth mesh according to default quality parameters (orthogonality, i.e.)
• Define mesh refinement close to surfaces
• Define boundary layer parameters (e.g. normal height of 1st cell, etc.)
• Refine mesh, again with smoothing

Quite often you will have the following procedure:

• Input geometry (CAD-Export)
• Heel bad geometry
• 'Reinvent' the geometry within mesh program (i.e. surface based meshing tools)
• Building blocks step by step (all by hand)
• Allocate points on connected block edges (all by hand)
• Check mesh (on your own)
• Improve mesh (cut and reconstruct mesh)
• Refine mesh
• Using smoothing afterwards

The latter one needs GUI to perform all these task by hand. It's exhausting to build grids this way.

Fast high quality meshing with support of massive parallelism should be the way of grid generation in future ;)


/Stefan

Hello Ahmed:

You are to be congratulated for wanting to work on mesh generation. Your professor is correct - it is the hardest part of CFD and therefore the part where advancements are needed.

I'm not certain the world needs yet another grid generation software program. Instead, focus on some of the core issues that make mesh generation challenging. Develop methods, don't write a program. Several other people have already mentioned these things but I'll repeat some of them here.

Dealing with CAD geometry (defeaturing, healing, abstracting). Quantification of a priori mesh quality metrics on CFD solution convergence and accuracy. Unstructured hex meshing. Anisotropic unstructured meshing (i.e. stretching along flow features such as boundary layers, wakes, shock waves). Automatic decomposition of a 3D domain into zones (for structured grid blocking, for example). Parallel tet meshing. These are just a few ideas.

Best of luck with your research.

Let's just add one issue: High order grids!

cfdnewbie:

What exactly do you mean by "high order grids"? The generation of higher order elements (e.g. a quadratic hex with 1 mid-side node per edge) is a solve problem. Do you mean issues associated with using higher order (e.g. quadratic or cubic) elements in a CFD solver?

Dear John,
What I mean by high order grids is the representation of curved geometry by elements which are high order accurate, e.g. high order polynomial mappings (let's say p>=4) with well-defined normal vectors. To my knowledge, the generation of curved high order meshes is an open issue, since most grid generators just produce linear elements..... Or has that been solved? I'm not completely up to date with the new features of grid generators, I admit!

cfdnewbie: Generation of higher order elements for FEA is a commodity feature. It's just that CFD meshers usually only support linear elements because there aren't many solvers that support higher order elements. In other words, I don't think research is required. Someone just has to sit down and code it.

Recently, I have just written an amateur's review on current mesh generations. I think you make this too hard for ibluesun, he just started it. :)

My two cents is:
Since we dont know exactly what ibluesun's background is, so the way he focuses on mesh generation might be different than others. :) You all shared about your concern on CAD geometry import and export and healing issue, but is this so urgent for a beginner? For me, doing turbulence studies on some simple geometries, I dont care CAD issue at all.

So I agree with Dr. Chawner's doubt, --"do we need another mesh generation software", my point is this,
I feel some issues like what Dr. Chawner has mentioned: 1) "Automatic decomposition of a 3D domain into zones"; 2) "Quantification of a priori mesh quality metrics on CFD solution convergence and accuracy"; are actually more urgent than the others for a beginner, so that his contribution to mesh generation will not turn out to be solely a GUI, but a very cool mesh solver behind it. And the better he understand a mesh solver, and the better he will have a good philosophy for a mesh GUI design.


Last points, I think Mr. ibluesun will not and can not handle all the issues in limited years, so why not pick up one or two issue and delve into it.

Personally, I still think multi-block structured mesh is more valuable than unstructured mesh, they should be sought whenever possible. :D:D

Hi Ahmed,

Here is my suggestion on an approach:
1) Talk to various people to get an idea of types of physics which create the biggest challenges for CFD.
2) Somehow get an idea of what CFD methodologies are required to capture these physics. This can include RANS, DNS, LES, and discretization methods, just to name a few. You don't necessarily need to understand the theory behind it, yet, but you do need to know what is out there.
3) Ask your professor if he/she can recommend some people in industry who use CFD that you can talk to one-on-one. Get an idea of how they use CFD, what their expectations are, and the direction they would like CFD to go.
4) Go back to your professor and have an in depth CFD discussion.
5) Factor 1-4 into your choice of paths forward in regard to gridding.

It is my opinion that there are two types of CFD out there, qualitative (get a basic idea of the flow) solutions and quantitative (nail down the numbers) solutions.

Getting qualitative results seems to be a very well populated market segment.

However, who and what is in the market segment for quantitative results is much more ambiguous. I think some like to give the impression that their qualitative results are quantitative, when they are not. Unfortunately, many times I can't sort out the truth from the fiction. It is also hard to determine how "good" or "bad" a result is.

Getting quantitative results is a real pain, at least for me. And it is not just the gridding. It is the whole process.

Take something as simple as a vortex. Tracking it properly can be a challenge, especially when it is interacting with flow features and geometries. And tracking it properly requires a bit of gridding and CFD solver work. The unfortunate part is that the vortex trajectory and strength is sensitive to the grid, time step, and the order of the spatial discretization. How "good" higher order spatial discretization is depends on how "good" the grid is. Higher order discretization tends to be sensitive to the grid.

So now we get, in my opinion, to a basic question. For quantitative results where one needs to resolve severe nonlinearities, (shocks, wake on geometry interactions, tracking a vortex, etc) is a structured or unstructured grid better? I don't have the answer to this. And the choice of structured vs. unstructured is not just based on geometry, gridding, and whether the CFD formulation is implicit or explicit, it's also based on computer hardware. In general, structured grids are more efficient with the memory bus.

You can find examples of structured and unstructured grid results at the drag prediction workshop, http://aaac.larc.nasa.gov/tsab/cfdlarc/aiaa-dpw/ (at the bottom of the page you'll see links to the older workshops) And don't forget, these are nice clean configurations. Sure, they have some physics excitement, but not nearly as much as they could! (Personally, I think it would be more fun to do the computations of one aircraft in the near wake of another!)

Edit: My example of structured vs. unstructured is not necessarily connected with Daniel's comment since I posted my reply before I read his post.

The more you sweat over CFD, the more you hate others abusing it :)