Deformation issue using preCICE and OpenFOAM

Using preCICE
, ,
#1

Hi everyone,

trying to couple a rotation movement with preCICE in OpenFOAM, I am facing the following problem:
Rotating a body using a Rotation Matrix (and displacing the body respectively with preCICE), the body starts deforming at the boundary of the patch, shaping the boundary “wave-like” (from this to that state).
Executing the same movement just with OpenFOAM (using angularOscillatingDisplacement in the pointDisplacement file), the body rotates normally without deformation.
A video of the motion can be found here.

To reproduce the issue, I have uploaded the case to Github:

1 Like
#2

Addition: In the case I have presented above, the airfoil is divided into two patches along the midline. Replicating the case with one continuous patch, the deformation issue doesn’t appear. Therefore I think the problem must be multi-body related.

#3

@JulianSchl you are using a nearest-neighbor mapping in your preCICE config. This is the simplest/cheapest, but also least accurate mapping technique, which can lead to such issues. Better switch to e.g. an RBF-based mapping: Mapping configuration | preCICE - The Coupling Library

1 Like
#4

@JulianSchl did using a different mapping method solve this issue?

#5

Hi @Makis,

I’ve tried rbf-thin-plate-splines mapping (see this issue) and the case is (as far as I can tell by now) working quite well.

Nevertheless I think my approach for RBF is not correct. I am mapping data from a beam (1D line of points) to a OpenFOAM patch (2D). Normally this wouldn’t work with RBF, because of the 1D beam. Therefore, I’ve just copied the beam 10 times in parallel. With this approach, I am getting better mapping, than with nearest-neighbor mapping.
If you have any suggestions to improve this “shady” approach, I would be glad to see them :slight_smile:

#6

Have you tried restricting some directions, e.g. with the z-dead="true"? Mapping configuration | preCICE - The Coupling Library

#7

Since it is a 2D-case in the x-y plane, I am setting the z-axis to “dead”. But for the beam (1D) I have to deal with the other dimension (y-axis), which is why I came up with the copying approach.

#8

I am not completely sure I understand this copying approach.

In any case, before we also had tutorials similar to what I understand is your case (1D interface for a pseudo-2D flap in a pseudo-2D flow) and we also had issues with RBF. This is why we have now introduced a 2D mode in many adapters, including OpenFOAM, CalculiX, and deal.II. With this, preCICE can treat the pseudo-2D solvers as 2D, since they both only define one line of points.

If you set <solver-interface dimensions="2">, then OpenFOAM will automatically only define one line of points as the interface (ignoring the z-axis). Edit: I see that this is what you are actually doing already. Maybe I need a figure to understand the case setup.

#9

Indeed I am already using <solver-interface dimensions="2">.

I have drawn a little figure to explain the setup:

Unbenannte Präsentation (3)
Unbenannte Präsentation (3)960×540 27.2 KB


If you have any questions feel free to ask :slight_smile:
1 Like
#10

The extrusion can make some sense to overcome the fact that you map between a 1D and a 2D representation. We recently used a similar approach here: https://www.scipedia.com/wd/images/d/d3/Draft_Content_133641963p2530.pdf
A more rigorous approach is work in progress in preCICE. @Makis is the right person to talk to :grin:

#11

I was also thinking in the same direction, although I understand that the problem here is a bit different.

Just to explain the situation in the linked paper, and in particular Figure 3: the 1D code defines different “panels” (zones of different material properties), so we needed a system to also restrict the mapping to the right panels. Mapping from the 3D mesh to the intermediate grid was as usual, but mapping from the intermediate grid to the 1D mesh also involved a conversion step for variables (this is what we are particularly interested in for the geometric multiscale mapping).

Do I understand correctly that the beam is the internal structure of the airfoil? Then you need that multiple fluid nodes (left and right of the beam) get deformation values from the beam, which starts indeed to look a lot like a 1D-3D radial-spread mapping (in our terminology).

This seems to work already for you for nearest-neighbor (with some hard-coding for this case, I assume), but you have issues with the RBF mapping. But then, @uekerman, isn’t it exactly the case we had with the previous pseudo-2D tutorials?

#12

not sure.

@JulianSchl Could you please export the vtk of both interface meshes? That would help to better understand the problem.
https://precice.org/configuration-export.html

#13
  • red: structure mesh
  • blue: fluid mesh

VTK files

mesh
mesh1128×574 10.4 KB

1 Like
#14

As I was writing above, I do not really have issues with RBF mapping, but think that the approach is theoretically wrong.

#15

Update: Changing the mapping between preCICE and the MBDyn-Adapter, I’m getting similar results, but now with a more meaningful mapping:

The structure mesh is generated (interpolated) by the MBDyn-Adapter, using the beam “mesh” of MBDyn, which is more or less a line.

2 Likes
#16

What do you mean “similar results”? What problem is now left to solve?

Any more details / updates would be very welcome.

#17

With “similar results” I mean, that with the extruded mesh and the interpolated mesh, I’m getting the same motion in OpenFOAM (somehow the extrusion was a “hack around”).
Still there stays the issue pointed out in the first post → wrong deformation with two patches. I will inform you when I try the “two patches” case again with the new RBF mesh.

1 Like