CGNS mesh not processing fully

[saintlyknighted]

Hello,

I'm just starting out in using Code_Saturne, and I'm currently using Star-CCM+ to generate my mesh which would then be exported in the CGNS format and imported into Code_Saturne. The mesh seems to be imported successfully, but mid-way through processing it throws up a "SIGSEGV signal (access to forbidden memory area) intercepted" error (as in the preprocessor.log attached). Have no idea what this means so I figured I'd ask here for some advice, whether I might need any other steps in order to get it to work.

The Code_Saturne version that I'm using now is 7.0.4, and I'm running it on Windows Subsystem for Linux. To the best of my knowledge I've installed the HDF5, CGNS and MED packages successfully (edited the setup file after running the install_saturne.py script once).

Thanks!

[Yvan Fournier]

Hello,

This looks like a bug, or at least a robustness issue.

Could you post a small mesh exhibiting this behavior, or send one through a file sharing tool if larger than a few Mb ?

Best regards,

Yvan

[saintlyknighted]

Here's the link to the mesh file: https://www.dropbox.com/s/ft682h58oi0pv ... .cgns?dl=0

The mesh itself is fairly coarse, and the file is what I obtained by exporting the mesh data from Star-CCM+. I might try generating some other mesh tomorrow and importing it to see if the bug is replicated - honestly did not think of doing that yet.

Appreciate the help.

[Yvan Fournier]

Hello,

I can reproduce the issue all CGNS library versions I tested with (3.4, 4.3, 4.4).

Using a debug version of CGNS, I can get an idea of where the issue lies, but it seem a CGNS call does not read some data.

Using CGNS's own "cgnscheck" utility, I also have a segmentation fault when trying to check the mesh (independently of code_saturne.

I have test cases exported from older Star-CCM+ versions (12.02.011) which read just fine. Are there any export combinations you could try ?

In an older working example, under the "cgnsview" utility, the ElementStartOffset array is not present.

This seems related to changes in CGNS:

- Prior to version 3.4, CGNS stored polygonal faces in a single list, with for each face : {number of vertices, <list of vertices>}
This was really not a smart choice, as this means elements must be read sequentially.
- In version 3.4.0, CGNS finally replaced this with an indexed approach, with a separate index, and list of faces (like CSR storage for matrixes).
- In version 3.4.1, they realized this broke forward compatibility, so reverted to the 3.3 and older behavior, and moved the indexed version to CGNS 4.0 (the major release number allowing an incompatible change).
- After a few glitches upt to CGNS 4.2, CGNS versions 4.3 and 4.4 do the sensible thing (or almost; I do not know why they force full face-based polyhedral connectivity as soon as a single cell is of polyhedral type, except to make things complicated again. I guess it takes a full committee to expect others to do the thinking...).

So in conclusion :
- CGNS 3.4.0 is THE CGNS library version to avoid.
CGNS 3.4.1 should also be avoided, as some tools just check for "3.4" and ignore the differences between the two...
- It seems Star-CCM developers chose to use that version in Star-CCM 2022, using CGNS 3.4.1 behavior but indicating only "3.4" in the file. They were either out of their minds or trying to give others a hard time... CGNS 4.3 was already available and would have been a much saner choice... Unless perhaps they let you choose the CGNS output version when exporting the mesh ?

I'll see if I can add tests to detect/work around this, but a simple workaround on you side is to open the file using CGNS's "cgnsview" utility, and simply change the library version info from 3.4 to 3.3. (If Star-CCM+ cheats you, cheat it back....)
With this simple edit, code_saturne (and reference CGNS tools such as CGNS check) should read it just fine.

Best regards,

Yvan

[saintlyknighted]

Changing the CGNS version to 3.3 on cgnsview works, thanks Yvan! Unfortunately Star-CCM+ doesn't appear to have an option of exporting its meshes in a different CGNS version, I'm guessing they simply didn't update their version of CGNS to be exported because it just wasn't on their list of priorities.

[Yvan Fournier]

Hello,

I have added a workaround for this issue so that code_saturne can work with both CGNS polygon/polyhdra structure representations, so things should now work even without changing the CGNS version number. This works on your test case and a few others.

The change is pushed to the master branch, but I'd prefer to wait for a bit more feedback before pushing it to the v8.0 and v7.0 branches.

Best regards,

Yvan