SIGFPE signal (floating point exception) intercepted!

[Stephan Barbe]

Hello,

I'm performing a calculation in code_saturne 2.0.2. I got the following error:

SIGFPE signal (floating point exception) intercepted!

Call stack:
1: 0x2af59055fd3a <redvse_+0x9ca> (libsaturne.so.0)
2: 0x2af59052480d <calgeo_+0x2bd> (libsaturne.so.0)
3: 0x2af5905485c6 <cregeo_+0x82a> (libsaturne.so.0)
4: 0x2af590526a34 <caltri_+0x474> (libsaturne.so.0)
5: 0x2af590506b86 <cs_run+0x856> (libsaturne.so.0)
6: 0x2af590506e5d <main+0x1fd> (libsaturne.so.0)
7: 0x2af593b00436 <__libc_start_main+0xe6> (libc.so.6)
8: 0x40a299 ? (?)
End of stack

I tried to increase the arrays for real and integer memory allocation but it did not help.

Can somebody help me?

Thanks in advance

Stephan

[Yvan Fournier]

Hello,

redvse is the function used to reduce extended neighborhoods for gradients. So changing gradient type (either using simple least squares or full extended gradient) would probably help for this stage, but if you have a division by zero error (the most common cause of the SIGFPE error), chances are there is an issue with your mesh quality.

You may want to try the calculation (or at least the quality criteria) in single-processor mode to see if you have more info in the listing file. I would recommend the mesh quality criteria check in any case, as there is probably an issue with the mesh.

If things work well in single-processor mode, then there might be a bug in the code, so your mesh would be interesting. If you have the same error, then the cumprit is probably the mesh)...

Best regards,

  Yvan

[Stephan Barbe]

Thanks Yvan,

Indeed, I checked the mesh quality and I found some problems due to wrong junctions between the meshes. I improved the the junction by changing the corresponding parameters and it works now.

Best regards

Stephan

Previously Yvan Fournier wrote:

Hello,

redvse is the function used to reduce extended neighborhoods for gradients. So changing gradient type (either using simple least squares or full extended gradient) would probably help for this stage, but if you have a division by zero error (the most common cause of the SIGFPE error), chances are there is an issue with your mesh quality.

You may want to try the calculation (or at least the quality criteria) in single-processor mode to see if you have more info in the listing file. I would recommend the mesh quality criteria check in any case, as there is probably an issue with the mesh.

If things work well in single-processor mode, then there might be a bug in the code, so your mesh would be interesting. If you have the same error, then the cumprit is probably the mesh)...

Best regards,

  Yvan