Nearest-neighbor mapping | 3 mesh

Hi,

I am trying to use two patches as interfaces for my fluid simulation in OpenFOAM.
Here you can find my preciceDict with the two patches.

Next step would be to adjust the precice-config.xml. My problem is to understand how to map the displacement and the forces. In a example, I’ve found, there was the force and the displacement mapped between the solid and the fluid solver.

Now I have 2 interfaces at the fluid simulation and one at the FSI simulation. The aim would be to “combine” the 2 interfaces of the fluid simulation to one.
I would like to map like this (but I think this will not work):

<mapping:nearest-neighbor direction="write"  from="Fluid-Mesh-Up"
        to="Solid-Mesh"
        constraint="conservative"/>
<mapping:nearest-neighbor direction="write"  from="Fluid-Mesh-Down"
        to="Solid-Mesh"
        constraint="conservative"/>
<mapping:nearest-neighbor direction="read"  from="Solid-Mesh"
        to="Fluid-Mesh" constraint="consistent"/>

Do you have any advice, how to map the two patches together correctly?

It is a bit vague what you want to do. Do you want the displacements/forces to be added, subtracted…? What data is mapped from where to where? What happens with the forces/displacements when they are communicated in the opposite direction? What data is mapped from which interface to which other interface?

I worked on an application with similar setup that was discussed here and here. This ultimately led to the implementation of the “Multiple mappings to and from a mesh” feature by the preCICE team (thanks again for that). This feature might be interesting for you. You could also (artificially) create two meshes for the solid solver, e.g., Solid-Mesh-Up and Solid-Mesh-Down.

Edit Just as an addition. You could also merge your fluid meshes into one Fluid-Mesh instead of have a Fluid-Mesh-Up and Fluid-Mesh-Down. I assume that is not possible for your application/setup, but it is hard to tell what you want to achieve.

I assume, that if I divide a airfoil (2D) in two parts, I have to add the displacements forces, to consider them as one airfoil together, am I right?.

The aim is to map forces from the fluid simulation to the FSI simulation and recieve displacement back.

This will not work, since my FSI simulation requires force input.

Originally, my body in the fluid simulation (2D airfoil) consisted of one interface and the solid simulation also had one interface. Because the model in the fluid simulation is divided into two patches, the simulation crashes. I want to solve this issue by creating two meshes (seperate one for every patch in the fluid simulation). The aim is to map the same data (force from fluid to solid an displacement back), but from two meshes to one mesh.

The link you provided sounds promising :+1:

I have tried using just one fluid-mesh for the two fluid patches. Using OpenFOAM, it resulted in this weird behaviour during a externally imposed rotation (counter-clockwise):
3
You can see the left and the right boundary of the arifoil, which are both seperate patches. They are both linked to the same mesh. Unfortunately, the left patch gets overlapped by the right patch, which shouldn’t happen. The expected behaviour would be a consistent rotation of the body without deformation of the patches.

Edit: When trying @ajaust’s proposed solution of “Multiple mappings to and from a mesh” feature by the preCICE team, I’m getting the following message:

---[precice] ERROR:  There cannot be two mappings to mesh "Solid-Mesh" if the meshes from which is mapped contain duplicated data fields that are also actually mapped on this participant. Here, both from meshes contain data "Force". The mapping is not well defined. Which data "Force" should be mapped to mesh "Solid-Mesh"?

Have I understood this correctly?:

  • I can map data from one mesh to two other meshes.
  • I can not map data from two meshes to one other mesh.

Now how does someone map data from two meshes to one other mesh?
Do I have to give the data two different names and handle the problem in the recieving solver (add / subtract them)?
Or is there another solution?

That you should know as it depends on what is a “positive” direction for you and whether quantities need to be summed up or subtracted. However, I guess you should sum up forces if you model your airfoil in 1D. For the displacement it depends on your model I assume. Are these separate displacement for the top and bottom side of the airfoil or is the displacement the same for both sides? (see also below)

I was vague here. Sorry for that. What I meant, understand so far is that you want the data exchanges.

  1. Fluid (top and bottom) → Solid: Effective forces.
    • What you seem to want is Forces=Forces_Up + Forces_Bottom
  2. Solid → Fluid (top and bottom): Displacement
    • Here it is unclear to what you want. Will the top and bottom side get the same displacement such
      1. that Displacement_Fluid_Up=Displacement_Solid and Displacement_Fluid_Down=Displacement_Solid
      2. or do we need to split the displacement into two parts such that Displacement_Solid = Displacement_Fluid_Up+Displacement_Fluid_Down

Maybe we should draw a picture for this.

The case 2.1 is supported by the “Multiple mappings to and from a mesh”. If you need case 2.2 it becomes complicated, because it would not be clear how to split the displacement.

Yes that is correct. In this case the data from the single mesh is duplicated/replicated to the two other meshes.

You can map from two meshes to one other meshes using a summation (make sure the signs of your quantity make sense) operator using Python actions. For an example configuration you need to check the pull request that is mentioned in the news. There are some limitations on the mapping types (read/write, consistent/conservative), but this is not a problem if you have matching grid points in the used meshes. I guess you lack the definition of this action which gives you the error:

I am trying to use the same mesh for both airfoil parts, therefore the displacement should be the same.
→ case 2.1

:white_check_mark:

I was thinking this addition can be made by preCICE. Now I have solved it by splitting the displacements in two and passing them to every patch (of the 2 patches) seperatly in the fluid simulation.

Does this mean it works for you know? It sounds to me like you have very much the same use case that I had. Especially, if you have matching mesh points.

The rationale of summing data within preCICE was the following

  1. It reduces the amount of data points one has to run the acceleration schemes which can improve the coupling stability and/or reduces the number of iterations needed. It also potentially decreases the number of data points that have to be communicated between the solvers.
  2. It works also for parallel execution. If you add the data up manually in your solvers that is fine. We did it in our work as well. However, that becomes a problem if the solver adding the data is run in parallel. In that case, there is no guarantee that the ranks of the solver have data from both sides that has to be added.

Yes it is working now (I am having a new OpenFOAM issue, which does’t fit into this thread :laughing:)
I was getting this error

because I was mapping displacements from one mesh (solid simulation) to two meshes (fluid simulation), which again mapped the forces back from two meshes (fluid simulation) to one mesh (solid simulation), wich is illegal in preCICE.
I was solvig this by just passing the displacement as mentioned above, but sending a seperate force from each fluid mesh to the solid mesh (and adding them in the solid simulation).

So do you think this can lead to trouble, executing this case in parallel, since I am adding the forces in the solid simulation manually? You mean since my displacement is the same in both meshes, I can just swap over my coupling an instead pass the displacements seperatly and send the forces from two meshes to one mesh?

Great that it works!

Still. Mapping from two meshes to one, using a meaningful operator, and from one mesh to two, replicating information, is legal in preCICE 2.2.0 and newer. However, you have to respect the current limitations and the proper preCICE configuration that is explained in the pull request I had linked earlier. If your simulation works for now, I would not worry for the moment. Look into that again if it becomes a problem later.

I have drawn a figure of the situation that can occur if the solver are executed in parallel in the other thread (last figure). In the case pictured there it is not so straightforward to add up data. However, again, if it does not bother you at the moment I would keep it in mind and look into that when it becomes an issue.

Since the initial problem has been solved we can keep this thread marked as solved and if you run into another issue you can open a new thread.

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.