Overset with moving domain

Alczem · January 12, 2024, 11:08

Hey!

After testing a lot of parameters, I wanted to report what worked for me (numerically speaking

) for an overset simulation of a body falling/moving in a fluid domain linked to the movement of the overset mesh, to avoid meshing the whole background, with OpenFoam v2306. This was done to study fluttering and tumbling motion of bodies in a pool.

I tested overPimpleDyMFoam, overBuoyantPimpleDyMFoam and overRhoPimpleDyMFoam. overRhoPimpleDyMFoam was best suited because it can use the moveMeshOuterCorrectors setting to compute mesh movement for each outer corrector instead of once per timestep (overPimpleDyMFoam ignores this switch, and compute the mesh movement only once per timestep). A constant density was used for the fluid. overBuoyantPimpleDyMFoam was given me trouble with velocity exploding near the falling body, despite underrelaxing or reducing the maxCo.

nOuterCorrectors = 2 was enough to have a stable simulation, without any spurious velocities, with a maxCo = 3.

No underrelaxation in fvSolution or dynamicMeshDict was necessary. In particular, accelerationRelax is useful only when using moveMeshOuterCorrectors, and the simulation remains time accurate, but you have to have enough outer correctors. accelerationDamping should not be used to capture accurately the transient evolution of the body or the flow, but only to reach a steady state.

Newmark or symplectic solver gave similar results with marginal differences. Newmark seemed more robust when using larger CFLs.

inverseDistance and cellVolumeWeight gave similar results, with inverseDistance being waaaay faster (as reported in several papers and threads) so I would recommend it over cellVolumeWeight except if nothing else works.

Set nCorrectors at least to 2. The solver would diverge if nCorrectors = 1

Setting the relaxation factors of fvSolution to 0.8 or 0.7 (even for the final iteration) did not affect significatively the results when using residualControl and the Pimple algorithm to have a converged timestep and allowed for a more stable run, but differences were minimal compared to nOuterCorrectors = 2 and no relaxation.

The sides of the moving domain were treated as one moving boundary where fluid could go through freely, so inletOutlet was used for turbulence quantities, totalPressure for pressure, and zeroGradient for velocity (pressureInletOutletVelocity was not tested)

Here are the settings:

fvSolution

Code:

solvers
{
    cellDisplacement
    {
        solver          PCG;
        preconditioner  DIC;

        tolerance       1e-06;
        relTol          0;
        maxIter         100;
    }
    
    rho
    {
        solver          PBiCGStab;
        preconditioner  DILU;
        tolerance       1e-8;
        relTol          0.1;
    }

    rhoFinal
    {
        $rho;
        tolerance       1e-8;
        relTol          0;
    }

    "(p|p_rgh)"
    {
        solver          PBiCGStab;
        preconditioner  DILU;
        tolerance       1e-6;
        relTol          0;
    }

    "(p|p_rgh)Final"
    {
        $p;
    }

    pcorr
    {
        $p;
        //solver          PCG;
        //preconditioner  DIC;
    }

    pcorrFinal
    {
        $pcorr;
        relTol          0;
    }
    
    "h.*"
    {
        solver          smoothSolver;
        smoother        symGaussSeidel;
        tolerance       1e-6;
        relTol          0;
        maxIter            0;
    }

    "(U|k|epsilon|omega)"
    {
        solver          smoothSolver;
        smoother        symGaussSeidel;
        tolerance       1e-6;
        relTol          0;
    }

    "(U|k|epsilon|omega)Final"
    {
        $U;
        tolerance       1e-6;
        relTol          0;
    }

    "yPsi.*"
    {
        solver          PBiCGStab;
        preconditioner  DILU;
        tolerance       1e-5;
        relTol          0.0;
        minIter            1;
    }

}

PIMPLE
{
    momentumPredictor   no;
    nOuterCorrectors    2;
    nCorrectors         3;
    nNonOrthogonalCorrectors 1;
    moveMeshOuterCorrectors yes;
    turbOnFinalIterOnly no;
    
    consistent            no;

    oversetAdjustPhi    yes; //replaces ddtCorr, correctPhi and massFluxInterpolation
    
     residualControl
    {
        "p.*"
        {
                tolerance  1e-5;
                relTol      0;
        }

     }
}


relaxationFactors
{
    fields
    {
        "p_rgh.*"       1;
    }
    equations
    {
        "U.*"                1;
        "k.*"                 1;
        "epsilon.*"         1;
        "omega.*"             1;
    }
}

cache
{
    grad(U);
}

fvSchemes

Code:

ddtSchemes
{
    default         Euler;
    //default         backward;
}

gradSchemes
{
    default         Gauss linear;
    limited            cellLimited Gauss linear 0.5;
}

divSchemes
{
    default         none;
    div(phi,U)      Gauss linearUpwindV limited; //Gauss upwind;

    div(phi,epsilon) Gauss linearUpwind limited; //Gauss upwind;
    div(phi,omega) Gauss linearUpwind limited; //Gauss upwind;
    div(phi,k)       Gauss linearUpwind limited; //Gauss upwind;
    div(phi,h)       Gauss linearUpwind limited;
    
    div(phi,K)      Gauss linear;

    div((nuEff*dev2(T(grad(U))))) Gauss linear;
    div(((rho*nuEff)*dev2(T(grad(U)))))    Gauss linear;
    
    div(meshPhi,p)  Gauss linear;
}

laplacianSchemes
{
    default         Gauss linear corrected;
    laplacian(diffusivity,cellDisplacement)  Gauss linear corrected;
}

interpolationSchemes
{
    default         linear;
}

snGradSchemes
{
    default         corrected ;
}

oversetInterpolation
{
    //method          cellVolumeWeight;
    method          inverseDistance;
    //method          leastSquares;

    // The inverseDistance method uses a 'voxel' like search structure.
    // Optionally specify the extent and number of divisions n.
    // Note that it will allocate an array of nx*ny*nz. If not specified:
    // - searchBox          : local mesh bounding box
    // - searchBoxDivisions : root (2D) or cube-root(3D) of number of cells
    //searchBox           (-0.1 -0.175 -0.175) (0.55 0.175 0.175);
    //searchBoxDivisions  (10 10 10);

    //layerRelax 0.5; //control the number of interpolated cells
    
    //allowInterpolatedDonors    false;
    //layerRelax          0.3;
    //holeLayers            3;
    //useLayer            2;// Layer used
    
    
    
    // Faster but less accurate
    //method              trackingInverseDistance;
    //searchBox           (0 0 0)(0.02 0.01 0.01);
    //searchBoxDivisions  2{(64 64 64)};
    //allowInterpolatedDonors     false;
    
}


oversetInterpolationSuppressed
{
    grad(p_rgh);
    surfaceIntegrate(phiHbyA);
}


fluxRequired
{
    default         no;
    pcorr           ;
    p               ;
}


wallDist
{
    method        Poisson;
    //correctWalls    true;
}

dynamicMeshDict

Code:

motionSolverLibs    (sixDoFRigidBodyMotion);

dynamicFvMesh       dynamicOversetFvMesh;

solver          sixDoFRigidBodyMotion;



solvers
{
    
     domain
     {
        motionSolverLibs (fvMotionSolvers);

        motionSolver            solidBody;
        solidBodyMotionFunction drivenLinearMotion;

        cellSet                 c0;
        cOfGdisplacement        CofG;
    }
    



    plate
    {
        motionSolverLibs   (sixDoFRigidBodyMotion);
        motionSolver        sixDoFRigidBodyMotion;

        cellSet         c1;
        cOfGdisplacement    CofG;

        patches         (plate);
        innerDistance   1e3;
        outerDistance   1.5e3;

        centreOfMass    (0 0 20);

        //rho rhoInf;

        //rhoInf 1;
        

        // Cuboid mass
        mass            21.25;  //mass minus the buoyancy of the body
        
        g (0 0 -9.81);
        
        velocity        (0 0 -5);
        
        momentOfInertia (1.40625 0.71015 0.71015);

        report          on;
        accelerationRelaxation 1; //0.5; // for newmark
        accelerationDamping    1; //0.8;

        solver
        {
            type Newmark;
        }

    
        constraints
        {
            /*
            line_restraint
            {
               sixDoFRigidBodyMotionConstraint   line;
               direction                              (0 0 1);
            }
            
            orientation_restraint
            {
                sixDoFRigidBodyMotionConstraint   orientation;
            }
            */
            
        }
    
    }
}

Sorry for the messy post

but I wanted to have some written record as much for me as for others. This is all based on my recent experience with overset simulations and whatever I could find online, so take it with a grain of salt!

I will be happy to hear from others about recommended practices overset computations and moving domains. There are a lot of settings I have not yet tested, such as the ddtScheme. Hopefully I will update this thread with more detailed information as I learn more about it.

NotOverUnderated · January 12, 2024, 11:41

Hi,

Thank you for sharing this. This is certainly very helpful.

I have some questions about some dictionaries in your fvSolution files:

1) Why you are using a small number for nOuterCorrectors? I read somewhere here in the forum (here: https://openfoamwiki.net/index.php/O...hm_in_OpenFOAM) that you must use a large number.

Code:

    nOuterCorrectors    2; // I think this should be a large number like 30

2) This is a followup question from the question 1):

Code:

    nOuterCorrectors    2;

    ...
    ...
    
     residualControl
    {
        "p.*"
        {
                tolerance  1e-5;
                relTol      0;
        }

     }

- What is the point of using residualControl in this case when you are using only 2 nOuterCorrectors? as far as I understand the residualControl dictionary controls the number of outer correctors: The solver will do nOuterCorrector iterations unless the initial residuals of the fields satisfy the tolerance specified in residualControl.

Kind regards

xiangxiang · January 14, 2024, 22:32

Quote:

Originally Posted by Alczem

Hey!

After testing a lot of parameters, I wanted to report what worked for me (numerically speaking

) for an overset simulation of a body falling/moving in a fluid domain linked to the movement of the overset mesh, to avoid meshing the whole background, with OpenFoam v2306. This was done to study fluttering and tumbling motion of bodies in a pool.

I tested overPimpleDyMFoam, overBuoyantPimpleDyMFoam and overRhoPimpleDyMFoam. overRhoPimpleDyMFoam was best suited because it can use the moveMeshOuterCorrectors setting to compute mesh movement for each outer corrector instead of once per timestep (overPimpleDyMFoam ignores this switch, and compute the mesh movement only once per timestep). A constant density was used for the fluid. overBuoyantPimpleDyMFoam was given me trouble with velocity exploding near the falling body, despite underrelaxing or reducing the maxCo.

nOuterCorrectors = 2 was enough to have a stable simulation, without any spurious velocities, with a maxCo = 3.

No underrelaxation in fvSolution or dynamicMeshDict was necessary. In particular, accelerationRelax is useful only when using moveMeshOuterCorrectors, and the simulation remains time accurate, but you have to have enough outer correctors. accelerationDamping should not be used to capture accurately the transient evolution of the body or the flow, but only to reach a steady state.

Newmark or symplectic solver gave similar results with marginal differences. Newmark seemed more robust when using larger CFLs.

inverseDistance and cellVolumeWeight gave similar results, with inverseDistance being waaaay faster (as reported in several papers and threads) so I would recommend it over cellVolumeWeight except if nothing else works.

Set nCorrectors at least to 2. The solver would diverge if nCorrectors = 1

Setting the relaxation factors of fvSolution to 0.8 or 0.7 (even for the final iteration) did not affect significatively the results when using residualControl and the Pimple algorithm to have a converged timestep and allowed for a more stable run, but differences were minimal compared to nOuterCorrectors = 2 and no relaxation.

The sides of the moving domain were treated as one moving boundary where fluid could go through freely, so inletOutlet was used for turbulence quantities, totalPressure for pressure, and zeroGradient for velocity (pressureInletOutletVelocity was not tested)

Here are the settings:

fvSolution

Code:

solvers
{
    cellDisplacement
    {
        solver          PCG;
        preconditioner  DIC;

        tolerance       1e-06;
        relTol          0;
        maxIter         100;
    }
    
    rho
    {
        solver          PBiCGStab;
        preconditioner  DILU;
        tolerance       1e-8;
        relTol          0.1;
    }

    rhoFinal
    {
        $rho;
        tolerance       1e-8;
        relTol          0;
    }

    "(p|p_rgh)"
    {
        solver          PBiCGStab;
        preconditioner  DILU;
        tolerance       1e-6;
        relTol          0;
    }

    "(p|p_rgh)Final"
    {
        $p;
    }

    pcorr
    {
        $p;
        //solver          PCG;
        //preconditioner  DIC;
    }

    pcorrFinal
    {
        $pcorr;
        relTol          0;
    }
    
    "h.*"
    {
        solver          smoothSolver;
        smoother        symGaussSeidel;
        tolerance       1e-6;
        relTol          0;
        maxIter            0;
    }

    "(U|k|epsilon|omega)"
    {
        solver          smoothSolver;
        smoother        symGaussSeidel;
        tolerance       1e-6;
        relTol          0;
    }

    "(U|k|epsilon|omega)Final"
    {
        $U;
        tolerance       1e-6;
        relTol          0;
    }

    "yPsi.*"
    {
        solver          PBiCGStab;
        preconditioner  DILU;
        tolerance       1e-5;
        relTol          0.0;
        minIter            1;
    }

}

PIMPLE
{
    momentumPredictor   no;
    nOuterCorrectors    2;
    nCorrectors         3;
    nNonOrthogonalCorrectors 1;
    moveMeshOuterCorrectors yes;
    turbOnFinalIterOnly no;
    
    consistent            no;

    oversetAdjustPhi    yes; //replaces ddtCorr, correctPhi and massFluxInterpolation
    
     residualControl
    {
        "p.*"
        {
                tolerance  1e-5;
                relTol      0;
        }

     }
}


relaxationFactors
{
    fields
    {
        "p_rgh.*"       1;
    }
    equations
    {
        "U.*"                1;
        "k.*"                 1;
        "epsilon.*"         1;
        "omega.*"             1;
    }
}

cache
{
    grad(U);
}

fvSchemes

Code:

ddtSchemes
{
    default         Euler;
    //default         backward;
}

gradSchemes
{
    default         Gauss linear;
    limited            cellLimited Gauss linear 0.5;
}

divSchemes
{
    default         none;
    div(phi,U)      Gauss linearUpwindV limited; //Gauss upwind;

    div(phi,epsilon) Gauss linearUpwind limited; //Gauss upwind;
    div(phi,omega) Gauss linearUpwind limited; //Gauss upwind;
    div(phi,k)       Gauss linearUpwind limited; //Gauss upwind;
    div(phi,h)       Gauss linearUpwind limited;
    
    div(phi,K)      Gauss linear;

    div((nuEff*dev2(T(grad(U))))) Gauss linear;
    div(((rho*nuEff)*dev2(T(grad(U)))))    Gauss linear;
    
    div(meshPhi,p)  Gauss linear;
}

laplacianSchemes
{
    default         Gauss linear corrected;
    laplacian(diffusivity,cellDisplacement)  Gauss linear corrected;
}

interpolationSchemes
{
    default         linear;
}

snGradSchemes
{
    default         corrected ;
}

oversetInterpolation
{
    //method          cellVolumeWeight;
    method          inverseDistance;
    //method          leastSquares;

    // The inverseDistance method uses a 'voxel' like search structure.
    // Optionally specify the extent and number of divisions n.
    // Note that it will allocate an array of nx*ny*nz. If not specified:
    // - searchBox          : local mesh bounding box
    // - searchBoxDivisions : root (2D) or cube-root(3D) of number of cells
    //searchBox           (-0.1 -0.175 -0.175) (0.55 0.175 0.175);
    //searchBoxDivisions  (10 10 10);

    //layerRelax 0.5; //control the number of interpolated cells
    
    //allowInterpolatedDonors    false;
    //layerRelax          0.3;
    //holeLayers            3;
    //useLayer            2;// Layer used
    
    
    
    // Faster but less accurate
    //method              trackingInverseDistance;
    //searchBox           (0 0 0)(0.02 0.01 0.01);
    //searchBoxDivisions  2{(64 64 64)};
    //allowInterpolatedDonors     false;
    
}


oversetInterpolationSuppressed
{
    grad(p_rgh);
    surfaceIntegrate(phiHbyA);
}


fluxRequired
{
    default         no;
    pcorr           ;
    p               ;
}


wallDist
{
    method        Poisson;
    //correctWalls    true;
}

dynamicMeshDict

Code:

motionSolverLibs    (sixDoFRigidBodyMotion);

dynamicFvMesh       dynamicOversetFvMesh;

solver          sixDoFRigidBodyMotion;



solvers
{
    
     domain
     {
        motionSolverLibs (fvMotionSolvers);

        motionSolver            solidBody;
        solidBodyMotionFunction drivenLinearMotion;

        cellSet                 c0;
        cOfGdisplacement        CofG;
    }
    



    plate
    {
        motionSolverLibs   (sixDoFRigidBodyMotion);
        motionSolver        sixDoFRigidBodyMotion;

        cellSet         c1;
        cOfGdisplacement    CofG;

        patches         (plate);
        innerDistance   1e3;
        outerDistance   1.5e3;

        centreOfMass    (0 0 20);

        //rho rhoInf;

        //rhoInf 1;
        

        // Cuboid mass
        mass            21.25;  //mass minus the buoyancy of the body
        
        g (0 0 -9.81);
        
        velocity        (0 0 -5);
        
        momentOfInertia (1.40625 0.71015 0.71015);

        report          on;
        accelerationRelaxation 1; //0.5; // for newmark
        accelerationDamping    1; //0.8;

        solver
        {
            type Newmark;
        }

    
        constraints
        {
            /*
            line_restraint
            {
               sixDoFRigidBodyMotionConstraint   line;
               direction                              (0 0 1);
            }
            
            orientation_restraint
            {
                sixDoFRigidBodyMotionConstraint   orientation;
            }
            */
            
        }
    
    }
}

Sorry for the messy post

but I wanted to have some written record as much for me as for others. This is all based on my recent experience with overset simulations and whatever I could find online, so take it with a grain of salt!

I will be happy to hear from others about recommended practices overset computations and moving domains. There are a lot of settings I have not yet tested, such as the ddtScheme. Hopefully I will update this thread with more detailed information as I learn more about it.

Hi, Alczem
Here's my personal opinion:
1. Euler in ddtSchemes is of first-order precision, and usually we prefer to get a result with second-order precision, such as using backward
2. The number of external loops of nOuterCorrectors is usually set to be relatively large, and I usually set it to nOuterCorrectors =50~100, which does not affect the calculation speed, because the external loops will jump out after the convergence condition is reached.

Kind regards
xiangxiang

Alczem · January 15, 2024, 05:54

Hey!

About the nOuterCorrectors set to 2, I found out that letting the solver converge with nOuterCorrectors set to 50 and residualControl versus having a fixed number of loops (2 or 4 in my case) made almost no difference in the computed position and velocity after 1 second of simulated time. I should add that I found a a tutorial by Alletto, investigating the Newmark and symplectic solvers for oversets, and it also uses a fixed number of loops for Newmark, which gave me confidence in using 2 loops. Here is his collection of tutorials:

https://wiki.openfoam.com/Collection...ichael_Alletto

You are right that using PIMPLE and residualControl would usually result in a few iterations to converge (more are needed with a tighter tolerance of course). But since I used moveMeshOuterCorrectors, additional loops are more expansive than usual. That is why I stuck with 2 loops, but I agree that if you need the best accuracy regardless of runtime, having PIMPLE manage the number of loops is the way! The residualControl subdictionary in my fvSolution is just there so I didn't have to re-edit the file when I was trying things out. It does not prevent the simulation from running even if it does not converge each timestep.

I have not properly tested the ddtSchemes, I hope I will have some time to compare the different schemes. But similar to the nOuterCorrectors discussion, the settings I shared are meant to be a compromise between accuracy and cost, since overset simulations are so heavy

(As additional info, my test case was a plate falling with an initial vertical velocity in water, and I monitored the position and velocity after 1 second. This may not be chaotic or long enough to see the differences in accuracy when using more loops or different schemes though)

Alczem · January 16, 2024, 05:12

Quick edit about the velocity boundary condition for the domain boundaries:

I used zeroGradient, but running the simulation for a longer time eventually created some kind of succion effect at the "inlet" (the bottom boundary since my body is falling). My understanding is that the fluid getting pushed downward by the falling body reaches the zeroGradient boundary, which registers this downward current and keep applying this downward velocity, resulting in a succion instead of an immobile fluid. As a a fix, I tried to enlarge my background mesh, with better results, but whats seems to be best is to use an inletOutlet condition with inletValue set to (0 0 0) for all the boundaries that allow the fluid to enter or leave freely. That way, the fluid is introduced into the domain with a null velocity (duh, I don't know how I missed that, it is also similar to the rigidBodyHull tutorial for the interFoam overset solver).

With this change, results are similar between a cube falling with a fixed background mesh and a cube falling with a moving domain linked to it (terminal velocity and forces are equal), though the background mesh for the moving domain still needs to be large enough to mitigate any boundary effect on the moving body.

Karim ahmed · March 26, 2024, 09:45

Hello Alczem ,

Thank for this useful informations. can you please provide the 0 folder , just to check the BC , i am trying to solve something near this case and i want to check my BCs

thanks in advance

Alczem · March 27, 2024, 08:58

Quote:

Originally Posted by Karim ahmed

Hello Alczem ,

Thank for this useful informations. can you please provide the 0 folder , just to check the BC , i am trying to solve something near this case and i want to check my BCs

thanks in advance

Hey,

Here you go! Don't hesitate to report back if you find issues with this setup

Redrakham · April 19, 2024, 10:10

Quote:

Originally Posted by Alczem

Hey!

After testing a lot of parameters, I wanted to report what worked for me (numerically speaking

) for an overset simulation of a body falling/moving in a fluid domain linked to the movement of the overset mesh, to avoid meshing the whole background, with OpenFoam v2306. This was done to study fluttering and tumbling motion of bodies in a pool.

I tested overPimpleDyMFoam, overBuoyantPimpleDyMFoam and overRhoPimpleDyMFoam. overRhoPimpleDyMFoam was best suited because it can use the moveMeshOuterCorrectors setting to compute mesh movement for each outer corrector instead of once per timestep (overPimpleDyMFoam ignores this switch, and compute the mesh movement only once per timestep). A constant density was used for the fluid. overBuoyantPimpleDyMFoam was given me trouble with velocity exploding near the falling body, despite underrelaxing or reducing the maxCo.

nOuterCorrectors = 2 was enough to have a stable simulation, without any spurious velocities, with a maxCo = 3.

No underrelaxation in fvSolution or dynamicMeshDict was necessary. In particular, accelerationRelax is useful only when using moveMeshOuterCorrectors, and the simulation remains time accurate, but you have to have enough outer correctors. accelerationDamping should not be used to capture accurately the transient evolution of the body or the flow, but only to reach a steady state.

Newmark or symplectic solver gave similar results with marginal differences. Newmark seemed more robust when using larger CFLs.

inverseDistance and cellVolumeWeight gave similar results, with inverseDistance being waaaay faster (as reported in several papers and threads) so I would recommend it over cellVolumeWeight except if nothing else works.

Set nCorrectors at least to 2. The solver would diverge if nCorrectors = 1

Setting the relaxation factors of fvSolution to 0.8 or 0.7 (even for the final iteration) did not affect significatively the results when using residualControl and the Pimple algorithm to have a converged timestep and allowed for a more stable run, but differences were minimal compared to nOuterCorrectors = 2 and no relaxation.

The sides of the moving domain were treated as one moving boundary where fluid could go through freely, so inletOutlet was used for turbulence quantities, totalPressure for pressure, and zeroGradient for velocity (pressureInletOutletVelocity was not tested)

Here are the settings:

fvSolution

Code:

solvers
{
    cellDisplacement
    {
        solver          PCG;
        preconditioner  DIC;

        tolerance       1e-06;
        relTol          0;
        maxIter         100;
    }
    
    rho
    {
        solver          PBiCGStab;
        preconditioner  DILU;
        tolerance       1e-8;
        relTol          0.1;
    }

    rhoFinal
    {
        $rho;
        tolerance       1e-8;
        relTol          0;
    }

    "(p|p_rgh)"
    {
        solver          PBiCGStab;
        preconditioner  DILU;
        tolerance       1e-6;
        relTol          0;
    }

    "(p|p_rgh)Final"
    {
        $p;
    }

    pcorr
    {
        $p;
        //solver          PCG;
        //preconditioner  DIC;
    }

    pcorrFinal
    {
        $pcorr;
        relTol          0;
    }
    
    "h.*"
    {
        solver          smoothSolver;
        smoother        symGaussSeidel;
        tolerance       1e-6;
        relTol          0;
        maxIter            0;
    }

    "(U|k|epsilon|omega)"
    {
        solver          smoothSolver;
        smoother        symGaussSeidel;
        tolerance       1e-6;
        relTol          0;
    }

    "(U|k|epsilon|omega)Final"
    {
        $U;
        tolerance       1e-6;
        relTol          0;
    }

    "yPsi.*"
    {
        solver          PBiCGStab;
        preconditioner  DILU;
        tolerance       1e-5;
        relTol          0.0;
        minIter            1;
    }

}

PIMPLE
{
    momentumPredictor   no;
    nOuterCorrectors    2;
    nCorrectors         3;
    nNonOrthogonalCorrectors 1;
    moveMeshOuterCorrectors yes;
    turbOnFinalIterOnly no;
    
    consistent            no;

    oversetAdjustPhi    yes; //replaces ddtCorr, correctPhi and massFluxInterpolation
    
     residualControl
    {
        "p.*"
        {
                tolerance  1e-5;
                relTol      0;
        }

     }
}


relaxationFactors
{
    fields
    {
        "p_rgh.*"       1;
    }
    equations
    {
        "U.*"                1;
        "k.*"                 1;
        "epsilon.*"         1;
        "omega.*"             1;
    }
}

cache
{
    grad(U);
}

fvSchemes

Code:

ddtSchemes
{
    default         Euler;
    //default         backward;
}

gradSchemes
{
    default         Gauss linear;
    limited            cellLimited Gauss linear 0.5;
}

divSchemes
{
    default         none;
    div(phi,U)      Gauss linearUpwindV limited; //Gauss upwind;

    div(phi,epsilon) Gauss linearUpwind limited; //Gauss upwind;
    div(phi,omega) Gauss linearUpwind limited; //Gauss upwind;
    div(phi,k)       Gauss linearUpwind limited; //Gauss upwind;
    div(phi,h)       Gauss linearUpwind limited;
    
    div(phi,K)      Gauss linear;

    div((nuEff*dev2(T(grad(U))))) Gauss linear;
    div(((rho*nuEff)*dev2(T(grad(U)))))    Gauss linear;
    
    div(meshPhi,p)  Gauss linear;
}

laplacianSchemes
{
    default         Gauss linear corrected;
    laplacian(diffusivity,cellDisplacement)  Gauss linear corrected;
}

interpolationSchemes
{
    default         linear;
}

snGradSchemes
{
    default         corrected ;
}

oversetInterpolation
{
    //method          cellVolumeWeight;
    method          inverseDistance;
    //method          leastSquares;

    // The inverseDistance method uses a 'voxel' like search structure.
    // Optionally specify the extent and number of divisions n.
    // Note that it will allocate an array of nx*ny*nz. If not specified:
    // - searchBox          : local mesh bounding box
    // - searchBoxDivisions : root (2D) or cube-root(3D) of number of cells
    //searchBox           (-0.1 -0.175 -0.175) (0.55 0.175 0.175);
    //searchBoxDivisions  (10 10 10);

    //layerRelax 0.5; //control the number of interpolated cells
    
    //allowInterpolatedDonors    false;
    //layerRelax          0.3;
    //holeLayers            3;
    //useLayer            2;// Layer used
    
    
    
    // Faster but less accurate
    //method              trackingInverseDistance;
    //searchBox           (0 0 0)(0.02 0.01 0.01);
    //searchBoxDivisions  2{(64 64 64)};
    //allowInterpolatedDonors     false;
    
}


oversetInterpolationSuppressed
{
    grad(p_rgh);
    surfaceIntegrate(phiHbyA);
}


fluxRequired
{
    default         no;
    pcorr           ;
    p               ;
}


wallDist
{
    method        Poisson;
    //correctWalls    true;
}

dynamicMeshDict

Code:

motionSolverLibs    (sixDoFRigidBodyMotion);

dynamicFvMesh       dynamicOversetFvMesh;

solver          sixDoFRigidBodyMotion;



solvers
{
    
     domain
     {
        motionSolverLibs (fvMotionSolvers);

        motionSolver            solidBody;
        solidBodyMotionFunction drivenLinearMotion;

        cellSet                 c0;
        cOfGdisplacement        CofG;
    }
    



    plate
    {
        motionSolverLibs   (sixDoFRigidBodyMotion);
        motionSolver        sixDoFRigidBodyMotion;

        cellSet         c1;
        cOfGdisplacement    CofG;

        patches         (plate);
        innerDistance   1e3;
        outerDistance   1.5e3;

        centreOfMass    (0 0 20);

        //rho rhoInf;

        //rhoInf 1;
        

        // Cuboid mass
        mass            21.25;  //mass minus the buoyancy of the body
        
        g (0 0 -9.81);
        
        velocity        (0 0 -5);
        
        momentOfInertia (1.40625 0.71015 0.71015);

        report          on;
        accelerationRelaxation 1; //0.5; // for newmark
        accelerationDamping    1; //0.8;

        solver
        {
            type Newmark;
        }

    
        constraints
        {
            /*
            line_restraint
            {
               sixDoFRigidBodyMotionConstraint   line;
               direction                              (0 0 1);
            }
            
            orientation_restraint
            {
                sixDoFRigidBodyMotionConstraint   orientation;
            }
            */
            
        }
    
    }
}

Sorry for the messy post

but I wanted to have some written record as much for me as for others. This is all based on my recent experience with overset simulations and whatever I could find online, so take it with a grain of salt!

I will be happy to hear from others about recommended practices overset computations and moving domains. There are a lot of settings I have not yet tested, such as the ddtScheme. Hopefully I will update this thread with more detailed information as I learn more about it.

I am doing similar overset problem of Vortex induced vibration of cylinder in 3D. But I am using following part:
PIMPLE
{
momentumPredictor true;
correctPhi true; //true;
//oversetAdjustPhi false;
nOuterCorrectors 50;
nCorrectors 5;
nNonOrthogonalCorrectors 2;

//ddtCorr false;

//checkMeshCourantNo yes;
pRefCell 0;
pRefValue 0;
moveMeshOuterCorrector yes;
residualControl
{
p
{
relTol 0;
tolerance 1e-5;
}

U
{
relTol 0;
tolerance 1e-5;
}
}
}
After every 50 outer iterations it is not converged. Is it something to do with momentumPredictor? Thanks in advance

Alczem · April 22, 2024, 03:48

Hey!

Could you share the case? It may have to do with your max Courant number, the mesh or maybe the schemes. People can have a look and maybe find out the issue.

Redrakham · April 23, 2024, 01:32

The case is attached.

January 12, 2024, 11:41		#2
NotOverUnderated Senior Member ONESP-RO Join Date: Feb 2021 Location: Somwhere on Planet Earth Posts: 127 Rep Power: 5	Hi, Thank you for sharing this. This is certainly very helpful. I have some questions about some dictionaries in your fvSolution files: 1) Why you are using a small number for nOuterCorrectors? I read somewhere here in the forum (here: https://openfoamwiki.net/index.php/O...hm_in_OpenFOAM) that you must use a large number. Code: nOuterCorrectors 2; // I think this should be a large number like 30 2) This is a followup question from the question 1): Code: nOuterCorrectors 2; ... ... residualControl { "p.*" { tolerance 1e-5; relTol 0; } } - What is the point of using residualControl in this case when you are using only 2 nOuterCorrectors? as far as I understand the residualControl dictionary controls the number of outer correctors: The solver will do nOuterCorrector iterations unless the initial residuals of the fields satisfy the tolerance specified in residualControl. Kind regards __________________ Don't keep making the same mistakes. Try to make new mistakes.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Periodic Pressure drop	cfd_begin	CFX	10	May 25, 2017 07:09
Domain Imbalance	HMR	CFX	5	October 10, 2016 05:57
Floating point exception: Zero divide	liladhar	CFX	11	December 16, 2013 04:07
Moving elemnt in the domain	kekko	CFX	3	February 21, 2007 16:17
Saving data at a point in moving domain	sawa	FLUENT	0	February 19, 2006 09:31

January 15, 2024, 05:54		#4
Alczem Senior Member Join Date: Dec 2021 Posts: 207 Rep Power: 5	Hey! About the nOuterCorrectors set to 2, I found out that letting the solver converge with nOuterCorrectors set to 50 and residualControl versus having a fixed number of loops (2 or 4 in my case) made almost no difference in the computed position and velocity after 1 second of simulated time. I should add that I found a a tutorial by Alletto, investigating the Newmark and symplectic solvers for oversets, and it also uses a fixed number of loops for Newmark, which gave me confidence in using 2 loops. Here is his collection of tutorials: https://wiki.openfoam.com/Collection...ichael_Alletto You are right that using PIMPLE and residualControl would usually result in a few iterations to converge (more are needed with a tighter tolerance of course). But since I used moveMeshOuterCorrectors, additional loops are more expansive than usual. That is why I stuck with 2 loops, but I agree that if you need the best accuracy regardless of runtime, having PIMPLE manage the number of loops is the way! The residualControl subdictionary in my fvSolution is just there so I didn't have to re-edit the file when I was trying things out. It does not prevent the simulation from running even if it does not converge each timestep. I have not properly tested the ddtSchemes, I hope I will have some time to compare the different schemes. But similar to the nOuterCorrectors discussion, the settings I shared are meant to be a compromise between accuracy and cost, since overset simulations are so heavy (As additional info, my test case was a plate falling with an initial vertical velocity in water, and I monitored the position and velocity after 1 second. This may not be chaotic or long enough to see the differences in accuracy when using more loops or different schemes though)

January 16, 2024, 05:12		#5
Alczem Senior Member Join Date: Dec 2021 Posts: 207 Rep Power: 5	Quick edit about the velocity boundary condition for the domain boundaries: I used zeroGradient, but running the simulation for a longer time eventually created some kind of succion effect at the "inlet" (the bottom boundary since my body is falling). My understanding is that the fluid getting pushed downward by the falling body reaches the zeroGradient boundary, which registers this downward current and keep applying this downward velocity, resulting in a succion instead of an immobile fluid. As a a fix, I tried to enlarge my background mesh, with better results, but whats seems to be best is to use an inletOutlet condition with inletValue set to (0 0 0) for all the boundaries that allow the fluid to enter or leave freely. That way, the fluid is introduced into the domain with a null velocity (duh, I don't know how I missed that, it is also similar to the rigidBodyHull tutorial for the interFoam overset solver). With this change, results are similar between a cube falling with a fixed background mesh and a cube falling with a moving domain linked to it (terminal velocity and forces are equal), though the background mesh for the moving domain still needs to be large enough to mitigate any boundary effect on the moving body.

March 26, 2024, 09:45		#6
Karim ahmed New Member Karim Ahmed Join Date: Nov 2017 Posts: 3 Rep Power: 8	Hello Alczem , Thank for this useful informations. can you please provide the 0 folder , just to check the BC , i am trying to solve something near this case and i want to check my BCs thanks in advance

April 22, 2024, 03:48		#9
Alczem Senior Member Join Date: Dec 2021 Posts: 207 Rep Power: 5	Hey! Could you share the case? It may have to do with your max Courant number, the mesh or maybe the schemes. People can have a look and maybe find out the issue.