I find the convervative mapping behave oddly for a cylinderal interface. I have a precice coupling for a FSI simulation, the fluid part is simulated by the OpenFOAM and the solid part is simulated by Calculix. Therefore, the “force” variable is exchanged at the fluid side through conservative mapping. I have tried the mapping:nearest-neighbor (
).
In the uploaded figures, the spheres are the points from the solid participant and the triangles are from the fluid part. From the figures, it seems that the mapping does not find the correct nearest points to do the conservative mapping. The consistent mapping, on the other hand, shows correct results.
I have attached the precice-config.xml for your reference (the fluid part are running in parallel with 16 cores). precice-config.xml (2.6 KB)
yes, the point of force are the faceCenters from the openFOAM simulation, which are shown in the figure. the point of displacement are teh faceNodes from the openFOAM simulation, which are at the same height (with exact same z coordiantes) as the nodes from CalculiX. I think this answered your next question.
the entire length(height) of the cylinder is 9.63m, and discretize into 963 segments. I used 16 cores to run parallel simulation and the decomposition is taken for the z axis. So, no. There are a few rings (16 to be exact) belongs to two different partitions.
The diameter of the cylinder is 0.02m, which makes the cylinder a very slender structure.
to be more helpful, I uploaded the blockMeshDict to set up the openFOAM mesh, and the riser.fbd to set up the Calculix mesh. In addition, I upload the decomposeDict to show how to make the partition.
The nearest-neighbour mapping looks correct. In conservative mappings, each input (triangle) is mapped to exactly one output (sphere). In your case, you often run into the situation where 2 nearest outputs are at the same distance to one of the inputs. So you can consider that they are picked randomly.
Nearest neighbour works best with (nearly-)matching meshes. Adjusting one of the meshes to avoid the above case can also solve your issue.
The thin-plate-splines results looks strange though. Could you upload a resulting set of vtu/pvtu s?
This allows us to inspect the geometry and data more closely.
you probably right for the nn mapping as I checked closely for the forces from the solid side and the fluid side, I guess my real question is how the conservative mapping determines which nodes from the fluid side are aggregated to have the conservative value for the solid side (fluid mesh is finner)
For the nearest-neighbour mapping, conservative mappings map each input vertex to the nearest output vertex. Hence, some output vertices may hold no data, while some may hold aggregated data of multiple input vertices.
For details and other mappings, please have a look at section 3.2 from our 2nd reference paper.
