[laurentb]

Hi all,

I want to simulate a mixer (rushton turbine) and I m using pimpleDyMFoam solver but after some iterations i've got an error message. Can you help me understand why ?

Thanks
------------
Courant Number mean: 0.000809178 max: 0.483624
deltaT = 8.08409e-05
Time = 0.0321407

solidBodyMotionFunctions::rampedAxisRotationMotion ::transformation(): Time = 0.0321407 transformation: ((0 0 0) (0.99999 (0 0 0.00450739)))
AMI: Creating addressing and weights between 25130 source faces and 25130 target faces
AMI: Patch source weights min/max/average = 1.0565e-06, 1.00177, 0.834999
AMI: Patch target weights min/max/average = 0, 1.00183, 0.83511
PIMPLE: iteration 1
[2] #0 Foam::error:rintStack(Foam::Ostream&) in "/opt/openfoam220/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
[2] #1 Foam::sigFpe::sigHandler(int) in "/opt/openfoam220/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
[2] #2 in "/lib/x86_64-linux-gnu/libc.so.6"
[2] #3 Foam::divide(Foam::Field<double>&, double const&, Foam::UList<double> const&) in "/opt/openfoam220/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
[2] #4 Foam::tmp<Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> > Foam:perator/<Foam::fvPatchField, Foam::volMesh>(Foam::dimensioned<double> const&, Foam::tmp<Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> > const&) in "/opt/openfoam220/platforms/linux64GccDPOpt/bin/pimpleDyMFoam"
[2] #5
[2] in "/opt/openfoam220/platforms/linux64GccDPOpt/bin/pimpleDyMFoam"
[2] #6 __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
[2] #7
[2] in "/opt/openfoam220/platforms/linux64GccDPOpt/bin/pimpleDyMFoam"
[laurent-Precision-WorkStation-T7400:17917] *** Process received signal ***
[laurent-Precision-WorkStation-T7400:17917] Signal: Floating point exception (8)
[laurent-Precision-WorkStation-T7400:17917] Signal code: (-6)
[laurent-Precision-WorkStation-T7400:17917] Failing at address: 0x3e8000045fd
[laurent-Precision-WorkStation-T7400:17917] [ 0] /lib/x86_64-linux-gnu/libc.so.6(+0x364a0) [0x7f92ee10b4a0]
[laurent-Precision-WorkStation-T7400:17917] [ 1] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35) [0x7f92ee10b425]
[laurent-Precision-WorkStation-T7400:17917] [ 2] /lib/x86_64-linux-gnu/libc.so.6(+0x364a0) [0x7f92ee10b4a0]
[laurent-Precision-WorkStation-T7400:17917] [ 3] /opt/openfoam220/platforms/linux64GccDPOpt/lib/libOpenFOAM.so(_ZN4Foam6divideERNS_5FieldIdEERKdRK NS_5UListIdEE+0x24) [0x7f92ef33a034]
[laurent-Precision-WorkStation-T7400:17917] [ 4] pimpleDyMFoam(_ZN4FoamdvINS_12fvPatchFieldENS_7vol MeshEEENS_3tmpINS_14GeometricFieldIdT_T0_EEEERKNS_ 11dimensionedIdEERKS8_+0x2a0) [0x4480a0]
[laurent-Precision-WorkStation-T7400:17917] [ 5] pimpleDyMFoam() [0x41aa93]
[laurent-Precision-WorkStation-T7400:17917] [ 6] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed) [0x7f92ee0f676d]
[laurent-Precision-WorkStation-T7400:17917] [ 7] pimpleDyMFoam() [0x41eebd]
[laurent-Precision-WorkStation-T7400:17917] *** End of error message ***
--------------------------------------------------------------------------
mpirun noticed that process rank 2 with PID 17917 on node laurent-Precision-WorkStation-T7400 exited on signal 8 (Floating point exception).
--------------------------------------------------------------------------

[Artur]

Take a look at the fragments highlighted in red:

Originally Posted by laurentb

Hi all,

AMI: Creating addressing and weights between 25130 source faces and 25130 target faces
AMI: Patch source weights min/max/average = 1.0565e-06, 1.00177, 0.834999
AMI: Patch target weights min/max/average = 0, 1.00183, 0.83511

mpirun noticed that process rank 2 with PID 17917 on node laurent-Precision-WorkStation-T7400 exited on signal 8 (Floating point exception).

Your sliding mesh explodes due to incorrect weighting (there is at least one face with zero weighting which is unphysical). There have been many posts on this forum giving guidance on how to get rid of that. In short, you should aim at having all your AMI weightings as close to 1.0 as possible.

Have a look at these to start with:

http://www.cfd-online.com/Forums/ope...ing-ami-2.html

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

Without seeing your case I'd recommend increasing the number of feature snap iterations and solver iterations in your snap controlls. Sometimes coarsening the mesh and increasing the AMI tolerance also helps.

Best wishes,

A

[laurentb]

If you want to have a look to my case (200 Mo) you can download it at :

https://www.dropbox.com/s/allf2zv7v1...L131003.tar.gz

I'm working on an hexaedral mesh in order to avoid zero wheighting. Does someone can explain exactly what are "patch source and target weights" ?

[louisgag]

For those reading on, an quick way to get around this weighting problem is sometimes to use a constant timestep (if you're using a variable one), and ensure it adds up correctly to the period of the mesh movement cycle and/or verify using the moveDynamicMesh command that you will never hit that null weighting zone...
-Louis

[Artur]

Hi,

Thanks for sharing the tip!

Since I last posted in this thread I've also found that sometimes it's a very particular angular position that causes a crash, even if the overall AMI mesh is good. I've found that a hack that helps to deal with that sometimes is to save your solution JUST before the crash point (1 time step), let it crash, and then restart with a bigger time step (just temporarily) in order to "jump over" the problematic conformation of the interpolation patches. It's not a very neat way of doing it and it's quite tedious but helps if you need to get the results and don't have the time to re-mesh and re-run.

All the best,

A

[louisgag]

Hi Artur,
I've noted the same thing, but how do you save just before the crash when you don't know beforehand where it will crash ?
Regards,
-Louis

[Artur]

In general, for big simulations I tend to save my solution quite often anyway but use the purgeWrite parameter in controlDict to only keep the last 2 or 3 saves. Then, if a problem occurs, I restart and save every time step (it's terrible, I know, but as I said this is a hack). Then when it crashes I have the data for just before it did and hence can restart with a big time step to perform the "jump".

In the past it would usually happen to me more-or-less once or twice per revolution so it's bearable to deal with it this way. If it happened more often for a particular mesh I would probably just try to re-do it.

A

[louisgag]

Great, thanks for the tip about purgeWrite.
-Louis