An Epiphany (I think).
 

I've been experimenting with mesh settings trying to find out what causes a simulation to not converge...

Running checkmesh on mesh's for failed runs I found it failed the check due to highly skewed faces being detected. The faces all having a max value greater than 4. But there were only 7 or so failing each time.

That lead me to think it was something to do with the setting: maxInternalSkewness but that was set to 4 already, so what was going on?
Reducing the maxInternalSkewness setting say to 1 fixed the issue but now the mesh looked rough and even raising the value to 1.5 I got skewed faces in the checkmesh results again.

Then the light bulb came on and I realized that the maxInternalSkewness set to 4 was correct but that the setting:

// The surface refinement loop might spend lots of iterations refining just a
// few cells. This setting will cause refinement to stop if <= minimumRefine
// are selected for refinement. Note: it will at least do one iteration
// (unless the number of cells to refine is 0)
minRefinementCells 10;

Meant that once there were less than 10 problem cells the meshing process moved onto the next step, which is why I was seeing less than 10 problem faces each time.

So I've put the maxInternalSkewness back to 4 and set minRefinementCells to 0 (i.e. no cells are allowed to fail any of the meshing checks that run as snappy does its work).

The mesh generated with about 20% more cells than previously and took about 25% more time to mesh so I assume running the simulation will also be about 25% longer than before.

I'm running the simulation at the moment and looking at the results as they are coming in everything appears to be hanging together nicely after ~1200 iterations, past runs that went bad did so after about 500 so I'm hopeful I've found a fix for my issues.

I've read a number of threads on the forum with people trying to fix skew faces but not found this solution before.

So the question is, is what I've described above right or not?

Greetings Doug68,

That sounds about right.
There are situations where that parameter might come in handy (i.e., to be >0), as any other parameter on "snappyHexMeshDict".

Additionally, there are situations where some parameters can be relaxed... as shown near the end on the "tutorials/mesh/snappyHexMesh/flange/system/snappyHexMeshDict".


If you check the various "snappyHexMeshDict" files available in OpenFOAM's tutorials and on the original source code folder, you'll see that although many parameters are set to values that work in most cases, there are some that have minor adjustments for better results... OK, you probably already know this.
But this you might not know - run in the tutorials folder this command:
It will show you the different values used on each case!


Last but not least, always keep in mind that one of the major important details is the base mesh! ;)

Best regards,
Bruno

Turns out I got a little ahead of myself :(

The results from the simulation look believable but I get the following in checkmesh:

Max skewness = 9.3085, 3 highly skew faces detected which may impair the quality of the results

Which I had expected to not be possible with the settings as in the first post.

To date I've been using a simple blockmesh definition 0f 0.1m cubes covering the 20m x 8m x 4m volume in use, I think my next step would be to look at putting a finer mesh in to the area of the volume in - around where the stl file sits?

Hi Doug68,

There is another trick that sometimes works: center the STL and the base geometry in the space origin.
When the mesh is complete, move it back into place.

"How?" I expect you to ask - Use transformPoints (for mesh) and surfaceTransformPoints (for STL).

Best regards,
Bruno

Hi Bruno,

I'm in the middle of trying this I'll let you know the result.

I'm also wondering whether to try running using obj rsther than stl? My stl files are typically about 400mb compared to ~60mb as an obj.
So clearly obj is a mor efficient way to describe the geometry, perhaps this has an effect in meshing. The next test I think.

So here's some results...

The center of the shape in the stl file is at about 6,0,0.5 in an unmodified form, so for 3 different runs:

1. With the stl file located as above gives: Max skewness = 9.01339, 4 highly skew faces detected
   
2. With the stl file moved -6,0,0 gives: Max skewness = 9.01339, 5 highly skew faces detected
   
3. With the stl file moved -6,0,0 then the mesh moved back 6,0,0 after creation but before the sym runs: Max skewness = 9.01339, 4 highly skew faces detected

The results in terms of reported forces were identical for 2 & 3 above 1 recorded 6% different though.

In total I've ran this sym 9 times with different combinations of maxInternalSkewness and minRefinementCells looking a force in the z direction taking the average of the last 500 iterations (out of 2500) the force reported varies some 24% between the max and min value. I think there's a lesson in that if someone can tell me what it is I'd like to know ;)

At some point in a previous run I had got it down to: Max skewness = 4.73026, 1 highly skew faces detected I think that was with minRefinementCells set to 1 or 2 though, which may be the best I'm going to get.

Given my mesh has 8889571 cells in it should is chasing this down a worthwhile effort?

Hi Doug68,

Well, one lousy cell can lead to the solution not converging, but it doesn't necessarily mean that the results after 5000 iterations are completely useless. You'll have to take a look at results and compare if there are significant changes over the domain and inlet/outlet patches.

Additionally, there is an utility that can help you with detecting the locations where the residuals are greater in the simulation domain: simpleFoamResidual
This isn't part of the standard OpenFOAM distribution, but the particular code for that utility is present in OpenFOAM 1.6-ext and easily compilable in the latest OpenFOAM versions.

This application will create another scalar field with the non-normalized residuals, which you can then inspect with paraFoam.

edit: I forgot to mention: why don't you use a refinement box where the skew faces are located?
edit2: Another thing: Wavefront OBJ files have the advantage of not repeating points. STL defines the same point for every triangle that uses it, but OBJ only defines each one once! So that way you can save yourself a lot of pain with crooked triangles...

Best regards,
Bruno

So I pretty much failed with simpleFoamResidual, this appears to need a laminar model before it'll work? According to the errors I received anyway.

So then I used the FoamLog function to create the log files individually, brought these into excel and plotted them out. The result is the attached file, to my uneducated eye it looks good to me, what am I missing?

A few details:

• Use log scale on Y axis, so it's easier to see values.
• It's good that the graph lines seem stable after several iterations.
• The rule of thumb I usually use (because someone else told me so :rolleyes:) is to have the pressure residuals below 1e-3.

Best regards,
Bruno

Here it is, not so bad?

Seems stable after 1500 iterations (which would mean no need for more iterations), but I'm not so certain if the solution achieved is accurate, given the pressure being above 1e-3 and Uy above 1e-4...

Hi Doug68,

I gathered the following info just now for another thread:
Good luck!
Bruno

So after much stuffing about I think I'm getting somewhere...

Attached you'll find a plot of the residuals, the forces and a snapshot from Paraview.

The Cd comes out at about 0.42 which is basically believable.
There's some 7.1m cells in the mesh.

The breakthrough came when fvsolution was set as attached, maybe this'll help someone else. Comments?

Hi Doug68,

I hope more people can comment on this, because I'm unable to make a experienced comment on "fvSolution".

But I do know that:

• ForcePZ is oscillating a lot! This could be indicative of a transient simulation by nature... Either that, or not enough number smoothing :p Or it's due to the mesh...
• The pressure residuals seem acceptable, although those spikes seem a bit strange... also possibly it's due to the mesh itself.
• The configurations in "fvSchemes" also weigh heavily on the results and convergence.
• It doesn't make much sense letting the solver run for more than 1500 iterations with these settings. It was already as close to convergence as it could get with those settings.

And 7.1M cells is a whole lot of cells! The big question is if you were able to properly add layers around the whole vehicle...

Which reminds me, you can find new intel on snappyHexMesh here: http://openfoamwiki.net/index.php/SnappyHexMesh

Best regards,
Bruno

I'm inclined to think that the oscillation in forces is dues to the shape itself.

The attached charts are from a run done with a rear wing for the car on its own, this is a NACA profile with a Gurney flap on it and end plates.
The snappy settings were identical for this and the previous runs.

Hi doug68 and bruno,

maybe some infos due to the residuals (for the not converging situation).

Bruno mentioned that 7.1 million cells are very much and thats correct. I saw many meshes used in cfd simulations in companys and have to say that some meshes are too fine for RANS. After the 7th OFW I had a look to some presentations. The meshes of validation cases are so rough that I was amazed.

In my thesis I validate the flamelet solver from alberto too and wanted to make a very fine mesh (200.000 cells) for a 2D case to be very accurate. The resolution of the simulation was like the residuals mentioned at the 8th post. After I had a look to albertos mesh (~45.000, I think), it was clear. And additionally I wrote out every 10th timestep and could make an animation of the steady-state-transient solution :D

The problem of my mesh was, that I solved local turbulent values that give me a non-converging solution.


What I wanna say is, that many meshes are too fine for RANS modelling. And remind yourself that RANS in turbulent flows is a averaging process with turbulence "modelling".


Correct me if I am wrong
Tobi

Hi Tobi,

I think I get what you are saying, however when I look at the size of the problem I struggle to think that a much lower number of cells could come up with a reasonable representation of the problem.
For example the blockmesh region is 20m x 8m x 4m I believe the lowest resolution that'd be meaningful in the space is a 0.1m cube so that's how I've broken it down in blockmesh, this makes 640,000 cells before refinement has even started on the shape.

The shape itself being a car is quite complex and has features that need to be reasonably represented that are down at mm scale, hence there's a lot of cells created.

Looking at the results I'm now getting they correlate reasonably with real word examples I have, when I make changes in the shapes being tested I get what I think are reasonable reactions in the results produced.

So whilst you may well be correct I'm at a bit of a loss as to what I would do differently?

Hi,

I saw your picture with your car and yes you have to be accurate on the shapes. You can compare the motorbike tutorial ... I made eyes as I saw that big starting mesh. Okay I never solved that case but I think it should work.

For the rest - I dont understand your last question!

Hi Tobi,

thank you for that very interesting post. Let's say, I am working on a low-Re case with the k-omega SST turbulence model. I try to get y+ below zero and aim for a expansion ratio of more or less 1.2. It seems to me my mesh is more or less fixed than. Of course I have to do studies for mesh independency and so on...
Are you only referring to high-Re modeling or what am I getting wrong here?
Moreover, it seems to be logical to me that you get a non-constant solution wherever turbulence is involved (Though it is a bit contrary to the RANS idea.)

I'd be very glad if you could explain this a bit more.

Kate