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 Floating Object with SnappyHexMesh not solving (https://www.cfd-online.com/Forums/openfoam-solving/153783-interdymfoam-floating-object-snappyhexmesh-not-solving.html)

eloic June 3, 2015 12:08

InterDyMFoam Floating Object with SnappyHexMesh not solving
 
Hello,

I'm a beginner with OpenFOAM, and my goal is to adapt the floatingObject tutorial with a different object.

I have replaced the cube by a special geometry : it's a box created with Rhinoceros. There's a hole in there. I want to see what happens when I put the box at the surface of the calm water, and the water enters in the cavity in the box. Will the box float ? Will it sink ? What's the angle of the box with the x axis when the water is in the cavity ?

I used SnappyHexMesh, and then InterDyMFoam, inspired by floatingObject and DTCHull.

I always get the same error when I try to solve :

Code:

#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<double>&, Foam::Field<double>&, Foam::lduMatrix const&, Foam::FieldField<Foam::Field, double> const&, Foam::UPtrList<Foam::lduInterfaceField const> const&, Foam::Field<double> const&, unsigned char) const at ??:?
#4  Foam::GAMGSolver::Vcycle(Foam::PtrList<Foam::lduMatrix::smoother> const&, Foam::Field<double>&, Foam::Field<double> const&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::PtrList<Foam::Field<double> >&, Foam::PtrList<Foam::Field<double> >&, unsigned char) const at ??:?
#5  Foam::GAMGSolver::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const at ??:?
#6  Foam::fvMatrix<double>::solveSegregated(Foam::dictionary const&) at ??:?
#7  Foam::fvMatrix<double>::solve(Foam::dictionary const&) at ??:?
#8 
 at ??:?
#9  __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#10 
 at ??:?
Floating point exception (core dumped)

I guess you're familiar with it, because I have seen it on a lot of threads. I've tried a lot of methods (change deltaT, maxCo, boundary conditions etc. ) and I always get the same problem. The solving stops after few steps.

Can you help me to resolve it ?

Here is the complete case : https://www.dropbox.com/s/but0ovitg6...float.zip?dl=0

Thank you very much for your help.

nimasam June 5, 2015 08:14

instead of GAMG use PCG

eloic June 5, 2015 11:44

Thank you for the quick answer.

I tried using the PCG solver. I configured it this way :

Code:

/*--------------------------------*- C++ -*----------------------------------*\
| =========                |                                                |
| \\      /  F ield        | OpenFOAM: The Open Source CFD Toolbox          |
|  \\    /  O peration    | Version:  2.3.1                                |
|  \\  /    A nd          | Web:      www.OpenFOAM.org                      |
|    \\/    M anipulation  |                                                |
\*---------------------------------------------------------------------------*/
FoamFile
{
    version    2.0;
    format      ascii;
    class      dictionary;
    location    "system";
    object      fvSolution;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

solvers
{
    "alpha.water.*"
    {
        nAlphaCorr      3;
        nAlphaSubCycles 1;
        cAlpha          1;
        icAlpha        0;

        MULESCorr      yes;
        nLimiterIter    10;
        alphaApplyPrevCorr  yes;

        solver          smoothSolver;
        smoother        symGaussSeidel;
        tolerance      1e-10;
        relTol          0;
        minIter        1;
    }

    "pcorr.*"
    {
        solver          PCG;
        preconditioner  DIC;
        tolerance      1e-05;
        relTol          0;
        maxIter        100;
    };

    p_rgh
    {
        solver          PCG;
        preconditioner  DIC;
        tolerance      1e-05;
        relTol          0;
        maxIter        100;
    };

    p_rghFinal
    {
        solver          PCG;
        preconditioner  DIC;
        tolerance      1e-07;
        relTol          0;
        maxIter        20;
    }

    "(U|k|omega).*"
    {
        solver          smoothSolver;

        smoother        symGaussSeidel;
        nSweeps        1;

        tolerance      1e-7;
        relTol          0;
        minIter        1;
    };
}

PIMPLE
{
    momentumPredictor no;

    nOuterCorrectors 1;
    nCorrectors      3;
    nNonOrthogonalCorrectors 0;

    correctPhi      yes;
    moveMeshOuterCorrectors yes;
    turbOnFinalIterOnly yes;
}

relaxationFactors
{
    fields
    {
    }
    equations
    {
        ".*" 1;
    }
}

cache
{
    grad(U);
}


// ************************************************************************* //


Unfortunately I obtain the same results, and still get the error :

Code:

#0  Foam::error::printStack(Foam::Ostream&) at ??:?
#1  Foam::sigFpe::sigHandler(int) at ??:?
#2  in "/lib/x86_64-linux-gnu/libc.so.6"
#3  double Foam::sumProd<double>(Foam::UList<double> const&, Foam::UList<double> const&) at ??:?
#4  Foam::PCG::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const at ??:?
#5  Foam::fvMatrix<double>::solveSegregated(Foam::dictionary const&) at ??:?
#6  Foam::fvMatrix<double>::solve(Foam::dictionary const&) at ??:?
#7  Foam::fvMatrix<double>::solve() at ??:?
#8 
 at ??:?
#9  __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#10 
 at ??:?
Floating point exception (core dumped)


Maybe my configuration is not good, but I haven't found a lot of documentation about PCG solver. Using GAMG preconditioner instead of DIC changed nothing. Do you have another idea about what could make my case work ?

Thank you very much

JNSN June 8, 2015 07:27

Hi Albert,

change nOuterCorrectors to someting >1, e.g. like in the floatingObject tutorial to 5. Also set nCorrectors to 1.

Best regards,
Jan

eloic June 8, 2015 12:30

Thank you for your answer.

I changed the nOuterCorrectors to 5, and the nCorrectors to 1.
However I still get an error, trying with PCG or GAMG :

Code:

PIMPLE: iteration 3

6-DoF rigid body motion
    Centre of rotation: (15.9498 -188.023 -179.621)
    Centre of mass: (15.9498 -188.023 -179.621)
    Orientation: (-0.577721 -0.744973 0.333547 -0.743622 0.648866 0.161241 -0.336548 -0.15488 -0.928842)
    Linear velocity: (2.87644e+13 -3.39088e+14 -3.2394e+14)
    Angular velocity: (4.51385e+16 5.2248e+16 2.32419e+16)
Execution time for mesh.update() = 0.59 s
DICPCG:  Solving for pcorr, Initial residual = 1, Final residual = 2.47224, No Iterations 101
time step continuity errors : sum local = -1.12228, global = -1.34134e-05, cumulative = -0.000426832
#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::symGaussSeidelSmoother::smooth(Foam::word const&, Foam::Field<double>&, Foam::lduMatrix const&, Foam::Field<double> const&, Foam::FieldField<Foam::Field, double> const&, Foam::UPtrList<Foam::lduInterfaceField const> const&, unsigned char, int) at ??:?
#4  Foam::symGaussSeidelSmoother::smooth(Foam::Field<double>&, Foam::Field<double> const&, unsigned char, int) const at ??:?
#5  Foam::smoothSolver::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const at ??:?
#6  Foam::fvMatrix<double>::solveSegregated(Foam::dictionary const&) at ??:?
#7  Foam::fvMatrix<double>::solve(Foam::dictionary const&) at ??:?
#8  Foam::fvMatrix<double>::solve() at ??:?
#9 
 at ??:?
#10  __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#11 
 at ??:?
Floating point exception (core dumped)


The linear and angular velocity seem to be diverging, although I tried with a maxCo number of 1, 0.8 and 0.5.

I don't get what is my error, I have all tried with different numbers and always get the same thing... I would be very pleased if you could help me solve this mystery.

Thank you again

JNSN June 10, 2015 03:26

Hi Albert,

it is definitely no problem with PCG or GAMG. I have downloaded your case and had a small look at it. Very interesting that your body properties are exactly the same as for the DTC tutorial!?!?! First of all update the properties in the dynamic mesh dict to fit to your problem, i.e. mass, cog and moments of inertia. That is the reason why your motion is diverging.

After that you should think about spending some more distance between your floating body and the tank wall and change the inner and outer distance of the mesh morpher apropriately.

Good luck & best regards,
Jan

JNSN June 10, 2015 04:09

ok, one more hint. I think, for your problem you should use one of the generic motion solvers (e.g. displacementSBRStress), not the SLERP as your body is not completly filled. That means that you have to specify the body properties via boundary condition, how it was in previous versions.

Again, good luck!

eloic June 19, 2015 10:06

Thank you very much Jan for all these answers. I enlarged the tank wall and changed the solver into DisplacementSBRStress. I changed the initial conditions in pointDisplacement, using angularOscillatingDisplacement for testing (found here : http://www.cfd-online.com/Forums/ope...verfvmesh.html ). Great news, I don't have the sigFpe error anymore !! The solving runs fine.

But I have still a problem : angularOscillatingDisplacement is not the initial condition I want. I want the hull to react on the action of the gravity. I tried using sixDoFRigidBodyDisplacement for the hull, but it wasn't recognized by OpenFOAM. The valid patchfields types are :

Valid patchField types are :

30
(
angularOscillatingDisplacement
angularOscillatingVelocity
calculated
codedFixedValue
cyclic
cyclicACMI
cyclicAMI
cyclicSlip
empty
fixedNormalSlip
fixedValue
nonuniformTransformCyclic
oscillatingDisplacement
oscillatingVelocity
processor
processorCyclic
slip
solidBodyMotionDisplacement
surfaceDisplacement
surfaceSlipDisplacement
symmetry
symmetryPlane
timeVaryingMappedFixedValue
timeVaryingUniformFixedValue
uniformFixedValue
uniformInterpolatedDisplacement
value
waveDisplacement
wedge
zeroGradient
)

I have found very little documentation about these types, and I don't know which one would suit my problem. Maybe solidBodyMotionDisplacement ?

Can you help me there ?

Thank you again

JNSN June 19, 2015 10:37

yep, you need to include libs ("libsixDoFRigidBodyMotion.so"); in the controlDict.

Have a nice weekend!
Jan

eloic July 6, 2015 07:43

I included the libs, it's running but here again the same sigFpe error is coming back immediately...

I don't know what to do at all, I have tried a lot of configurations and I always get this error.

Here are the files attached, maybe someone can help me.

https://www.dropbox.com/s/x1rqlarsjg...loat3.zip?dl=0

Thank you very much

Besr regards

JNSN July 6, 2015 08:47

Check your body properties!!!! Hint: https://en.wikipedia.org/wiki/List_o...nts_of_inertia (Solid cube). Your cube is not completly solid, but should be a better value than what you have specified.

Best regards,
Jan

eloic July 6, 2015 10:37

Ok, I didn't thought that was the source of the problem. I put these values just to try.

In fact , calculing the center of mass and moment of inertia is a bit problematic, because the box is supposed to be split in half by a wall and constituted of two cells filled with air (you can see it on the stl file), but snappyhexmesh only considers the extern surface, and does not fill with air the other cavity (the one that has no hole).

Do you know how to make snappyhexmesh recognize the other cavity and fill it with air ?

Thank you very much

JNSN July 6, 2015 11:14

There is no need to model the air filled chamber, because the forces would be very small (density of air << density of water). And also if you would model this part the 6DoF solver still needs correct body properties, otherwise your accerlerations will be much too high. But it should be not that complicated to calculate the correct moments of inertia for your body. I think you can assume your walls as homogenous, sum them up, don't forget the Steiner theorem, thats it. Or do a very rough approximation, calculate for a solid cube, and take something like e.g. 10% of that value.

Hope this helps,
Jan

JNSN July 9, 2015 03:50

Hi Albert,

I played around a little with your case, and at the moment for me it looks like that also if you have some "realistic" body properties (i.e. mass, cog, inertia moment) your case is very unstable. My feeling at the moment is that there is some kind of bug in the 6-DoF solver. If you do not mind I will upload your case to the bug reporting system?

Best regards,
Jan

eloic July 9, 2015 05:44

Hi Jan,

Thank you for your help. No problem if you upload my case.

Best regards,
Albert

amcloughlin801 February 14, 2016 20:03

Hi guys, I realise quite a lot of time has passed since this thread was active, but did anyone come up with some solution to make interDyMFoam more stable?

My cases are very temperamental, crashing at any little change in body properties or position of the body in the domain.

Cheers
Aidan

JNSN February 17, 2016 08:01

Hi Aidan,

have you tried OpenFOAM-3.0 or newer. In the 3.0 release there was a major improvement of the 6DoF solver. You can now use an fully implicit Newmark integration scheme, which is MUCH more stable than the previous Leapfrog.

Best regards,
Jan

amcloughlin801 February 17, 2016 23:19

Hi Jan,

I'm using OF 2.3 right now, but I may well make the switch some time soon. Thanks for the info!

Aidan

abigail_s September 30, 2016 15:56

Alternative for a floating structure
 
Hi all,
I have been working with both SHM and 6DoRigidBodyMotion together and have noticed that a sphere can be modeled successfully, but shapes with a vertical wall, or even a rounded end cylinder will blow the case up- to where alpha is greatly outside of the 0-1 bounds.
I have found an alternative that works for me by using topoSet (i.e. in the floatingObject tutorial). I have not worked in detail with the topoSet function, but I believe a more complex structure may be created with some deeper understanding.

Simply speculating- I believe there is a discontinuity between the mesh created with snappy and the process for solving 2-phase dynamic mesh, but I could be wrong :rolleyes:

wouter September 30, 2016 17:00

hello,
Just my two cents. I had the experience that the displacement causes the cells to become very small, so check the cells near the solid in the direction of the movement. I think they become zero volume and the calculation for that cell crashes. I have not found a solution for this problem.

hope this helps
Wouter


All times are GMT -4. The time now is 02:17.