GitLab

Summary

The dynamicFvMesh type named dynamicMotionSolverListFvMesh produces unexpected mesh displacement when two or more motion solvers with non-zero displacement are included in dynamicMeshDict. The explanation would be an incorrect displacement value attribution in the code in dynamicMotionSolverListFvMesh.C.

Steps to reproduce

Applying two or more different solvers in dynamicMeshDict with non-zero displacement components may already cause the issue.

Example case

The attatched example case illustrates the displacement miscalculation, and can be run by tiping:

1. blockMesh
2. moveDynamicMesh
3. paraFoam

What is the current bug behaviour?

The example case shown in the attatched file, which presents constant mesh movement speed for both x and y axis, moves the mesh in the expected direction and with desired displacement variation, but only in alternated time steps. During the other timesteps the mesh is kept almost unchanged, hence halving the expected total displacement for a larger number of time steps. More complex movement cases move the mesh in more unpredictable ways.

What is the expected correct behavior?

For the attatched case, points in the mesh should move 0.2 m in both x and y directions for every 1 s time step.

Environment information

• OpenFOAM version : v1912
• Operating system : ubuntu
• Hardware info : Dell Inspiron 14
• Compiler : gcc

Possible fixes

The problem was found to be in the Member Function of the code dynamicMotionSovlerListFvMesh.C (located in src/dynamicFvMesh/dynamicMotionSolverListFvMesh), more precisely at lines (123 to 130), as shown bellow:

    pointField disp(motionSolvers_[0].newPoints() - fvMesh::points());

    for (label i = 1; i < motionSolvers_.size(); i++)
    {
        disp += motionSolvers_[i].newPoints() - fvMesh::points();
    }

    fvMesh::movePoints(points() + disp);

For every motion solver, the code extract the difference between its result and the current mesh, sum all the results and add that value of displacement to the current mesh points, returning then the new mesh position. The problem is that every motion solver moves the mesh independently of other solver and its result is the respective displacement in relation to the initial time instant. Thus subtracting its result from the current mesh (which is a combination of the movement of all solvers) produce an incorrect mesh displacement. A possible correction would be adding a pointField type variable (hereby named initialMesh) to which the mesh point coordinates of the initial time instant of the simulation is atributed. The new code would be:

    pointField disp(motionSolvers_[0].newPoints() - initialMesh);

    for (label i = 1; i < motionSolvers_.size(); i++)
    {
        disp += motionSolvers_[i].newPoints() - initialMesh;
    }

    fvMesh::movePoints(initialMesh + disp);

exampleCase.tar.gzg