I use nearest neighbor mapping to exchange data between fluid (OpenFOAM) and solid (python code). The fluid mesh use 9 nodes in the vertical direction, and the solid uses 5 nodes only but they are exactly a subset of the fluid nodes.
The conservative mapping seems wrong in two aspects (Figs 1 and 2).
the right nodes do not get data from the fluid. (Fig. 2)
the left nodes only get the data from its neighbors but no data from itself (the same location of fluid mesh). (Fig. 2) For example, the data 2.0 boxed in Solid Mesh of Fig.2, should be (0.2+1.0+2.2)=3.4, and all the other values at solid nodes should be calculated the same way.
The consistent mapping (Figs 3 and 4) looks reasonable, but the error looks large. I expect the consistent mapping gives the exact the same value if the coordinates of the fluid and solid nodes are the same.
Please note I deliberately move the left nodes in the solid mesh a little bit for testing. It seems the nodes of solid Mesh which are closer to the face center can receive the data, because the fluid data(force) are located at the face center.
If “mapping:rbf-thin-plate-splines” is used, the results are ever worse. If I decrease the dimension of y direction which only has one cell, it improves, but still not good. Setting y-dead=“true” does not help.
In the documentation, it is clear and easy to understand how the data are mapped from finer mesh to coarse mesh. However, it will be very helpful if this is illustrated in 2D fashion.
For example, in the configuration figure above, how are ‘S1’ to ‘S4’ calculated from the data of ‘F1’ and ‘F2’ when using consistent and conservativenearest mappings?
On the contrary, how are ‘F1’ and ‘F2’ calculated if ‘S1’ to ‘S4’ are known?
I am not sure I understand the setup and the question. Do you mean why the spheres on the right all have value (0.0 0.0 0.0), while the spheres on the left have some correct values?
If you are reading from the grid (Fluid) to the spheres (Solid), then every sphere should get a value.
If you are writing from the grid to the spheres, then maybe these nodes are ommitted.
But I am starting to get dangerously confused myself here, so maybe @uekerman may be able to confirm.
I am still not very clear about the mapping direction. Suppose I need to read force from Fluid to Solid. Do I need to set both mapping directions in both participants as follows?
Please note the differences to your configuration:
In both cases, I removed one redundant mesh.
I made the mapping conservative as you want to map forces.
For participants running in serial, both configurations are valid. As soon as you run in parallel, only the first one (mapping on Fluid) is valid as conservative mappings always have to be write mappings. More information: Mapping configuration | preCICE - The Coupling Library
Don’t forget to also adjust the mesh over which you exchange in the coupling scheme if you change from one option to the other.
I must admit I was not able to fully follow the discussion above. I don’t think that there is an actual bug, but there seems to be a misunderstanding. In case the explanation here did not help already, please attach your preCICE configuration file and vtk files for both meshes (Exports configuration | preCICE - The Coupling Library).
Hi @uekerman,
I have a quesiton about the read and write in the configuration file.
For the perpendicular-flap case in preCICE tutorials, the mapping is defined only on the fluid side with both read and write. precice-config.xml (2.4 KB)
However, as for the multiple-perpendicular-flaps case, the mapping is defined on both solid and fluid sides. Besides, only read is used in the mapping. precice-config_multipleFlaps.xml (4.6 KB)
So I guess in the mapping configuration, read on the fluid side is the same as write on the solid side, right?
Yes. Here, the read mapping is consistent (to map displacements) and the write mapping conservative (to map forces).
Here, all mappings are consistent (to map stresses or displacements).
Correct. This is a choice the user can make. As pointed out above, if you run in parallel, there is only one good choice (read for a consistent mapping, write for a conservative mapping).
Try to use the config visualizer. It often helps to understand these things.
Hi @uekerman,
Thank you for your explanation! That helps a lot and gives me the guideline when defining the mapping.
Regarding your comments on redundant mesh. I hope you can confirm or correct my following understanding:
If the data exchange is one way, only the participant who is responsible for the mapping uses all the meshes involved, the other participant only uses its own mesh.
If both participants want to read and write data from each other, then they use both meshes.
The first configuration means: Fluid first maps data from Fluid-Mesh to Solid-Mesh, then Solid obtains the data directly from its own mesh, i.e., Solid-Mesh. Data is actively transferred by Fluid, and Solid ** passively receives the data.
Is it correct?
On the other hand, the configuration below means: Solid fetches data from Fluidactively, and Fluid passively gives data to Solid.
So, regarding the data exchange, the two configurations are equivalent. The only difference is which participant initiates the exchange and is responsible for the mapping. Is it correct?
This breaks up the procedure of data mapping and exchanging and makes things easier to understand. I think I was confused with Fluid and Fluid-Mesh. They have different responsibility during the mapping and exchanging. Reading the Step 1 a few more times does help understand the logic.