Monitoring probe question

[iorishx]

Hello, I was trying to put some monitoring probes in my fluid field. But it looks like the probe position has to avoid some specific positions in the flow field, e.g., in my case, if I set a probe position as
"<probe name="1" status="on">
<probe_x>2.00</probe_x>
<probe_y>0.00</probe_y>
<probe_z>0.05</probe_z>
</probe>"

the code will give me an error:

"SIGSEGV signal (forbidden memory area access) intercepted!

Call stack:
1: 0x2aaaaadbdee3 <parhis_+0x43> (libsaturne.so.0)
2: 0x2aaaaae1a7d3 <ecrhis_+0xc93> (libsaturne.so.0)
3: 0x2aaaaad583da <caltri_+0x42ba> (libsaturne.so.0)
4: 0x2aaaaad39792 <cs_run+0x3f2> (libsaturne.so.0)
5: 0x2aaaaad39221 <main+0x111> (libsaturne.so.0)
6: 0x2aaaae9c4c36 <__libc_start_main+0xe6> (libc.so.6)
7: 0x403809 <> (cs_solver)
End of stack

Rank 111 [Tue Feb 16 12:49:09 2016] [c7-0c1s13n0] application called MPI_Abort(MPI_COMM_WORLD, 1) - process 111"

Does this mean in code saturne, there is some limitations for the probe positions? Does anyone know about this?

Sean

[Yvan Fournier]

Hello,

No, this might be a bug.

Which version are you using ? Is your case small enough and non-confidential so that you can post it here ?

Regards,

Yvan

[iorishx]

Hi, the version is 4.0.1. The case is too large but I am happy to post files such as listing or *.log or error. please let me know which file do you need.

Hello,

No, this might be a bug.

Which version are you using ? Is your case small enough and non-confidential so that you can post it here ?

Regards,

Yvan

[Yvan Fournier]

Hello,

According to the backtrace, the error occurs during the parallel syncing of probe data, so it might be partition-dependent, which makes reproducing it without your data quite difficult (and possibly partitioning output file, if you are using Scotch or Metis)...

I recommend upgrading to 4.0.4, which fixes a few bugs (though none of the fixes that appear in the NEWS file or seems relevant to this).

Do you have user subroutines ?

Regards,

Yvan

[iorishx]

Yes, just subroutines for wall shear stress and spanwise efforts calculations. Please see attached. Any suggestions for the probe positions or I have to try them out one by one? It seems that some positions are fine, some are not.

Hello,

According to the backtrace, the error occurs during the parallel syncing of probe data, so it might be partition-dependent, which makes reproducing it without your data quite difficult (and possibly partitioning output file, if you are using Scotch or Metis)...

I recommend upgrading to 4.0.4, which fixes a few bugs (though none of the fixes that appear in the NEWS file or seems relevant to this).

Do you have user subroutines ?

Regards,

Yvan

[Yvan Fournier]

Hello,

I took a quick look at your user subroutines, and did not see anything suspicious, but as an additional precaution, can you check if you reproduce the issue without user subroutines ?

If you still have the issue, running with a debug build of the code (i.e. configured with --enable-debug=true) could help pinpoint the exact line where the crash occurs. Without your case, I might not have a direct fix, but I might be able to get a hint of what is wrong, and send you patches to test.

Regards,

Yvan

[iorishx]

Thanks for getting back to me, Yvan. I think you may have found the problem. The code is running fine without my subroutines, in particular, when I disabled the wall shear stress subroutines. Now the code is running fine. I will update this post if I encounter further questions.

I appreciate your suggestions.

Best regards,
Sean

Hello,

I took a quick look at your user subroutines, and did not see anything suspicious, but as an additional precaution, can you check if you reproduce the issue without user subroutines ?

If you still have the issue, running with a debug build of the code (i.e. configured with --enable-debug=true) could help pinpoint the exact line where the crash occurs. Without your case, I might not have a direct fix, but I might be able to get a hint of what is wrong, and send you patches to test.

Regards,

Yvan

[Yvan Fournier]

Hello,

Good. The next step for debugging would be do add/remove parts of your subroutines to pinpoint the cause of the bug (i.e. doing a bisection to find the bug).

If you have a debug build and Valgrind installed, running under valgrind might help you find the bug faster (assuming the case is small enough "per node" for the overhead of running under Valgrind not to prevent running the case, and that Valgrind doesn't give you too many false positives due to fast network driver code).

Regards,

Yvan