SimScale CAE Forum

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


#1

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


#2

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


#3

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


#4

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 :wink: )

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 :question:

Great diligence here, bravo!


#5

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…


#6

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.


#7

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


#8

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


#9

@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:


#10

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.


#11

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 :frowning:

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 :frowning:

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.


#12

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.


#13

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

Best,

Jousef


#14

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