Again about Anason tutorial - Particle Dispersion in a Turbulent Pipe Flow - example files

[pici1251]

Hi to everybody,
I' trying to complete this tutorial, but I'm locked at second step: particles.
For the first step, because I'm not able to write programs in C/C++, I did a different method to add 'special' boundary condition at inlet.
I used a "Norm (User law)" for inlet BC, producing the same law written in tutorial pdf; attached two snapshots.
This 'escamotage' works perfectly.
After I passed to define the particles environment. And here i'm sure i'm going wrong!
I tried to modify the three subroutines indicated in tutorial pdf, cs_user_lagr_particle.c, cs_user_lagr_volume_conditions.c and cs_user_postprocess.c.
After a lot of different attempts, I was able (..maybe..) to indicate the correct Injection Zone (Zone name is Zone_1, whereas MED Group name is Iniezione) in cs_user_lagr_volume_conditions.c. and, in cs_user_postprocess.c , I tried to indicate the four horizontal planes as in .pdf file.
But the result was always the same:

SIGSEGV signal (forbidden memory area access) intercepted!

Call stack:
1: 0x55a9572b8818 <cs_user_lagr_extra_operations+0x78> (cs_solver)
2: 0x7f23f61c0473 <cs_lagr_solve_time_step+0xac3> (libsaturne-6.0.so)
3: 0x7f23f5b18bfb <caltri_+0x2016> (libsaturne-6.0.so)
4: 0x7f23f725677f <cs_run+0x5ef> (libcs_solver-6.0.so)
5: 0x7f23f7256048 <main+0x178> (libcs_solver-6.0.so)
6: 0x7f23f52f8b97 <__libc_start_main+0xe7> (libc.so.6)
7: 0x55a9572b77ba <_start+0x2a> (cs_solver)
End of stack

Now I'm locked and I need your kind help.
Many thanks
Piero

Attached any useful file in second part of my post

[Yvan Fournier]

Hello,

Whether you define the inlet using a mathematical expression in the GUI or a C function should not change anything relative to the issue you describe.

Since you crash is under cs_user_lagr_extra_operations, the most probable cause is an error in that file (it could be upstream, so checking proactively with tools such as Valgrind is always good, but without any additional information, the most logical place to search first is still cs_user_lagr_extra_operations).

So a first step would be to deactivate cs_user_lagr_extra_operations, taking the advantage of the fact it is not needed for the computation, only for extracting additional data.
Adding a "return" at the top of the function is enough for this.

If the code then runs OK, we can continue debugging cs_user_lagr_extra_operations as a second step. I see no obvious error, so I might need to check again, or we may need to run on a debug build, which runs slower but with additional checks, and can help better pinpoint the error.

Best regards,

Yvan