Rotational movements with preCICE and OpenFOAM using solidBody solver instead of displacementLaplacian solver

Hi everyone,

in the FSI interface documentation of the OpenFOAM-Adapter, the displacementLaplacian solver is the only mentioned solver. Having a case, where I want to rotate an airfoil, the displacementLaplacian solver does not fit to this case. Furthermore, I would need the solidBody solver to access the solidBodyMotionFunction rotatingMotion.
Now I am asking you, if there is a way to couple preCICE with the solidBody solver.

To give you an example of my issue:
Here you can see a rotational movement coupled with preCICE an the displacementLaplacian solver. The issue is, that you cannot make big rotations (e.g. 360°) with the displacementLaplacian solver. The simulation crashes after ~85° due to cell crashes. The solution would be to use the solidBodyMotionFunction rotatingMotion, which would rotate the full mesh.

I hope, my problem is expressed understandable, for questions please comment below :slight_smile:

Hi @JulianSchl,

I have not explored which other mesh motion solvers work, so looking into this would definitely be interesting.

Have you considered overset grids, instead? OpenFOAM: User Guide: Overset

This definitely works, as shown in Derek Risseeuw’s thesis: Fluid Structure Interaction Modelling of Flapping Wings | TU Delft Repositories

1 Like

Hi @Makis,

thank you for your reply :slight_smile: !

Overset grids would not solve the problem, as I am having issues rotating bodies with the displacementLaplacian solver and preCICE at big angles (> ~20°). With overset, I still have to rotate the mesh.

The thesis only looks at small rotation angles, I am looking for a solution to couple a rotaing motion with angles up to 360°.

But this is a problem similar as with e.g. car wheel rotating, right? I don’t have any reference, but I thought that it is common to not solve such problems directly (with classical mesh motion solvers), but working around it e.g. with overset grids.

Similarly, in the thesis of Qunsheng Huang (helicopter “CFD/CSD coupling” - essentially FSI, with TAU and CAMRAD II), TAU uses a chimera (overset) grid.

Thesis: mediaTUM - Media and Publication Server
Follow-up conference publication with some fixes/updates: mediaTUM - Media and Publication Server

Hi @Makis and thanks for the tips.
I’m working with @JulianSchl and what we’re looking to do is to impose a solidBody(displacementLaplacian) motion directly from PreCICE. We will use overset once we get the one component mesh moving correctly.
The pointDisplacement imposed by preCICE cannot be incorporated by OpenFOAM as the displacementLaplacian solver does not allow large rotations of a patch and consequently of the mesh: you can see my post and the answer from the developers on this topic.
The solution I rely on for non-coupled cases (i.e.: predefined patch morphing and motion) is to combine a solidBody motion (imposed to a cellZone in dynamicMeshDict) to a displacementLaplacian (imposed through a boundary condition in the pointDisplacement folder. This works well by using the solidBodyDisplacementLaplacian solver, but as far as we understand it preCICE can only impose the motion of the patch (i.e. through the boundary condition in pointDisplacement) and for our motion to work properly we would need to impose, through preCICE, a second (solidBody) motion (in dynamicMeshDict).

Is this something that the preCICE adapter is able to do?

By looking at the code we could not find an implementation and it seemed to be non-trivial to implement it. The “uncoupling” between what is a solidBody motion and what is a deformation could be done using a python script or something similar and should be trivial, but the forcing of a solidBody motion (without knowing a priori what it is, otherwise we can simply using a rotating motion or something similar) would require the preCICE openFOAM-adapter to be able to control such a function…

This definitely reaches the limits of my knowledge on the topic, but here are a few fragments of information that may help:

  1. We currently only consider FSI with a specific surface to couple. We do, however, support reading both pointDisplacement and cellDisplacement on those patches.
  2. preCICE does not need to know if the points lie on a boundary or on a larger part of the domain (e.g. a cellZone). If this is still an ALE approach, then this is not an issue.
  3. we are currently discussing how to implement volume coupling in the OpenFOAM adapter (for CHT, mainly), see first pull request. I guess we could also then extend it to couple cellDisplacement on a volume.

In any case, if most of the adapter helps you already, you could try extending it to support this feature. I will be happy to help to the extent I can here.

1 Like

Is there any example of a case with cellDisplacement? I could not find anyone. And to make it clear: With cellDisplacement you can move the cells instead of the patch?

All examples specify just “displacement” as read data. The adapter automatically switches between pointDisplacement and cellDisplacement, depending on the specified location where we read the displacements (face centers or face nodes): openfoam-adapter/Displacement.C at aab511c0756f9dc50b542d2c9166502b5ee56a9d · precice/openfoam-adapter · GitHub

Thanks @Makis for the support.
As for extending the solver, would be nice, but not feasible within the bachelor thesis of Julian.

1 Like

Just a short update: I’ve created a simple test case for @JulianSchl and he will turn it into a coupling interface to allow controlling the mesh motion through the solidBody (i.e.: what the user usually gives into dynamicMeshDict) part of the solidBodyDisplacementLaplacian solver while letting the pointDisplacement still be handled by preCICE. In other words, the deformation is handled by preCICE and the motion is handled by a solidBody motion.

The coupling will only be achieved through a file that we will create and update (in Python/MBDyn) and read (in OpenFOAM), because we are not familiar with how the communication between preCICE and OpenFOAM is done. We’ve had a quick look at the code, but we get lost into interpolation matrices and pointDisplacement libraries. We only need to uncouple the motion and transfer a septernion to OpenFOAM, which I assume could be done in a few lines of code.

If someone wants to point us in the proper direction we may then actually end up extending the solver.

If you want, I think it would definitely be helpful to meet and I could walk you through the code and we could identify together what we could improve in the adapter documentation. I think that contributing back what you learned would be really great! Just contact me on Gitter or at chourdak at tum.de.