TET meshing is now strongly irregular, but was OK 1 month ago

[Retsam]

I used a lot of TET meshing last couple of months and doing quite interesting simulations with it. They were ‘regular’ like on that example:

---

Simulation "N0012_9.99deg_5.95MR_T2"

Now, the same meshing operation (automatic) gives that very uneven cell aspect:

---

Simulation “N0012_11.15deg_5.95MR_T2”

---

Obviously, something did change in the mesh generation algorithm.

Simulation TetMesh contaminated is now shared with support.

Now, simulation results are quite different (compare Run 3 to Run 2 in Simulation “N0012_11.15deg_5.95MR_T2”). Shape of flow is very different (compare Area averages, Ux, for instance).

Thank you in advance for fixing it.

Retsam

[dlynch]

Hi @Retsam, absolutely something changed and furthermore it is consciously happening. As with everything there is pro’s and con’s. Tetrahedral meshes are still being very actively developed and we quantify every change by testing outcomes of difficult to solve cases. This effect you are seeing, although not obvious has a reason.

To ensure that we are pushing the meshing algorithm further towards a higher overall success rate we look at what we can do to improve mesh quality, automatically. This change actually refines upon cells and regions that have lower quality, it was present before but has been turned up so to speak. Being unstructured on the surface, there is a chance that some areas will have poorer quality and as a con, these areas are refined and produces the artefacts that you see.

So the pro is that you can expect higher quality meshes out of the box the con is that you might see larger meshes and some refinements that visually make no sense but numerically do.

I hope I have explained that well enough but I invite my colleague @jprobst to correct me.

Best,
Darren

[jprobst]

Hi @Retsam
thanks for reporting! This is really an extreme case which I’d like to report to the supplier of our meshing software. Is this fine for you? I would have to send them the CAD file.
The change in behaviour you’re seeing is most likely related to a change we made regarding mesh quality. We found that in many cases the mesh quality in some small areas wasn’t good enough. The change was to ask the mesher to refine more in case the quality metrics aren’t met. Apparently this causes the mesher to refine too much in these areas.
Johannes

[DaleKramer]

Too bad there is no way for me to view which mesh Run 2 and Run 3 use (old or new algo) in sim N0012_11.15deg_5.95MR_T2… (I could figure that out and actually see the meshes if you used only 1 mesh per Simulation )

But in any case, I would say a ~60% difference in Drag Coefficient should cause a lot of concern …

BTW, which mesh gives closer to experimental results

Great diligence here, bravo!

[Retsam]

Dale: old mesh gives consistent results for AoA <= 10 degrees.

Run 2 is with old mesh, Run 3 with new mesh. Same set of parameters was used for those meshes. I was taken by surprise and did not expect any discrepancy in mesh re-generation when tuning one of BLs.

Now, that huge fluctuation in mesh density outside the geometry will impact all my results (I mean for all already simulated AoA of NACA0012). It looks like CD is at least double of original simulations…

[Retsam]

Hi @dlynch and @jprobst: thank you for explanation.

This is indeed an extreme case and variation in mesh density outside the geometry looks like 1 : 3-4. ‘Attractors’ look random and in my opinion, are unexpected side effect of optimisation of TET mesh.

Johannes: you can use my geometries from that project as an example of mesh distortion (to mesh supplier).

Thank you in advance for your help.

[jprobst]

Hi @Retsam
thanks for your reply! We’ll forward the data to the provider.
One thing which caught my eye is that the model is very thin. This may be what forces the mesher to squeeze in elements, distorting them, and then this might be why it refines them in order to meet the quality. The fact that this happens with such irregular “attractors” (good choice of word there) is odd but it could be that it’s just on the verge. Sometimes it tips over the threshold (and then we get an attractor), and sometimes it stays just below it (and we get the normal mesh).
One experiment to try in order to verify this hypothesis is to make the model a bit thicker (say twice), remesh and compare.
Johannes

[Retsam]

Hi @jprobst,

I used that NACA0012 ‘pseudo 2D’ study as an easy to follow example (having good mesh available). But I did notice problem with ‘normal volume’ TET meshes with my Magnus Effect Study, while TET meshing with auto BL and HEX (Simulation ThomCyl_TET+HEX).

Please look at mesh on left / right sides in corners below the ‘plate’ or ‘disk’. Left side is strongly squeezed, right side looks correct.

---

Domain looks better, but you will see the squeeze places on top (but not on bottom of that domain):

---

Anyway thin domain reveals the problem to full extend. I used that mesh helping for best (doing, in mean time, Ahmed body study and Tesla Truck), but now I have to put TET mesh on hold, awaiting the fix.

Thank you,

Retsam

[DaleKramer]

@jprobst

This is really an extreme case which I’d like to report to the supplier of our meshing software. Is this fine for you?

@jprobst, it appears that you have the ear of the meshing software provider. Perhaps you could inquire about how hard it would be to add the following ‘standard’ algorithm meshing parameter which I present here:

A few of us have spent hundreds of hours in the last few months struggling with trying to have projects using the ‘standard’ TET mesher, verify experimental data… We have determined that one of the main issues causing poor verification, is the existence of ‘bad’ cells in our ‘standard’ TET meshes. The issue of this topic also confirms that.

Now I am taking a break from CFD and working on some FEA also using the ‘standard’ mesher.

Since it appears that FEA has similar mesh quality requirements, today I came upon the idea of a ‘standard’ meshing parameter that could really help us zero in on proper mesh settings with minimum time and effort. This parameter would also reduce ‘bad’ cells in our mesh to unheard of low levels at the same time…

Here is the request:

• Instead of (or in addition to) having a ‘Maximum edge length’ parameter, give us a ‘Maximum tetEdgeRatio’ parameter…
  .
  .
  .

Also, for those of us who continually monitor the ‘Meshing log’ to determine how a meshing is proceeding and whether we should cancel that mesh and change a parameter so that we do not waste core hours while trying to determine the needed fineness of our mesh etc… Could you add code, in the SimScale UI, so that on ‘every meshing log screen update’ (which is every minute or two or when the log text actually changes), do this:

1. If the log text has changed, add a timestamp at the end of the last line of the log…
2. On every screen update, edit/add to the UI screen Meshing Log window, a separate timestamp line. This would mean that if log text did not change on a screen update, you would still see the timestamp update (with realtime and core hours if possible).

Here is a fake idea of what the log would look like using those timestamps:

[Retsam]

As ‘standard mesh’ evolves without any warning, I also suggest to put a mesher version in the header of log file. It should reduce our anxiety about source of discrepancies when back to the project with updated mesher.

[DaleKramer]

But please put that Version # at the End of the mesh log since the beginning of the log disappears forever on meshes with many faces

Or better yet save the whole mesh log for us…

I would venture to say that it would be almost a necessity to have the version # in the mesh log in order to debug situations like this… It is fortunate that Retsam stayed organized well enough to discover this issue that appeared ‘out of the blue’ to us in the field so to speak

EDIT: Sorry, even with unlayered 2177 face mesh I did today, the ‘standard’ mesher log file was not truncated, I think this post is only relevant to Hex meshing log files that show only the last 1500 lines.

[Retsam]

Well, TET mesh is still called standard, but unless it is mended, it seems unusable:

I could comment, but you can say yourself: Holly s! what is it? My answer is: I do not know.

[jousefm]

Forwarded the issue Andrzej, one of my colleagues might jump into the discussion to clarify some things here.

Best,

Jousef

[jprobst]

Hi guys, thanks for reporting.

We’re still on it (as a matter of fact - right now). We understand the issue and we can assure you that this is generally harmless: it’s not a bug in the mesher and it should also not impact the results negatively (but please read the caveat below).

What’s happening here is the following:
Because we want good meshes, we are applying relatively strict quality criteria. The mesher is configured so that it refines the mesh in areas where it cannot meet the quality criteria of the mesh. This is what causes the refinements in the first place.

Generally, the meshes with the refinement have better quality than without. However, they also have more cells - and sometimes they have more cells than needed. This is problem number 1.

Problem number 2 is that the variance in mesh fineness also affects the condition of the matrix in the simulation. This means that the behaviour of the solver changes (the meaning of the residuals change) and this is possibly the cause for different results, at least if the simulations aren’t fully converged.

If you observe differences in results, one thing to look out for is to ensure that the result is actually converged. Residuals are one way to check that, however I strongly recommend to use result control items (e.g. probe points, or forces) to judge whether or not a result is converged.

We’re right now working on an improvement for the situation. Probably we will go back to less strict quality metrics, which means that mesh quality will become slightly worse again (and again, that’s not an accident, or a bug, but a conscious design choice motivated by a trade-off between mesh size and quality).

In the meantime - sorry for the inconvenience, guys. We really didn’t want to break things for you.

Johannes

[jprobst]

Hi guys
we have just released a fix for this problem. I hope we managed to improve the situation a bit. Please let us know if it helps in your cases, or if it makes anything else worse.
Thanks for reporting this and sorry that it took so long - we had a lot going on recently.
We’re committed to providing you with a tool that just works, and your feedback has been always very helpful. Keep it up!
Johannes

[Retsam]

Hi @jprobst: Thank you for providing a possible fix to standard mesh random skewness. I immediately tried it on my NACA0012 simulations (angle 11.15 > N0012_11.15deg_5.95MR_T2). I see now, that mesh is indeed not skewed randomly and resembles meshes I created on end of 2019.

However, keeping all parameters the same for simulations (Run 2 and Run 4 can be campared), gives following differencies:

Run 2 (mesh from 2019)
forces forces1 output:
sum of forces:
pressure : (1.10111025524 0.000398966314668 107.949038339)
viscous : (0.220256463195 -5.08671774776e-05 -0.0308278300759)
porous : (0 0 0)
sum of moments:
pressure : (0.863304918945 -0.181507031234 -0.00919426096133)
viscous : (-0.000282952642919 -0.000987897236667 -0.00171935167925)
porous : (0 0 0)
forceCoeffs forceCoeffs2 output:
Cm = -0.00210282921267
Cd = 0.0152256753623
Cl = 1.24350614857
Cl(f) = 0.619650245072
Cl(r) = 0.623855903497


Run 4 (fixed mesh 2020)
forces forces1 output:
sum of forces:
pressure : (1.98800188859 0.000284227679948 106.485766884)
viscous : (0.202973864501 -0.000768985824991 -0.0336274084459)
porous : (0 0 0)
sum of moments:
pressure : (0.851998340265 -0.172460051419 -0.0160815259606)
viscous : (-0.000276639806955 -0.00384372444654 -0.00161970838745)
porous : (0 0 0)
forceCoeffs forceCoeffs2 output:
Cm = -0.00203149059155
Cd = 0.0252458950857
Cl = 1.22661309285
Cl(f) = 0.611275055833
Cl(r) = 0.615338037016


---

That difference in drag forces / coefficients is very important and would mean that my results for AoA of NACA0012 <= 10 I crafted with ‘precision’ will be not reproducible, as drag can be bigger by > 60%.

Here is the link to NACA0012 study I did: NACA0012 airfoil study using standard mesh.

Cheers,

Retsam

[jprobst]

Hi @Retsam
thanks for trying it again so quickly! I’m glad that the mesh is more regular now.
I just took a look to check why you’re getting so different drag values now. I have checked the setup and the results. One thing I noted is the appearance of the boundary layer.

I would recommend to try with more layers (4-8). The y+ values should be outside of the range between 5 and 30 (i.e. avoid the buffer layer) to allow the wall functions to work properly. It seems to be satisfied in most of the surface of airfoil. Another thing which could be worth a try is to use a low-Reynolds grid where all y+ values are below 5 (as low as 0.1 for a true full resolution of the boundary layer) on the entire airfoil.
I hope this will give more consistent results.
Johannes

[Retsam]

Hi @jprobst

Thank you for offering your (well, standard) recommendation about meshing. I followed them for first ~9 months with SimScale, but being asked to check how well new ‘standard’ mesh (TET) behaves, I joined @DaleKramer and @Ricardopg on a separate channel (RocketChat), were we spent hundreds of simulation hours trying to match, to some extend, NACA0012 experimental data from NASA, and using TET and HEX meshes.

My objective was to make kind of ‘essential’ setup with smallest possible domain and minimal number of tweaks from Numerics.

While meshing for Full Resolution (y+1) I tested up to 64 BLs: even if Lift coefficient was in line with experimental one for many AoA, Drag coefficient was never approaching any. Convergence was steady or near ideal for those simulations.

While meshing for Wall Function (k-omega-STT) (y+30) I tested many layers, but found out, that Drag Coefficient is getting better and better when reducing the number of BLs and allowing Wall Function to take care of y+ > 80. I went to study Xfoil 2D meshing approach and with a hind side from pressure gradient study (in Xfoil), applied a ‘patch’ on a part of the airfoil face, allowing to handle high pressure gradients with much denser 1 layer BL.

That way I was able to get the correct results for CD / CL on NACA0012 from 3.97 to 9.99 degrees:

---

---

AoA > 10 degrees were strangely off, surely for a valid reason but I could not, at that moment, find a way to modify my mesh in order to accommodate that ‘change of regime’.

At that moment I jumped to Ahmed body study using TET mesh and my 1 BL layer approach with ‘patches’ for high pressure gradient, with success.

Early this year @DaleKramer did a systematic study of 1 layer BL for HEX mesh and validated that way of applying Wall function.

Summing it up: it is not my poor knowledge of meshing / simulation that can be blamed. We had a ‘strange’ opportunity window last year to validate new TET mesh for CFD and I started to be convinced, that it really can be used on experimental metrics, with minimal setup and without heavy Numeric acrobatics. As a side effect of that new (2020) TET mesh modification, all my studies (NACA0012, Ahmed body, Tesla Trck) are invalidated (nobody could now reproduce those results). I think I will still make NACA0012 public, with explanation about my ‘exploration’ of tools and methods to make CFD simulation better.

For inspiration, I thank @DaleKramer and @Ricardopg for countless hours of discussions (frequently hot), pointers to documentation and tips.

Cheers,

Retsam

[jprobst]

Hi @Retsam
oh no I didn’t mean to blame your knowledge at all. I’m very sorry if it came across that way. What you guys are doing here is really amazing, and I cannot emphasize enough how much you’re helping us by reporting all the problems you find. And if the results are wrong, it’s clearly something we’ve got to improve. Getting the lift and drag right for an airfoil is a very basic CFD problem and SimScale must be able to solve it without any doubt.

I think that the higher angles of attach will be more sensitive to correct behaviour of the turbulence in the boundary layer (especially the flow separation). It would be interesting to see if the turbulence boundary conditions (or the initial conditions, respectively) have any impact for the high-AoA regime.

How far off are the results for the 2019 validation projects?
Johannes

[DaleKramer]

For a single sim run, I believe that Retsam showed the results differences between 2019 meshes and 2020 meshes in this previous post 16 of this topic.

His drag direction is +X and his lift direction is +Z (I believe that is a standard ‘aerodynamics’ axis orientation).

We see that 2020 pressure Drag is ~81% higher than 2019.

We see that 2020 viscous Drag is ~9% lower than 2019.

We see that this results in a 2020 CD that is ~65% higher than 2019.

.
.
.

We see that 2020 pressure Lift is ~1% lower than 2019.

We see that 2020 viscous Lift is ~9% lower than 2019.

We see that this results in a 2020 CL that is ~1% lower than 2019.

.
.
.

It may be interesting to see a 2020 version of the below 2019 chart of Post 18 in this topic, but you may have to run that yourself since we are all back to using HEX meshes now for our external aerodynamic projects.

2019 Meshing Chart: