[CFD-Henning]

Hey all,
I'm simulating a floating monopile in a numerical wave tank (to extract its heave- and pitch-motion in different sea states). Therefore I'm using OF-1606+ and waves2Foam with dynamic mesh motion. Below is a coarse example of my mesh.
Currently I'm struggeling with a mesh morphing issue:
As you can see, there isn't much space between the pile and the bottom wall, so the mesh motion parameters in this direction have to be chosen very precisely.
With the dynamicMotionSolverFvMesh I can define different parameters for this in the dynamicMeshDict:

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

dynamicFvMesh       dynamicMotionSolverFvMesh;

motionSolverLibs   ("libsixDoFRigidBodyMotion.so");

solver             sixDoFRigidBodyMotion;

diffusivity     quadratic inverseDistance 0.2 ( interface );

sixDoFRigidBodyMotionCoeffs
{
    report          on;
    reportToFile    on;
    
    solver
    {
        type Newmark;
    }

   //accelerationDamping 0.9;

    patches         (interface);
    innerDistance   0.01;
    outerDistance   0.2;

    mass            15.7;
    centreOfMass    (0 0 0.298);
    momentOfInertia (6.34 6.34 2.93);

   
    constraints
    {
        xAxis
        {
            sixDoFRigidBodyMotionConstraint axis;
            axis                (0 1 0);
        }
    LineConstraint
    {
        sixDoFRigidBodyMotionConstraint   line;
        direction          (0 0 1);
     }
    }

}


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

I found out, that the corresponding parameters are: diffusivity (diffusion of the mesh motion through the domain) and the inner- and outer distance (def. of area of mesh motion)
I came up with some issues and questions, which google could not answer and I hope some of you can:

1. The diffusion distance parameter is not working in my case, so only the inner-/outer distance parameters have influence. But I want to manipulate the diffusivity mode. What am I doing wrong?
2. What's the difference between the diffusivity and inner-/outer distance parameters in term of the diffusion distance? In other words, if I'm defining a diffusion distance in diffusivity, why do I need another definition in inner-/outer distance?
3. I want to define different mesh motion distances to the directions (so I can set up just 20cm to the bottom, and way more to the sides). Is it possible to define such a distinction? (not in inner-/outer distance, bc. OF demands a scalar)
4. Biggest issue: I cannot define exactly the distance from the pile bottom to the domain bottom (20cm), bc. OpenFOAM crashes in < 1sec. However, I can define a bit less or more (10cm or 30cm) and this results either in a too big compression of certain cells in this area (10cm) or in an exceedence of the bottom cells out of the domain (30cm) -> both crash. If I could define 20cm, the mesh morphing should perfectly act in this area, but why is this crashing even before some bigger motion occured?

So i would really appreciate any hint to any of these questions.


Henning

[CFD-Henning]

For completeness, if s/o stumbles over the same problems, this i what I found out:

1.) In OF1606+, the diffusion parameter is not looked up, when the solver initializes. As you can see below in sixDoFRigidBodyMotionSolver.H, only "di_" and "do_" matter.
It seems that you cannot decide how deformation is diffused through the mesh (it is a cosine-function, as in point 3 pointed out).

[...]
/*---------------------------------------------------------------------------*\
        Class sixDoFRigidBodyMotionSolver Declaration
\*---------------------------------------------------------------------------*/

class sixDoFRigidBodyMotionSolver
:
    public displacementMotionSolver
{
    // Private data

        //- Six dof motion object
        sixDoFRigidBodyMotion motion_;

        wordReList patches_;

        //- Patches to integrate forces
        const labelHashSet patchSet_;

        //- Inner morphing distance (limit of solid-body region)
        const scalar di_;

        //- Outer morphing distance (limit of linear interpolation region)
        const scalar do_;

        //- Switch for test-mode in which only the
        //  gravitational body-force is applied
        Switch test_;

        //- Reference density required by the forces object for
        //  incompressible calculations, required if rhoName == rhoInf
        scalar rhoInf_;

        //- Name of density field, optional unless used for an
        //  incompressible simulation, when this needs to be specified
        //  as rhoInf
        word rhoName_;

        //- Current interpolation scale (1 at patches, 0 at distance_)
        pointScalarField scale_;

        //- Current time index (used for updating)
        label curTimeIndex_;


    // Private Member Functions

        //- Disallow default bitwise copy construct
        sixDoFRigidBodyMotionSolver
        (
            const sixDoFRigidBodyMotionSolver&
        );

        //- Disallow default bitwise assignment
        void operator=(const sixDoFRigidBodyMotionSolver&);


public:

    //- Runtime type information
    TypeName("sixDoFRigidBodyMotion");


    // Constructors

        //- Construct from polyMesh and IOdictionary
        sixDoFRigidBodyMotionSolver
        (
            const polyMesh&,
            const IOdictionary& dict
        );


    //- Destructor
    ~sixDoFRigidBodyMotionSolver();


    // Member Functions

        //- Return point location obtained from the current motion field
        virtual tmp<pointField> curPoints() const;

        //- Solve for motion
        virtual void solve();

        //- Write state using given format, version and compression
        virtual bool writeObject
        (
            IOstream::streamFormat fmt,
            IOstream::versionNumber ver,
            IOstream::compressionType cmp
        ) const;

        //- Read dynamicMeshDict dictionary
        virtual bool read();
};


// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
[...]

2.) See point 1.

3.) The mesh motion is diffused isotropic through the mesh. You can check this in the according function in sixDoFRigidBodyMotionSolver.C, where the relative distance between di and do is calculated (1 to 0) and put into a cosine function.
If anybody has enough C++-skills to improve this code in such a way that one can set up a three-dimensional vector for di and do and the solver calculates the mesh motion direction-dependent, I would really appreciate it. I could not figure out, how to address vectorial objects in C++ .

[...]
    // Calculate scaling factor everywhere
    // ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    {
        const pointMesh& pMesh = pointMesh::New(mesh);

        pointPatchDist pDist(pMesh, patchSet_, points0());

        // Scaling: 1 up to di then linear down to 0 at do away from patches
        scale_.internalField() =
            min
            (
                max
                (
                    (do_ - pDist.internalField())/(do_ - di_),
                    scalar(0)
                ),
                scalar(1)
            );

        // Convert the scale function to a cosine
        scale_.internalField() =
            min
            (
                max
                (
                    0.5
                  - 0.5
                   *cos(scale_.internalField()
                   *Foam::constant::mathematical::pi),
                    scalar(0)
                ),
                scalar(1)
            );

        pointConstraints::New(pMesh).constrain(scale_);
        scale_.write();
    }
[...]

4.) Primarily, the simulation became much more stable, when I switched most of the div-schemes to Gauss-upwind. Gauss-upwind seems to be "the shit ".
Furthermore, according to snappyHexMesh, increasing the nCellsBetweenLevels from 3 to 10 and reducing all parameters in the snapControls to a minimum helped also a lot.

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

ddtSchemes
{
    default         Euler;
}

gradSchemes
{
    default         Gauss linear;
    limitedGrad     cellLimited Gauss linear 1;
}

divSchemes
{
    default          none;
    div(phi,U)       Gauss upwind;
    div(rhoPhi,U)    Gauss upwind; //Gauss linearUpwind grad(U) 
    div(phi,alpha)   Gauss upwind; //Gauss vanLeer;
    div(phirb,alpha) Gauss upwind; //Gauss interfaceCompression; Gauss linear; schlechter
    div(((rho*nuEff)*dev2(T(grad(U))))) Gauss linear;
}

laplacianSchemes
{
    default         Gauss linear corrected;
}

interpolationSchemes
{
    default         linear;
}

snGradSchemes
{
    default         corrected;
}

wallDist
{
    method meshWave;
}

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

For me, this subject is closed . Nevertheless I would really appreciate any hint to point 3.

Greetings,
Henning