Thanks guys, that was fast and helpful!

Although the interpolation is already given now, I will have a closer look into freeSurface.C.

At the moment I'm trying to figure out which of the mesh motion solvers fits my needs best. laplaceFaceDecomposition seems to be used quite often, although I'm not sure if its fast and really works in parallel. If I remember right, I already discussed some bugs with deepsterblue. So far, I tried displacementLaplacian, but already encountered problems with distorted meshes - which of course led to a crash.

Thanks again,
Arne

Hi Arne

My pleasure.

My experience with the mesh motion and morphology/scour is that you need to use laplaceFaceDecomposition, as non of the other methods actually gives you a solution in the boundary layer, which does not invalidate the mesh - even if you constraint the mesh Courant number to say less than 0.2.

- Niels

Hi all,

again a question regarding the mesh motion and now esp. the mesh Courant number is coming up:

For long-term simulations of sediment movement and therefore mesh deformation I'm using a procedure of

1. calculate and store the flow and stress field etc. in defined time steps for lets say a period of 1 second
2. loop over the stored flow field values several times (so x times 1s) and solve the sediment transport equation + move the mesh (by modifying motionU bottom boundary patch and updating the mesh afterwards).

The mesh Courant number is calculated each time after the mesh is updated. What I get here, and don't really understand is that the mesh Courant number rises from updating to updating time step within the loop.

I guess that I missed something in the updating process, but am not sure what it is. So is there enything else necessary besides:

- motionU.boundaryField()[patchi] == motionUInterpolator.pointToPointInterpolate();
- mesh.update(); ?

I tested this as well by modifying the interDyMFoam solver by adding a loop over mesh.update() several times. The mesh courant number rises here as well:

Any explanations?

Arne