[pnovo]

Dear openfoamers,
I took the dictionary files from the hopper tutorial in the lagrangian tutorial folder and edited them to make a test using the elbow tutorial. First I calculated the U field using the icoFoam solver and then used this solution to calculate particle trajectories using icoUncoupledKinematicParcelFoam. The solution showed results as expected. Then I moved to my case (more complex microfluidic channels), got the U field calculated as well and then tried to use the icoUncoupledKinematicParcelFoam solver using the same configuration files as before but by changing the patch names appropriately. As soon as one particle is injected the solver crashes with the following error:

Evolving kinematicCloud
[0] #0  Foam::error::printStack(Foam::Ostream&)
Solving 3-D cloud kinematicCloud

--> Cloud: kinematicCloud injector: model1
    Added 1 new parcels
[0] #0  Foam::error::printStack(Foam::Ostream&) at ??:?
[0] #1  Foam::sigSegv::sigHandler(int) at ??:?
[0] #2  ? in "/lib/x86_64-linux-gnu/libc.so.6"
[0] #3  Foam::WallLocalSpringSliderDashpot<Foam::CollidingCloud<Foam::KinematicCloud<Foam::Cloud<Foam::CollidingParcel<Foam::KinematicParcel<Foam::particle> > > > > >::nSubCycles() const at ??:?
[0] #4  Foam::PairCollision<Foam::CollidingCloud<Foam::KinematicCloud<Foam::Cloud<Foam::CollidingParcel<Foam::KinematicParcel<Foam::particle> > > > > >::nSubCycles() const at ??:?
[0] #5  ? at ??:?
[0] #6  ? at ??:?
[0] #7  ? at ??:?
[0] #8  ? at ??:?
[0] #9  ? at ??:?
[0] #10  __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
[0] #11  ? at ??:?
[do2-aps-monea:18425] *** Process received signal ***
[do2-aps-monea:18425] Signal: Segmentation fault (11)
[do2-aps-monea:18425] Signal code:  (-6)
[do2-aps-monea:18425] Failing at address: 0x28aa000047f9
[do2-aps-monea:18425] [ 0] /lib/x86_64-linux-gnu/libc.so.6(+0x36d40) [0x7f16bba7ad40]
[do2-aps-monea:18425] [ 1] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x39) [0x7f16bba7acc9]
[do2-aps-monea:18425] [ 2] /lib/x86_64-linux-gnu/libc.so.6(+0x36d40) [0x7f16bba7ad40]
[do2-aps-monea:18425] [ 3] /opt/openfoam240/platforms/linux64GccDPOpt/lib/liblagrangianIntermediate.so(_ZNK4Foam28WallLocalSpringSliderDashpotINS_14CollidingCloudINS_14KinematicCloudINS_5CloudINS_15CollidingParcelINS_15KinematicParcelINS_8particleEEEEEEEEEEEE10nSubCyclesEv+0x1ec) [0x7f16c107355c]
[do2-aps-monea:18425] [ 4] /opt/openfoam240/platforms/linux64GccDPOpt/lib/liblagrangianIntermediate.so(_ZNK4Foam13PairCollisionINS_14CollidingCloudINS_14KinematicCloudINS_5CloudINS_15CollidingParcelINS_15KinematicParcelINS_8particleEEEEEEEEEEEE10nSubCyclesEv+0x8a) [0x7f16c108066a]
[do2-aps-monea:18425] [ 5] icoUncoupledKinematicParcelFoam() [0x4723a6]
[do2-aps-monea:18425] [ 6] icoUncoupledKinematicParcelFoam() [0x47266c]
[do2-aps-monea:18425] [ 7] icoUncoupledKinematicParcelFoam() [0x473153]
[do2-aps-monea:18425] [ 8] icoUncoupledKinematicParcelFoam() [0x473407]
[do2-aps-monea:18425] [ 9] icoUncoupledKinematicParcelFoam() [0x41fe58]
[do2-aps-monea:18425] [10] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7f16bba65ec5]
[do2-aps-monea:18425] [11] icoUncoupledKinematicParcelFoam() [0x420c6e]
[do2-aps-monea:18425] *** End of error message ***
--------------------------------------------------------------------------
mpirun noticed that process rank 0 with PID 18425 on node do2-aps-monea exited on signal 11 (Segmentation fault).

I ran the case either in parallel or not getting the same results. (The printed code above was for the parallel case).

I have seen in other posts that this error may be related to the lack of ram. However I have plenty of ram available (256 GB) and the case has only about 400 k cells.

Any help or info where to look would be very nice.

[guin]

"WallLocalSpringSliderDashpot" as well as "WallSpringSliderDashpot" seem only to work with patches of type "wall" and not with generic ones of type "patch". Specifying this with blockMesh is a straight-forward task, but "elbow" case uses an imported geometry (-> elbow.msh). My guess is that the "fluentMeshToFoam" utility used for the mesh conversion applies generic patches everywhere.
If still interested in the solution you may use the utility "createPatch" combined with "topoSet"(*) to modify this after the mesh is been converted.

Another possible reason: user given values at the sub-dictionary "wall(Local)SpringSliderDashpotCoeffs". After a while facing this issue I found out that I had a value of 35 for the Poisson coefficient instead of 0.35!

(*) Mmmm... possibly "topoSet" is not required here at all, but I did not test it.