Does preCICE rely on mesh coordinates or topology for coupling data mapping?

I am working on FSI simulations involving a rotating wind turbine rotor using OpenFOAM (with AMI) coupled to a structural FEM solver via preCICE.

I am exploring the possibility of keeping the structural mesh fixed in its reference frame, while still accounting for the rotor’s rotation by simply rotating the applied loads coming from the fluid solver.

This idea is based on a principle from finite element theory: as long as the relative positions between nodes remain constant (i.e., the mesh undergoes rigid-body motion such as a rotation or translation), the stiffness matrix does not change. Thus, by only updating the external load vector (e.g., rotating it appropriately each timestep), I could simulate structural response to a rotating flow field without physically rotating the structural mesh or recomputing the stiffness matrix.

My question is related to how preCICE handles the mapping of data between the solvers:

Does preCICE rely solely on spatial coordinates at every timestep to perform data mapping, or does it retain the correspondence between mesh nodes (e.g., via IDs) after the initial mapping?

In other words, suppose that in timestep 0 both meshes (fluid and structure) are aligned in space, so preCICE performs a mapping and establishes a set of node correspondences. Then, in timestep 1, if the fluid mesh has rotated but the structural mesh remains fixed, would preCICE re-map based on the new spatial positions, or would it reuse the initial correspondence?

Understanding this would help me decide whether I can implement this rigid-body motion approach on the structural side, without physically rotating the mesh.

I am currently using a custom FEM solver, but I would also consider using CalculiX if such a synchronization strategy were possible.

Hi,

Before answering, I would like to forward you to this page in the documentation:

I think this should answer all of your questions.

Please let me know if there are still open questions, this way I can give you a more targeted answer and improve the documentation at the same time.

Best regards
Frédéric

Hi @fsimonis,

Thanks for your reply. I just realized that the new version of preCICE includes features that are quite relevant to my case. As I understand it, remeshing seems to be the most suitable approach for my problem, since it would allow me to rotate the FEM model by remeshing at each time step. However, this comes with a significant computational cost, which I’m trying to avoid.

I might not fully understand the concept of just-in-time mapping or the pseudo-reference domain. In my case ()HAWT, the mesh in both domains are rotating, but there is no relative motion between them, so in such point of view the meshes are static.

I have limited computational resources, so my goal is to reduce the computational cost as much as possible. That’s why I considered keeping the solid mesh static — since, from a mathematical point of view, I believe the results would be equivalent — and instead mapping the loads from the rotating CFD domain.

I also thought about implementing some kind of “man-in-the-middle” dummy solver to handle the mapping, since preCICE mapping is, by far, less computationally expensive than solving the structural or fluid domains, so the bottleneck wouldn’t be in the mapping itself.

Could you give me some advice on how to proceed? Specifically, which of the new preCICE features could help me reduce computational costs in this setup?

Best regards,
Eduardo