code-saturne / code_saturne

code_saturne public mirror
https://www.code-saturne.org
GNU General Public License v2.0
218 stars 81 forks source link

Bug for Ensight format import #82

Closed YohannEude closed 3 years ago

YohannEude commented 3 years ago

Hi,

I currently try to use an Ensight mesh with CS 7.1 alpha (from 15 Apr) and I have some problem to keep the groups. So, I did the following tests to try to understand if the problem comes from my mesh (OpenFOAM one) :

Thank you for your help,

Cheers,

Yohann

YvanFournier commented 3 years ago

Hello,

Yes, we can only import mesh groups with the EnSight format when global vertex ids are given. Which is not the case when sub-meshes are exported by code_saturne, due to the way postprocessing is handled. Without those ids, we cannot compare faces in different parts, so cannot import groups (a geometrical option would be posssible but risky in case of thins walls).

The EnSight format is actually designed for post-processing, not mesh input. So the logic for importing groups is a "bonus" using a code_saturne-specific logic, but does not handle all cases.

So to check groups with an OpenFoam mesh, another solution is needed. I would recommend first trying to visualize it under SALOME. The probable cause of the issue is the faces with groups do not use the same vertex ids and are thus "isolated faces". The run_solver.log file should warn you about this and the "mesh check mode" of code_saturne places those faces in a separate EnSight part.

If this is the case, you can try to merge vertices under SALOME. Another last-resort option is to use and adapt the user-defined function example from cs_user_mesh-groups_from_free_faces.c, which will use mesh location and interpolation to project the groups from isolated faces on the actual mesh faces.

If this is not the case, check if the group names appear in the preprocessor.log or are already lost at that stage.