Mesh error cgns

[JuanUribe]

Hi Yvan,

I'm chipping in since I helped Kristin install Code_Saturne in her machine.

On my machine I have also the same problem as Kristin with the test.cgns mesh.

With version 2.0.5 I get an error but with version 2.2 it works. What is more intriguing is that both were compiled with the same cgns library (3.1.3-2).
I also get errors by doing a cgnscheck on the mesh.
I'm attaching a zip file all log files as follows:

install_saturne_2.2.log (installation log)
install_saturne_2.0.5.log
cgnscheck.log (log of the cgsncheck command)
preprocessor_2.2.log
preprocessor_2.0.5.log
ldd_cs_preprocess_2.2 (output of ldd cs_preprocessor)
ldd_cs_preprocess_2.0.5

I don't really know what could be the problem. Maybe is the cgns installation?

Cheers

Juan

[knewlands]

Hello,

Yvan, you are correct, the version of the GUI is 2.0.0-rc1.

Juan, thank you for all your efforts, I hope we can eventually get to the bottom of this.

Kind regards,

Kristin

[JuanUribe]

Hi Kristin,

I was able to open your project file in ICEM 13.
I saved it as cgns (see screen-shot attached) and the ran the adf2hdf command on the cgns mesh.
After that the preprocessor worked without any problem.

But running adf2hdf on your test.cgns and then cs_preprocess still gives me an error.

I know you saved the test.cgns from ICEM 14, so I was wondering if in there you have more options than the ones shown in the screenshot attached. Maybe cgns v3.0 instead on 3.1?

Cheers

Juan

[Yvan Fournier]

Hello,

I do not believe the initial problem is with the CGNS installation, but with one of the scripts, which would call components of the 2.0-rc1 version installed under "/usr" instead of its own components (normally, paths are sourced with added paths first, so this behavior is surprising, an I did not find where there may have been an error yet, but this can be solved by removing the version 2.0.0-rc1 from /usr (there would be no issue if it were installed "side-by-side" with other versions, instead of a system directory).

In Juan's log, the error related to preprocessor 2.0.2 is now different. I did not reproduce it directly here, but when I run both Preprocessor versions under Valgrind, I do have an issue with version 2.0, and none with 2.2.

Looking further, revision 2480 (in the Code_Saturne trunk) adds a change with the following comment:

Allow reading of CGNS files with BC's referring non-existant edges, as a workaround for a bug in ICEM CFD 13 CGNS export.

Let me guess. Which meshing tool did you use ?

This "fix" is not available in Preprocessor version 2.0.2. You can apply it in the "ecs-2.0.2" source directory with the attached file running:
patch -p 1 < ecs_2.0_icem_cgns.diff
and it makes the Valgrind error dissapear on my side, so your crash should go away also.

I might fix this in a future release of Code_Saturne 2.0 (that would lead to a preprocessor version 2.0.3), but note that the root cause of all this is a bug in ICEM, which does not output edges in the CGNS files, but outputs groups referring to those edges. This is easy to check using cgnsview, and you can also "fix" it with this tool, by selecting "BC1_on_SOLID_1_1" under BASE#1/project3.uns/ZoneBC, and selecting "delete" with the right button (then saving your changes). Note that the other BC's before that refer to you existing face groups, and the ElementList of BC1_on_SOLID_1_1 refers to non-existing element numbers...

I would actually prefer that people fix the mesh using cgnsview rather than needing a patch in Code_Saturne, as it would remind them that the bug is in ICEM, and that we do not normally need to "fix" the Code_Saturne CGNS reader, but applying a patch makes life easier.

Best regards,

Yvan

[Yvan Fournier]

Hello,

I was typing my post at the same time as Juan's, and I can now see that you are using ICEM 14, while we detected it with ICEM 13. This means they still have the bug (I do not know how to file a bug with them, and they made such a mess of CGNS support the last 3 ICEM versions that I would be tempted to try POINTWISE or CENTAUR instead, if only I had the time...).

Best regards,

Yvan

[JuanUribe]

Hi,

Thanks Yvan, deleting the node on with cgnsview works for me.

The other option is to export from ICEM to Fluent and use Fluent to write the cgns file.
That works as well (and there is no aditional node under ZoneBC) , so definitely is a problem with ICEM's cgns writer.

Cheers

Juan

[knewlands]

Hello,

Thank you for your replies, at least now it's clear that the origin of the problem lies with ICEM's cgns output.

On my part, I have changed the path in my .bashrc file and now I'm finally using Code_Saturne v2.0.5 with the correct gui. Also, when I check my mesh in Code_Saturne, it's using ECS 2.0.2 and CGNS 3.1.3, so that's progress.

This means that I no longer get the previous mesh errors. However, I still have some confusion and I have attached various attempts in the hope that the best approach at saving and loading the mesh transpires.

- Saving the mesh in Icem as .msh and exporting it as cgns from Fluent seems to work (it even worked before I updated the path, with cgns 2.5.4). When I check the mesh in cgnsview I do get 3 warnings though. In the attached folder the relevant files are "test_w2.cgns", "preproc_log_testfluent" and "test_w2.txt".

- I applied the patch in the ecs-2.0.2 source directory (it said "patching file pre-post/ecs_pre_cgns.c", so I think it worked?). However, if I don't fix the mesh in cgnsview by deleting BC1_on_SOLID_1_1, I get the warning "There is/are 1 isolated face(s)" (Ln124 in "preproc_log_testpatch"), which doesn't appear if I fix the mesh in cgnsview (see preproc_log_testfix). When I check the mesh in cgnsview (test_fix.cgns) I get 12 warnings and 2 errors though (see "test_fix.txt").

I did not need to run the adf2hdf conversion this time. In your opinion, do the preprocessor.log files look acceptable now? Have I made an obvious mistake to cause the numerous warnings and errors in cgnsview?

Juan, regarding the cgns output versions I can choose from Icem 14, I can go up to 3.1ADF (which is what test.cgns was saved as). If I save the test mesh as cgns ADF 3.0 I get the error "Error in recorded element connectivity array..." (see "preproc_log_ADF3.0error"). I have also included the cgns mesh (test_ADF3.0_fix.cgns), which gives me the "element connectivity incorrectly defined" error again when I check it in cgnsview.

Apologies for the long post, I would just like to be clear about what cgns input method is more recommended and which warnings/errors can be ignored, if any.

Thank you,

Kristin

[Yvan Fournier]

Hello,

Regarding ADF 3.0 vs ADF 3.1, the element type numbering scheme changed between CGNS 3.0 and 3.1 (if I remember correctly, it was actually changed from 2.5 to 3.0, with a new pyramid variant inserted, and reverted in 3.1, with the new pyramid type moved towards the end of the element type numbers). Normally, differences are handled by CGNS, but since ICEM "cheats" on version numbers while actually writing the same output, the issue with ADF 3.0 is to be expected.
CGNS 3.0 was a beta version, while 3.1 is a "true" version, so you should stick with CGNS3.1 (or ADF 3.1 in ICEM terminology), and forget about 3.0.

Regarding the isolated face, this is a bit surprising, and I am unable to reproduce this (though I recall encountering similar issues at a time). When I run "cs_io_dump --diff" on preprocessor_output files produced both ways, I have no differences (note that I use the cs_io_dump from code_saturne 2.1 or 2.2, as the oen from version 2.0 does not have the --diff option). In any case, cgnsview probably does not try to detect whether a face is isolated or not (as considering this allowed/not allowed is code specific).

Best regards,

Yvan