Error Running a Simulation of a Cylinder

[AndrewH]

Hi,
I'm relatively new user of Code Saturne and I'm having troubles running a simmulation of a simple cylinder. To begin with, I have run a simple case of a rectangular pipe and a channel flow with periodic boundary conditions to test out the code, and everything seems to work well. I then tried to run case with a simple cylinder, however Code Saturne keeps crashing when it gets to the computing stage with the following error:

fvm_selector_postfix.c:1288: Fatal error.

Error parsing expression:
CYLINDER
^
Syntax error, probably due to misplaced operands.


Call stack:
1: 0x7f812ec8200c <+0x23b00c> (libsaturne.so.0)
2: 0x7f812ec82ca7 <+0x23bca7> (libsaturne.so.0)
3: 0x7f812ec85396 <fvm_selector_postfix_create+0x3d6> (libsaturne.so.0)
4: 0x7f812ec7e789 <+0x237789> (libsaturne.so.0)
5: 0x7f812ec80aa9 <fvm_selector_get_list+0x39> (libsaturne.so.0)
6: 0x7f812eec3f1b <cs_gui_get_faces_list+0x8b> (libsaturne.so.0)
7: 0x7f812eecd054 <uiclim_+0x9044> (libsaturne.so.0)
8: 0x7f812ebd8645 <tridim_+0x29ed> (libsaturne.so.0)
9: 0x7f812eab5f34 <caltri_+0x30e0> (libsaturne.so.0)
10: 0x7f812ea96625 <cs_run+0xa35> (libsaturne.so.0)
11: 0x7f812ea95b0a <main+0x14a> (libsaturne.so.0)
12: 0x7f812e48c76d <__libc_start_main+0xed> (libc.so.6)
13: 0x4006b9 <> (cs_solver)
End of stack

I have tried running in both serial and parallel, but I have recieved the same error. I assume it might be something with my mesh since it crashes after it specifies the fluid properties and right before it lists the boundary face information in the listing file. I generated the mesh in ANSYS ICEM v14.0 and outputed in CGNS v3.1 ADF format. However, Code Saturne gives me no errors or warnings when it reads and checks the mesh. I have also remeshed it from scratch and it doesn't seem to help. I'm using Code Saturne v3.3.2, but I have tried v3.0.5 and both encounters the same problem. Any help is greatly appreciated!

Thank you,
Andrew

[Yvan Fournier]

Hello,

Selection criteria are case sensitive: use "cylinder", not "CYLINDER".

Regards,

Yvan

[AndrewH]

Thank you for your response Yvan,

I double checked the case sensitivity and everything seems to be in order, but I still had problems running my case. However, I changed the part name to "WALL," and it fixed my problem.

Thanks,
Andrew

[stefann]

What would it take to start adding concise error codes / descriptions for crashes like these?

[Yvan Fournier]

Hello,

There are normally already some warnings in the "listing" file when selection criteria find no cells or faces (it is only a warning, as this may be legitimate for advanced cases when using a series of meshes with a similar setup). A "high-level" selection function logs this warning, a "low-level" one does not, so depending on which is used where, there might be missing warnings.

What do you call concise ? Definitions vary...

Also, the "listing" provides a summary of group names present in your mesh, and creating postprocessing meshes using the same selection criteria as those used (if using complex criteria) during initial setup may be a good idea.

Also, in the current case, the error was listed as a syntax error, with a "caret" indicating where the syntax went wrong. The syntax for selection is fully detailed in the user documentation. Adding the corresponding page or chapter number in the user documentation to the error message might be possible, but it would make our build system significantly more complex (and it is already not so simple).

Do you have a more specific suggestion regarding error messages ?

Regards,

Yvan

[stefann]

Hello:

My mistake, I didn't read the error message over carefully. I agree in this instance that the error message is fairly clear. Perhaps we can also output also the line number and input file name that caused the error?

Stefan

[Yvan Fournier]

Hello,

With a build in debug mode, on most linux systems, you get exactly that in the backtrace.
In optimized mode, this is not so easy (but in any case, even with partial info, it can provide a quick guess for expert users in many cases, which also allows to to provide some support answers without needing to run everything on our side).

Some error messages also provide a line number in all cases, but the line usually points to the function that handles the error, not to the one which causes the error (harder, as some errors might be due to multiple calls, or missing definitions).

Putting warnings in a separate file would avoid drowning them with the rest, but we would lose the order of those messages relative to the rest, so the net gain might not be so good.

In any case, the log file "clarity" needs a lot of improvement (the idea is to progressively move setup and information to the setup.log and performance.log, and use only detailed info in the log). Some work has started on this, but 95% remains to be done, and it has not had highest priority so far...

Regards,

Yvan