CFD Online Discussion Forums

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)
-   OpenFOAM Running, Solving & CFD (https://www.cfd-online.com/Forums/openfoam-solving/)
-   -   InterDyMFoam error (https://www.cfd-online.com/Forums/openfoam-solving/195906-interdymfoam-error.html)

Emanueledes November 20, 2017 09:56

InterDyMFoam error
 
2 Attachment(s)
Hi guys,

I'm a beginner in the use of openFoam so I'm having some problems. I'm trying to simulate the slamming of an hull on the water by using interDyMFoam for my graduation project. I have placed the hull at a certain height from the water and let it move at the velocity of 1 m/s in the negative z direction to evaluate pressure on the hull due to the impact on the water. Now, when I run interDyMFoam, i got this error after some timesteps:

Courant Number mean: 0.00212778 max: 6.57496
Interface Courant Number mean: 1.95423e-05 max: 0.0120632
deltaT = 0.000951527
Time = 0.00565446

PIMPLE: iteration 1
DICPCG: Solving for cellMotionUz, Initial residual = 0.00875879, Final residual = 9.55665e-09, No Iterations 44
Execution time for mesh.update() = 9.36 s
GAMG: Solving for pcorr, Initial residual = 1, Final residual = 0.0598646, No Iterations 4
time step continuity errors : sum local = 8.80194e-07, global = 3.47383e-08, cumulative = -2.26463e-08
smoothSolver: Solving for alpha.water, Initial residual = 1.0246e-05, Final residual = 4.76097e-11, No Iterations 1
Phase-1 volume fraction = 0.412872 Min(alpha.water) = -1.62871e-88 Max(alpha.water) = 1
Applying the previous iteration compression flux
MULES: Correcting alpha.water
MULES: Correcting alpha.water
MULES: Correcting alpha.water
MULES: Correcting alpha.water
Phase-1 volume fraction = 0.412872 Min(alpha.water) = -3.47749e-16 Max(alpha.water) = 1
#0 Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::sigFpe::sigHandler(int) at ??:?
#2 ? in "/lib/x86_64-linux-gnu/libc.so.6"
#3 Foam::GAMGSolver::scale(Foam::Field&, Foam::Field&, Foam::lduMatrix const&, Foam::FieldField const&, Foam::UPtrList const&, Foam::Field const&, unsigned char) const at ??:?
#4 Foam::GAMGSolver::Vcycle(Foam::PtrList const&, Foam::Field&, Foam::Field const&, Foam::Field&, Foam::Field&, Foam::Field&, Foam::Field&, Foam::Field&, Foam::PtrList&, Foam::PtrList&, unsigned char) const at ??:?
#5 Foam::GAMGSolver::solve(Foam::Field&, Foam::Field const&, unsigned char) const at ??:?
#6 Foam::fvMatrix::solveSegregated(Foam::dictionary const&) at ??:?
#7 Foam::fvMatrix::solve(Foam::dictionary const&) in "/opt/openfoam4/platforms/linux64GccDPInt32Opt/bin/interDyMFoam"
#8 ? in "/opt/openfoam4/platforms/linux64GccDPInt32Opt/bin/interDyMFoam"
#9 __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#10 ? in "/opt/openfoam4/platforms/linux64GccDPInt32Opt/bin/interDyMFoam"

I tried to run moveDynamicMesh and I noticed that some bad cells appeared (non-orthogonalities, negative volumes ecc..) after some timesteps, but the initial mesh is perfect. Maybe it can be a problem of the solver but I've read that velocityLaplacian is the best for these cases. Can someone help me to solve this problem? I would be really grateful. I attach my controlDict and dynamicMeshDict files. Thank you all.

Emanuele

Emanueledes November 22, 2017 14:47

Any idea? I'm trying different ways but unfortunately without fix the problem. I really need your help, please. Thank you.

Emanuele

LVDH November 23, 2017 03:53

Is it possible that you are moving the hull so far that the mesh gets too deformed? If that is the case you could try using an overset mesh.

Emanueledes November 23, 2017 04:17

Hi Andre,

Thank you so much for your reply. Maybe I've found the error just right now. In the files cellMotionUz and pointMotionUz I had a noSlip condition for the plane where the hull moves. I changed it to Slip and now it seems to work. If I have other problems I'll write here again. Thank you again for the reply. Regards,

Emanuele De Stradis

Tobi November 23, 2017 05:43

Just one suggestion / trick / recommendation. For any mesh motion I prefer to run the moveDynamicMesh solver. Therefore, I change the delta t in order to see the motion and save the corresponding time steps. Via ParaView and the output of the solver one can directly see if e.g. the interfaces are still connected or not and if there is a problem of the motion itself (wrong set-up in the dynamicDict). Based on the fact that the solver just moves the mesh without calculating any equation, it is faster and is a perfect tool for analyzing the moving mesh behavior :)

Emanueledes November 23, 2017 10:09

Dear Tobias, thank you so much for your clear suggestion. I'll keep it in mind. Thank you again.

Sincerely,

Emanuele De Stradis


All times are GMT -4. The time now is 11:42.