problem of identification of boundaries when using CGNS mesh

[hpascalj]

Hello all of you members

I am trying to perform Saturne runs based on CGNS meshes produced by ICEM-CFD.

For any generated block (called Zone while using the Saturne pre-processor), the 6 boundaries (indicated into the CGNS mesh) are automatically recognized : perfect.

But there is a matter (at least, when exercizing as I did) :
for the sake of clarity in this problem report, let's consider only one Zone and a given type of boundary, for instance "BCWall" : so, if several of the previously mentionned 6 boundaries are of this type, the group of boundary_faces which will be retained in the sequel is related to ONLY THE LAST read of the 6 boundaries of the type "BCWall" ; and this is particularly ennoying afterwards for setting the Wall Boundary Conditions , although it might be possible but likely cumbersome to create/add groups of boundary_faces with the pre-processor to circumvente the difficulty (I think about using the option "--grp-fac zone", but up to now, my trials did not bring me satisfaction).

If you know a good practice to avoid that matter , please let me know it (unless it may be a bug)
Thanks in advance for your attention and help

Henri PJ

[Yohann Eude]

Hello Henri,

If I well understood your problem, when you export your mesh from ICEM you have only one name (or name-group) for all boundaries. You can try simply to give a different name for each boundary in order to impose separate boundary conditions in code_saturne.
Did I answer your question?

[Yvan Fournier]

Hello,

Referring to the first post, I am not sure what you mean by "sequel". I did not re-run your case, but Code_Saturne seems to merge groups with the same name from both blocks correctly when I compare the matching information in the proprocesor*.log and listing files.

Are you using the "mesh_output" file for following computations, or using the CGNS files from the postprocessing output ? For postprocessing, group information support depends on the output format: it is maintained for the MED format, it is "extracted" in preprocessing mode only for the EnSight gold format (by generating additional parts), and it is ignored for CGNS output.

So basically, CGNS files produced by Code_Saturne do not contain boundary condition information.

Adding that information in the src/fvm/fvm_to_cgns.c would be possible, but is more complicated than for MED (data is stored as "lists" instead of a "family" tag, and partial writes are not available for boundary condition data, combining to make things more complex for IO from distributed parallel data), and we almost never use CGNS for postprocessing (as EnSight gold, ParaView, and VisIt all read EnSight gold format files, and CGNS read support was buggy in EnSight a few years ago, is not built by default in ParaView, and most tools, even the cgnsviewer from CGNS did not support polygonal faces until very recently, or still do not support it).

Regards,

Yvan

[hpascalj]

Hi everybody

Regarding the issue of getting ONLY A SUBSET of BCs while loading a CGNS mesh ,
I have fixed it now.

The reason of such a not satisfactory behaviour is originated from the saving of the mesh generated with ICEM CFD .
Therefore, if one uses ICEM CFD to produce the mesh, the solution to avoid the previously mentionned issue is simply
to select the option "BCType" and not the other ones :
doing so, things work pretty well as expected.

Henri