"model contains faults" in standard but not in hex-dominant

Project Support
1

Design objective:
design of a fairing for a motorbike.The engine is air cooled I have to ensure that the airflow around the engine is still useful especially at low speed (~50kph).
Aerodinamic effects on vehicle dynamics are of no interest in this study, only the impact on the fairings on the airflow around the engine and correct flow evacuation.

3d Model Source:
the model is a STL hand-cleaned and simplified to the bare minimum, simmetry has already been applied and every non-essential element has been redacted from the model. The model is recognised as solid right away in CAD Mode.

Issue:
Standard Mesher returs “The mesh could not start because the model contains faults” with any level of fitness and the Meshing Log is empty.
The same source model has been thoroughly processed with hex-dominant mesher with no similar issues (“Divergence detected” determined two canceled simulation runs but appear unrelated to the problem above).
After asking for assistance in the support chat, I switched back to Standard Mesher but there seems no way to make it process the model.

What do?

Project link:

2

for any deeper inquiry into the project, the issue appears in:
Simulation: monster bellypan v59 edit (airfoil gills)
Source models: monster v59 (extended simmetry) and monster v59
Reference mesh for standard mesher: Mesh 47 standard
Reference mesh for hex-dominant mesher: Mesh 46 hex

3

Hi!

Here are some general comments that come to mind:

  • The standard and hex meshing tools are very different in nature. Standard is a bottom-up unstructured/hybrid meshing tool that first meshes faces, then boundary layers/volume mesh. Hex dominant is a top-down structured meshing tool that first meshes the volume, then faces, and then boundary layers.
  • Overall, standard is better to capture geometry details due to it meshing faces first plus due to it generating tets on faces, however this also means that if your CAD model is not very clean, the standard tool will capture those problematic faces, generating a bad quality mesh.
  • On the other hand, due to the order of cell creation in a hex mesh, they have a natively built-in filtering mechanism for small details. If your geometry has a detail that is smaller than the mesh size, this detail won’t be captured on a mesh level.
  • Since your model is a stl file with a little bit of a blocky tessellation (e.g. like shown below), this type of CAD model is not really made for the standard tool.
    image
    image1228Ă—867 149 KB

    Even for hex meshes this can be a bit tricky due to boundary layers potentially breaking, but hex is still better than standard in this case. In a very general sense, small faces/gaps and detailed topology can make meshing more difficult.

Cheers

4

thanks for the prompt reply.
If I’m not mistaken then, given the limitation of this particular model, it is not be recommended to proceed with Standard mesher, then.
may you confirm that?

[digressing on the project]
the only way forward, seems to simplify the 3dmodel further in the areas that appear prone to produce errors in the simulation stage and re-mesh everything with hex-dominant with the hope that a finer resolution would not generate new divergence.
would this be a feaseble strategy in this particular context?

5

Correct. Unless the model is much cleaner than it currently is, standard will not be a good option IMO.

And yes, that sounds like a possible approach. Optimizing the mesh (refinements, etc) can also help in some cases, but starting out with a cleaner CAD model is always going to be a good idea.

1 Like
6

thank you,
if it leads to a solution, i’ll post a screenshot of the results for future reference.

1 Like
7

Following from the thread:
I simpliefied a couple of details (calipers and conjuntion between the wheel and tire) that appeared problematic in the previous simulations and re-setted from scratch the mesher.
Standard was still useless but Hex-Dominant didn’t had issue at processing. Cells with volume ratio and non-orthogonality out of the acceptable range weren’t 100% avoidable but appeared limited to less 10 instances (on average)
The first mesh was successful but probably too heavy (detail was ~1mm) and the simulation crashed at 2%
After around some attemps of re-balancing the settings for the surface refinement, the simulation was processed with no issues
some results
240722separation
240722velocity

Thanks for the support! I’ll be back on analizing the results and modeling to solve the design issues.

Hope this is useful for future reference.

1 Like