[ansubru]

Good day fellow foamers!!

I had posted in this forum earlier, and about the same issue I am going to report now.

http://www.cfd-online.com/Forums/ope...nadequacy.html

I have been trying to simulate "Specific gravity aided separation of grains" on a vibrating table. I have just began my work and started with setting up a very simple case of a fluidized system i.e a rectangular box being filled with spherical grains from the top and fluidized slightly from the bottom (quite similar to the Goldschmidt tutorial case).

I believed that the error had been fixed when I re-checked and corrected my set-up and that was definitely true. I was successfully able to parallelize and simulate my set-up for up to 5500 particles.

However, when I re-run the same test case (duplicated all the requisite files) in parallel with a reduced number of particles (only 200 to reduce computation time), the simulation crashes after a run time of 0.023 sec. This is the same simulation which run for almost 3 secs the last time I ran it. I have no logical idea as to why this is happening.. This is the stack trace of my case (OF 2.3.0 64-bit Ubuntu 12.04 LTS debug mode)

Evolving kinematicCloud

Solving 3-D cloud kinematicCloud
    489 move-collide subCycles
Cloud: kinematicCloud
    Current number of parcels       = 200
    Current mass in system          = 0.00211618
    Linear momentum                 = (0.0211626 0.00478364 0.00267929)
   |Linear momentum|                = 0.0218613
    Linear kinetic energy           = 2.92399
    model1:
        number of parcels added     = 200
        mass introduced             = 0.00211618
    Parcels absorbed into film      = 0
    New film detached parcels       = 0
    Parcel fate (number, mass)      : patch top
      - escape                      = 0, 0
      - stick                       = 0, 0
    Parcel fate (number, mass)      : patch bottom
      - escape                      = 0, 0
      - stick                       = 0, 0
    Parcel fate (number, mass)      : patch walls
      - escape                      = 0, 0
      - stick                       = 0, 0
    Parcel fate (number, mass)      : patch frontAndBack
      - escape                      = 0, 0
      - stick                       = 0, 0
    Rotational kinetic energy       = 0.135396

smoothSolver:  Solving for U.airx, Initial residual = 0.672366, Final residual = 7.73413e-06, No Iterations 34
smoothSolver:  Solving for U.airy, Initial residual = 0.67905, Final residual = 8.42677e-06, No Iterations 37
smoothSolver:  Solving for U.airz, Initial residual = 0.566016, Final residual = 8.79127e-06, No Iterations 33
GAMG:  Solving for p, Initial residual = 0.426701, Final residual = 0.00386942, No Iterations 7
time step continuity errors : sum local = 1.30166, global = -0.0290894, cumulative = -0.249577
GAMG:  Solving for p, Initial residual = 0.177388, Final residual = 7.62761e-07, No Iterations 22
time step continuity errors : sum local = 0.000521, global = 5.96277e-05, cumulative = -0.249517
ExecutionTime = 138.63 s  ClockTime = 138 s

Courant Number mean: 596.86 max: 5746.98
Time = 0.023

Evolving kinematicCloud

Solving 3-D cloud kinematicCloud
    478 move-collide subCycles
[2] #0  Foam::error::printStack(Foam::Ostream&) at ~/OpenFOAM/OpenFOAM-2.3.0/src/OSspecific/POSIX/printStack.C:221
[2] #1  Foam::sigFpe::sigHandler(int) at ~/OpenFOAM/OpenFOAM-2.3.0/src/OSspecific/POSIX/signals/sigFpe.C:108
[2] #2   in "/lib/x86_64-linux-gnu/libc.so.6"
[2] #3  Foam::divideOp3<double, double, double>::operator()(double const&, double const&) const at ~/OpenFOAM/OpenFOAM-2.3.0/src/OpenFOAM/lnInclude/ops.H:167
[2] #4  void VectorSpaceOps<3, 0>::opVS<Foam::Vector<double>, Foam::VectorSpace<Foam::Vector<double>, double, 3>, double, Foam::divideOp3<double, double, double> >(Foam::Vector<double>&, Foam::VectorSpace<Foam::Vector<double>, double, 3> const&, double const&, Foam::divideOp3<double, double, double>) at ~/OpenFOAM/OpenFOAM-2.3.0/src/OpenFOAM/lnInclude/VectorSpaceM.H:34
[2] #5  Foam::Vector<double> Foam::operator/<Foam::Vector<double>, double, 3>(Foam::VectorSpace<Foam::Vector<double>, double, 3> const&, double) at ~/OpenFOAM/OpenFOAM-2.3.0/src/OpenFOAM/lnInclude/VectorSpaceI.H:587
[2] #6  Foam::PairCollision<Foam::CollidingCloud<Foam::KinematicCloud<Foam::Cloud<Foam::CollidingParcel<Foam::KinematicParcel<Foam::particle> > > > > >::wallInteraction() at ~/OpenFOAM/OpenFOAM-2.3.0/src/lagrangian/intermediate/lnInclude/PairCollision.C:249
[2] #7  Foam::PairCollision<Foam::CollidingCloud<Foam::KinematicCloud<Foam::Cloud<Foam::CollidingParcel<Foam::KinematicParcel<Foam::particle> > > > > >::collide() at ~/OpenFOAM/OpenFOAM-2.3.0/src/lagrangian/intermediate/lnInclude/PairCollision.C:671
[2] #8  
[2]  at ~/OpenFOAM/OpenFOAM-2.3.0/src/lagrangian/intermediate/lnInclude/CollidingCloud.C:66
[2] #9  
[2]  at ~/OpenFOAM/OpenFOAM-2.3.0/src/lagrangian/intermediate/lnInclude/CollidingCloud.C:224
[2] #10  
[2]  at ~/OpenFOAM/OpenFOAM-2.3.0/src/lagrangian/intermediate/lnInclude/KinematicCloud.C:204
[2] #11  
[2]  at ~/OpenFOAM/OpenFOAM-2.3.0/src/lagrangian/intermediate/lnInclude/KinematicCloud.C:112
[2] #12  
[2]  at ~/OpenFOAM/OpenFOAM-2.3.0/src/lagrangian/intermediate/lnInclude/CollidingCloud.C:197
[2] #13  
[2]  at ~/OpenFOAM/ask-2.3.0/Solvers/DPMFoam_mod/DPMFoam_mod.C:85
[2] #14  __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
[2] #15  
[2]  in "/home/ask/OpenFOAM/ask-2.3.0/platforms/linux64GccDPDebug/bin/DPMFoam_mod"
[ask-HP-Z230-Tower-Workstation:03979] *** Process received signal ***
[ask-HP-Z230-Tower-Workstation:03979] Signal: Floating point exception (8)
[ask-HP-Z230-Tower-Workstation:03979] Signal code:  (-6)
[ask-HP-Z230-Tower-Workstation:03979] Failing at address: 0x3e800000f8b
[ask-HP-Z230-Tower-Workstation:03979] [ 0] /lib/x86_64-linux-gnu/libc.so.6(+0x364a0) [0x7f8fce3544a0]
[ask-HP-Z230-Tower-Workstation:03979] [ 1] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35) [0x7f8fce354425]
[ask-HP-Z230-Tower-Workstation:03979] [ 2] /home/ask/OpenFOAM/OpenFOAM-2.3.0/platforms/linux64GccDPDebug/lib/libOpenFOAM.so(_ZN4Foam6sigFpe10sigHandlerEi+0xbc) [0x7f8fcf81a7d0]
[ask-HP-Z230-Tower-Workstation:03979] [ 3] /lib/x86_64-linux-gnu/libc.so.6(+0x364a0) [0x7f8fce3544a0]
[ask-HP-Z230-Tower-Workstation:03979] [ 4] DPMFoam_mod(_ZNK4Foam9divideOp3IdddEclERKdS3_+0x20) [0x4c2624]
[ask-HP-Z230-Tower-Workstation:03979] [ 5] DPMFoam_mod(_ZN14VectorSpaceOpsILi3ELi0EE4opVSIN4Foam6VectorIdEENS2_11VectorSpaceIS4_dLi3EEEdNS2_9divideOp3IdddEEEEvRT_RKT0_RKT1_T2_+0x29) [0x4abac7]
[ask-HP-Z230-Tower-Workstation:03979] [ 6] DPMFoam_mod(_ZN4FoamdvINS_6VectorIdEEdLi3EEET_RKNS_11VectorSpaceIS3_T0_XT1_EEEd+0x3c) [0x49cc75]
[ask-HP-Z230-Tower-Workstation:03979] [ 7] /home/ask/OpenFOAM/OpenFOAM-2.3.0/platforms/linux64GccDPDebug/lib/liblagrangianIntermediate.so(_ZN4Foam13PairCollisionINS_14CollidingCloudINS_14KinematicCloudINS_5CloudINS_15CollidingParcelINS_15KinematicParcelINS_8particleEEEEEEEEEEEE15wallInteractionEv+0x3f6) [0x7f8fd28f6ea4]
[ask-HP-Z230-Tower-Workstation:03979] [ 8] /home/ask/OpenFOAM/OpenFOAM-2.3.0/platforms/linux64GccDPDebug/lib/liblagrangianIntermediate.so(_ZN4Foam13PairCollisionINS_14CollidingCloudINS_14KinematicCloudINS_5CloudINS_15CollidingParcelINS_15KinematicParcelINS_8particleEEEEEEEEEEEE7collideEv+0x30) [0x7f8fd28e644a]
[ask-HP-Z230-Tower-Workstation:03979] [ 9] DPMFoam_mod() [0x4f69e6]
[ask-HP-Z230-Tower-Workstation:03979] [10] DPMFoam_mod() [0x4e1b81]
[ask-HP-Z230-Tower-Workstation:03979] [11] DPMFoam_mod() [0x4cc701]
[ask-HP-Z230-Tower-Workstation:03979] [12] DPMFoam_mod() [0x4b6dd4]
[ask-HP-Z230-Tower-Workstation:03979] [13] DPMFoam_mod() [0x4a388e]
[ask-HP-Z230-Tower-Workstation:03979] [14] DPMFoam_mod() [0x493a8d]
[ask-HP-Z230-Tower-Workstation:03979] [15] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed) [0x7f8fce33f76d]
[ask-HP-Z230-Tower-Workstation:03979] [16] DPMFoam_mod() [0x492239]
[ask-HP-Z230-Tower-Workstation:03979] *** End of error message ***
--------------------------------------------------------------------------
mpirun noticed that process rank 2 with PID 3979 on node ask-HP-Z230-Tower-Workstation exited on signal 8 (Floating point exception).
--------------------------------------------------------------------------

Well with my very basic knowledge of OF debugging, I guess #3 is the main cause for this crash, there is one variable in the code which is wrongly estimated as zero or is imaginary. have no idea how to identify which is the one. I would guess that this variable could be related to the pair collision model. However I have no idea how to fix this error.

Moreover, What I dont really understand is how can a simulation which ran perfectly the first time, crash in each of the several subsequent runs???

Any ideas anyone??? This issue is just bugging me??

Best regards

ansubru

[wyldckat]

Hi ansubru,

This seems to be a Lagrangian type solver and these solvers usually rely heavily in random numbers for randomly introducing new particles and for particles directions/collisions (if I'm not mistaken). Therefore, it's somehwat easy for you to be able to have a case that works fine with 5500 particles and not with 5499 or 5501.

As for the error message, it's indicating that there is a division that is triggering a sigFpe: http://en.wikipedia.org/wiki/SIGFPE#SIGFPE

Since you're using the debugging build, it tells you to then have a look into the file "~/OpenFOAM/OpenFOAM-2.3.0/src/lagrangian/intermediate/lnInclude/PairCollision.C", line 249, where the division is being requested. The code in question seems to be this one:

                    vector pW = nearPt - pos;

                    scalar normalAlignment = normal & pW/mag(pW);

Namely the second line. It seems that the "pW" variable is a vector with a magnitude of 0.0, hence the crash. Now the big question is why "nearPt" is identical to "pos".

This is assuming that you did not change the source code on this file.

Best regards,
Bruno

PS: Please post code and solver output following these instructions: Posting code and output with [CODE]

[ansubru]

Thanks a lot Bruno!! You have given me a new direction to look in. I will try to develop along those lines. As I had told you I am rather new to the forum so, Thank you so much for your earnest support. I will post here further if there are any developments.

PS - I have not altered the source code in any manner, however I am using a duplicated version of the solver DPMFoam entitled DPMFoam_mod (the code is exactly the same, i just felt that it would be safer to use my own copy of the solver so that accidental deletions are not affected at the src)

[ansubru]

Hi again Bruno!!

Well, I have tried a lot of things to try to overcome this error.. I included this snippet of code (experimental of course, and I am pretty sure this is not the right way ) to try to circumvent this error, however I have not managed to do so..

 if (nearest.distance() < r)
                {
                    vector normal = mesh.faceAreas()[realFaceI];

		if (mag(normal) == 0)

		{ 
                    
                    normal = (normal)/1.0; 
		}
	
                 else    
		{
                    normal /= mag(normal);
		}	 

                    
                    const vector& nearPt = nearest.rawPoint();

                    vector pW = nearPt - pos;

		// experimental bug fix

                 if (mag(pW) == 0)

		{ 
                    
                    scalar normalAlignment = normal & pW;
		}
	
                 else    
		{
                    scalar normalAlignment = normal & pW;//mag(pW);
		}

I still am not able to grasp why normal alignment or pW is zero (what is the pysical significance???) Moreover, I have also noticed this issue with regard to the dimensions specified for pressure in the 0 folder of the Goldschmidt tutorial..

FoamFile
{
    version     2.0;
    format      ascii;
    class       volScalarField;
    object      p;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

dimensions      [0 2 -2 0 0 0 0]; // --> isn't the dimensions of pressure [1 -1 -2 0 0 0 0];

And finally, I need to post-process individually each time step in matlab, hence I would need to open the files written in the kinematiccloud output. I have this issue, the files are not able to be read on the std gedit tool that is preinstalled in my linux work-station.. The file looks like the screen shot attached.. This is again for the tutorial case..

I am really quite befuddled by this issue . Do you have any more ideas???

Thanks again!!

ansubru

[wouter]

hello ansubru,

As you can see in line 11 of the header, this file is binary, so probably you told the solver in controlDict to write in binary. If you change this to ASCII then you get a lot bigger files but you can read them.

Hope this helps
Wouter

[wyldckat]

Greetings to all!

Originally Posted by ansubru

I still am not able to grasp why normal alignment or pW is zero (what is the pysical significance???)

I'm not familiar with this code, but it's either when the particle is exactly on top of a mesh cell vertex or when two particles are occupying the same exact place.

A few suggestions:

1. If you are not yet using OpenFOAM 2.3.x, then switch to using it. It's possible that this has already been fixed in this latest bug fix version. If you are using 2.3.x, then use "git pull" and run Allwmake again.
2. If it still occurs, then it's probably a bug, which should be reported here: http://www.openfoam.com/bugs/
3. The usual strategy used in OpenFOAM to avoid divisions by 0, is to change this:
   

   scalar normalAlignment = normal & pW/mag(pW);

   to this:
   

   scalar normalAlignment = normal & pW/(mag(pW)+VSMALL);

   Or instead of "VSMALL", try "ROOTVSMALL". Basically this is a faster way then to rely on "if", which is slower.

Best regards,
Bruno

[ansubru]

Hi again Bruno!!

Thanks for that added insight!! I had already figured out something based on those lines (i.e. overlapping between positions).. I have however, got my case to run again flawlessly.. I realized that the bounding walls within my geometry were quite close to each other.. hence there was a good probability that a particle that rebounded off the bottom wall would occupy a cell in the top wall where another particle was already situated... This is not my application at all... in the actual set up, there are no bounding walls on the top... hence i changed my geometry to eliminate the presence of the top wall i.e. push it to infinitum ( ideally i do not want particles to strike this wall).. when i made this change in geometry (top wall distance 10X longest distance in my geometry...) my case did run smoothly without any issues... Thanks gain for your invaluable support!!

Regards

ansubru

PS - I am not using OF 2.3.x yet...