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 pointDisplacementfile), 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:
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.
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
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.
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.
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
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?
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.
