deformable outlet crash. 3dTube based. preCICE.

[SvensenSeven]

According to your suggestion #363 I've changed the mesh motion solver to ElRBFMeshMotionSolver. Yes, simulation runs OK.

The next step for me was to setup a case in such a way that outlet patch could also be deformed by the fluid flow. In #355 you've suggested that:

sure, you'll have to change the boundary conditions for the solid in solid/0/U. The fluid mesh should also be allowed to move I guess. Right now, it is a fixed patch in fluid/constant/dynamicMesh, and should be a moving patch.

The brief summary of changes is listed below:
fluid/0/U -> outlet type myMovingWallVelocity
fluid/constant/couplingProperties -> movingFluidPatches (wall outlet);
fluid/constant/dynamicMeshDict -> movingPatches ( wall outlet);

solid/0/U -> outlet type solidTraction
solid/couplingProperties -> movingFluidPatches (wall outlet);

However, first step runs OK (outlet patch is really deformed), but on the first iteration of second time step the simulation crashed with floating point problem for fsiFluidFoam. The Courant number for the first time step was about 0.13, on the second step it is about 2. I've tried to add the relaxation factors for fluid solver: 0.3 for p and 0.7 for others. The time step is already very small - 1e-4.
Nevertheless, the simulation still crashed on the first iteration of second time step.

Maybe a mesh at the outlet patch deforms in such a way that it produces the cells with a high Courant number ?

The project file is here: https://yadi.sk/d/LedohW4iwBUQk

[davidsblom]

Hi!

So I guess that the under relaxation factors are not applied by the fluid solver. foam-extend uses the following way to set the underrelaxation factors:

relaxationFactors
{
    U 0.9;
    p 0.9;
}

Also, the fluid solvers has quite a large residual in my opinion. So you could consider using a stricter relTol for the PIMPLE settings. I've relaxed the maxIter a bit, otherwise a fluid solve could take forever if it is stalling.

PIMPLE
{
  nCorrectors 10;
  nNonOrthogonalCorrectors 0;
  tolerance 1.0e-7;
  relTol 1.0e-5;
  maxIter 20;
  minIter 1;
  pisoTol 1e-3;
}

[davidsblom]

I've just checked the meshes, and you're using non conforming fluid and solid grids. In that case, it is advised to use consistent interpolation between the fluid and solid grids as shown here:

https://github.com/davidsblom/FOAM-FSI/blob/master/tutorials/fsi/3dTube/fluid/constant/preCICE.xml

(Note that I've just updated the file yesterday. Refer to commit 384bb40 to see the changes.)

[SvensenSeven]

I've changed the solid mesh according to your remark. Now both meshes are conforming.
Also I've changed the relaxation factors and settings for relTol and maxIter. preCICE.xml was also modified.
However, now the simulation crashes just at the beginning. A tons of "eigenvalue" problems are appeared in solid solver. I've just noticed that you've already post some remark #367, that due to the recent changes in preCICE the fields should be initialized:

Note that it is necessary to initialize the displacement and/or pressure, otherwise the selected coupling method / post-processing scheme starts with a zero initial guess. This results in crashing of the solvers.

In my case the pressure field is already initialized by pimpleFoam. It seems that I also should initialize the displacement. However you wrote "and/OR". Therefore I've thought that initialized pressure field would be enough. But the simulation crashed. So, my question is: is there a way to initialize the displacement for solid ?

The project file and logs for fluid and solid solvers is located here: https://yadi.sk/d/DwTWDKEjwEHCt

[davidsblom]

Nice that you've changed the meshes to be conforming. I haven't had the time yet to look at the problem. I'll take a look at it tomorrow, and let you know how it goes.

What I meant with the initialization of the displacement and/or pressure, is of importance when a simulation is restarted. With precice, you can configure whether a variable should be initialized or not. In case of a restart, the displacement needs to be initialized in all cases. The pressure needs to be initialized when the fluid and solid solvers are coupled in parallel (solid solver is not waiting for the fluid solver).
I don't think this is of importance for the problem you're currently having. I'll let you know tomorrow .

[davidsblom]

Just looked at the test case again, and I noticed that you use the myMovingWallVelocity boundary condition for the velocity. That is correct for a moving wall, but here it is moving, but an outlet instead of a wall. The boundary condition applies a no-slip condition for a moving wall, so it is not appropriate here.

I guess that the zeroGradient boundary condition is more suitable here. It should not give any problems when the outlet is moving, as far as I can see.

You should first rerun the pimpleFoam solver, and then try again 👍

Also, when the solid solver is still crashing, you could try to use more relaxation for the structure solver. So set the relaxation factor to 0.1 for example in solid/system/fvSolution.

[SvensenSeven]

Thanks David. Now the simulation works without crashes. I've simulated the first 80 steps and now I'mlooking on the results. For solid part, it seems to be OK. However for the fluid region the outlet segment deforms a little bit strange. It is difficult to describe by words, please just look on the video fluid_internalview.avi. Is it a correct behaviour for fluid outlet?

The videos and project file are located here: https://yadi.sk/d/kO6ONHrswQtjm

[davidsblom]

This strange behaviour at the outlet is most probably caused by the fact that the displacement of the outlet is not well defined. The RBF mesh interpolation interpolates the displacements from the wall, and inlet (fixed) to the outlet. This is only based on interpolation, and not on physical constraints. I'm not really sure what would be a good solution here.