Periodic Boundary Conditions and CGNS

[AndrewH]

Hello,

I have a question regarding periodic boundary conditions. I'm trying to run a simulation of an airfoil using mesh that I generated in ICEM 15.0 in CGNS format. I import my mesh into Code Saturne and run a quality check on it, but it keeps failing when it does the "bounding-box tree layout: 3D" step. I then recieve "SIGSEGV signal (forbidden memory area access) intercepted!" error. If I don't enforce periodic boundary conditons, I have no problems with the mesh quality check. I ran a simulation before with periodic boundary conditions, although much smaller, and I had no problems. In ICEM, I conduct a mesh check and recieve no error for the periodic conditions. My Code Saturne version 3.3.2. I attached my check_mesh.log file. I can try to upload my mesh file if requested, but it's quite large. Any insight or help is appreciated

A further question related to CGNS formatted mesh, is it preferable to generate the mesh as structured or unstructured?

Thank you,
Andrew

[Yvan Fournier]

Hello,

I recommend exoporting the file as an unstructured file: though the reader may handle both, unstructured is more natural, and can handle boundary conditions at faces, not nodes, which requires less conversion steps.

For the crash, using periodicity incurs a mesh joining step, which is where things crash.
As your mesh is quite large, an things seem to work on smaller meshes, it is not impossible that this is due due 32/64 bit integer issues (I have never seen this happen on meshes smaller than 80 million cells, but periodicity incurrs extra, longer arrays).

A quick test would be to run the check in parallel: do not run it using "check mesh", but using the last section of the GUI, as when running a full computation, but do so in "mesh quality" mode. This allows you to run in parallel. Do tell us if this works or not.

The other solution is to transfer your mesh, which may take some time...

Regards,

Yvan

[AndrewH]

Hello,

I tried conducting the "mesh quality" check in parallel on my desktop, but I recieved "SIGTERM signal (termination) received" error when Code Saturne tries to partition the mesh either with Hilbert or Morton curve. However, I also tried the mesh check on my mesh using a cluster that I had Code Saturne compiled with metis on and everything worked great. I ran my simulation for a few iterations and it seems to work fine.

Also, if I export a mesh using the HDF5 format from ICEM, do I need to change the file extension from .hdf5 to .cgns? Code Saturne won't recognize the .hdf5 even though I compiled it with HDF5 and CGNS libraries, but will recognize it if I change the extension.

Thank you,
Andrew

[Yvan Fournier]

Hello,

I was not aware that ICEM exported HDF5-based CGNS files with an HDF5 extension instead of CGNS (but then again, ICEM have done strange things in the past, such as cheating on the CGNS version number)... The .hdf5 extension is also used by other formats (such as the Salome Platform's study files, an HDF5-based variant of the EnSight gold format, ...) so I am not too keen on having the code automatically assume an HDF5 file is a CGNS file.

Without changing the extension, you have the option of forcing the CGNS type in the GUI (or in the cs_user_scripts.py file if you use that) when specifying your mesh.

It is strange that you get a SIGTERM on your workstation with Morton or Hilbert curve, as this approach is usually more robust (less dependent on the installation) than using (PT-)Scotch or (Par)Metis, though partitioning quality is often slightly lower. Do you have an error_* file in this case ? Or is your mesh perhaps too big to run on a workstation ? (on 2 procs, memory usage due to MPI is slightly higher, so if you mesh barely fits in memory under 1 proc, it may not run under 2 on the same machine/node).

Regards,

Yvan

[AndrewH]

Hello Yvan,

I tried to replicate my error, but ironically I can't get my error to occur again. I attached the error files that I received earlier when I received the error.

Thank you,
Andrew

[Yvan Fournier]

Hello,

Did you run on a different number of MPI ranks than the previous run ? A bug might appear in one case and not the other. I am not sure what the crash is due to, though I recall encountering something similar recently, which I believe/hope is due to some operator not handling unordered elements on entry (occured very rarely, fixed this summer in upcoming 4.0 beta in rev. 6350).

Regards,

Yvan