This is more of a curiosity, but I’m wondering what SimScale is actually doing during mesh validity checks? I ask this because I have noticed from checking the meshing log during mesh generation that the mesh completes fairly quickly and much of the time spent ends up in the opaque validity checks that occur after “Finishing parallel run” in the meshing log. This is often where a mesh fails as well, with very little feedback as to why. It would be wonderful to know a little bit more about what is actually happening during these checks.
Just as a data point from the current mesh I’m working on: log says mesh completed in 480s, total time is 74 min/40 core-hours.
I forwarded this question to our engineers if we have additional background checkings for the parallelization task and if any optimizations for mesh quality are on the roadmap.
Hi @jhartung
very good question indeed. Let me try to shed some light around this topic:
We have observed that the meshing software we are using sometimes creates invalid meshes which cannot be used in a simulation. The most common invalidity in hex-dominant meshing is that the mesh contains a face with 3 cells next to it. This is clearly invalid as it will break many assumptions made by FVM. In order to save our users from proceeding with data which won’t work, we show this error.
Some other checks we do are:
All cells must have strictly positive volume > 0
All faces must have strictly positive area > 0
All boundary faces must have exactly 1 adjacent cell
All internal faces must have exactly 2 adjacent cells
There are more checks but those are only for us to catch other inconsistencies early in the process (so called “contract checks”). They will not be caused by the mesher directly.
Regarding the time spent after meshing: besides the validity check (and a few other things) we also generate the visualization which you see in the 3D viewer inside the workbench after meshing. This takes some time because we need to read in the entire mesh and convert it to a different format. In order to reduce the loading time for our users and to improve the interaction performance, we also run it through an optimization pipeline. This can take some time - however the ratio you reported is very extreme. If you don’t mind, I’d like to take a look. Feel free to share the project with me (or support, which is even easier) and I’ll try to find out what the matter is.
I also want to mention that some massive performance improvements for meshing are in the making. I cannot tell more at this point (sorry!) but I can say that you are going to see some exciting improvements and much faster meshing in the coming weeks. Stay tuned
Hi @jprobst, thanks for the update on this. The project is here. Be warned, it’s a big one with a lot of iterations. I’ve been following the process we’ve discussed in this thread, which is lengthy but worth the read if you’re involved in the meshing algorithm. From having played with it I’m concerned that most of the tutorials and help on the topic of meshing will result in a really bad mesh with almost non-existent boundary layer.
Hi @jhartung thanks for the project! Is the run you mentioned still there or was it deleted? You can also go to the mesh (or the event log) directly and paste the complete link. It’ll help me to find the specific job which had the issue.
I cannot spot the SimScale Staff answer now, but explanation (old of few weeks) was linked to inefficiency of multiprocessing, scaling as n^2. (well, perhaps not as it will go to the sky). I spotted it in first couple of days of using SimScale and understood that I have to set meshing on minimal necessary number of processors.
My last mesh from today simulation (quality checks are not run, as I use momentum sources, the same is with MRF), took 15 min, 2.1 core hours. Log file reports 491 seconds. Mesh is 1.5M cells 1.7M nodes and was run on 8 processors.
Yes I generally see the ‘Finalising parallel run’ message appear in the log, then I go do something else for the Real time minutes it took to get there
@jhartung I checked the mesh you posted. Let me try to explain the discrepancy between the number from the log and how long it actually took:
When a mesh has layers, we actually invoke meshing twice. We have done some experiments and found it to work better some time ago. This leads to the fact that the time reported in the log is not the full truth but only the time spent on layer generation. The meshing prior to this takes about 6.5 minutes. The layer generation takes about 3 minutes (consistent with the log).
In addition to that, there is some overhead. @Retsam mentioned that the parallel reconstruction may take a considerable amount of time. In your case it took about 10 minutes. The rest of the time goes into CAD operations, quality checks, visualization, data conversion, data transfer and other steps.
