Mapping Issues: Missing Vertices and Not Invertible Matrix

Using preCICE
, , ,
1

Hi there,

In this thread I’ve already mentioned my issues with the RBF mapping which seemed to be solved by then.

Now new problems occured :tada:

conclusion of the case:
I’m trying to couple a 3D model of an airfoil between the OpenFOAM-Adapter (fluid) and the preCICE Python bindings (solid) which are connected to MBDyn.
Firstly I’ve tried to just couple the surface of the airfoil while neglecting the side plate in the solid mesh (as you can see here).

issue:
Firstly it seems that some vertices which are sent to preCICE are not appearing in the preCICE mesh anymore.
I’ve tried to also map the full airfoil (with the back plate, as you can see in the following screenshots) which lead to the same issue.
Here you can see the exported VTK data of the solid (red) and the fluid (blue) mesh:

62b76b0aa261575a6c2892a448af4e2e73f72cb6
62b76b0aa261575a6c2892a448af4e2e73f72cb61580×1154 336 KB

It seems that two vertices are missing in the preCICE mesh, while the original mesh is sending it correctly as you can see in the next plot:
allNodesAvailable
allNodesAvailable1536×766 61.9 KB

second issue:
Further, after discovering some wrong force mappings (while the forces were mapped correctly in a similar 2D case) I was trying to map the full airfoil (including the backplate).
A screenshot of the preCICE mesh is shown below with the solid mesh (red) and the fluid mesh (blue):

3D_solidMesh_backPlate
3D_solidMesh_backPlate1580×1154 131 KB

The solid mesh in its state as it is sent to preCICE is shown in this figure:
3D_solidMesh_python
3D_solidMesh_python931×717 107 KB

Finally when trying to map this 3D solid mesh with the backplate, preCICE returns:

(0) 15:08:16 [impl::SolverInterfaceImpl]:285 in initialize: Slaves are connected
(0) 15:08:16 [impl::SolverInterfaceImpl]:317 in initialize: iteration: 1, time-window: 1, time: 0 of 0.5, time-window-size: 0.0001, max-timestep-length: 0.0001, ongoing: yes, time-window-complete: no, 
(0) 15:08:16 [impl::SolverInterfaceImpl]:1476 in mapWrittenData: Compute write mapping from mesh "Fluid-Mesh" to mesh "Solid-Mesh".
(0) 15:08:16 [mapping::RadialBasisFctMapping]:199 in computeMapping: ERROR: The interpolation matrix of the RBF mapping from mesh Fluid-Mesh to mesh Solid-Mesh is not invertable. This means that the mapping problem is not well-posed. Please check if your coupling meshes are correct. Maybe you need to fix axis-aligned mapping setups by marking perpendicular axes as dead?

Currently the vertex density on the backplate is 10^{-3}. I’ve tried to increase the vertex density on the backplate even more, but without any success. Reducing the vertices on the backplate to a number of 4 leads to a running coupling, but I think this won’t be a good mapping either.

Question :
I’m wondering how I could proceed now, as I have a similar 2D case which is running with the same preCICE configuration.
As I’ve mentioned my final guess in adding the lid to the mapping and varying its amount of vertices did not help to solve the issue …

2

Hi

are you sure that this is a preCICE problem? paraView has by default an upper limit on the number of output points is shows you. Maybe the number of interface nodes are beyond this number. In order to check this finally, you could (1) check the paraView settings again and (2) ask preCICE using preCICE.getMeshVertexSize() (docs)

With backplate you mean the cross-section?

Your guess is then that the backplate causes the issue?
Which RBF mapping do you use? Does it work when you remove the “back-plate”, while still mapping in 3D? Which data do you pass to preCICE when the mapping fails?

3

Hi,

indeed the missing vertex issue could be lead back to a low glyph resolution in Paraview (also getMeshVertexSize gives the expected no. of vertices), thanks for pointing that out!

yep

It is a guess because the simulation works, when not mapping the backplate. Still, when leaving out the backplate the mapping is somehow bad, because the forces are wrongly mapped by either preCICE or the OpenFOAM-Adapter (couldn’t figure out which one yet because I’m having issues with the python callback interface).

I have tried the rbf-thin-plate-splines and rbf-compact-polynomial-c0 mapping with similar issues.

preCICE fails after this step:
(0) 07:28:35 [impl::SolverInterfaceImpl]:1476 in mapWrittenData: Compute write mapping from mesh "Fluid-Mesh" to mesh "Solid-Mesh".
This step mapps the force data from the fluid-mesh (OpenFOAM) to the solid-mesh (Python / MBDyn).
At the time of the simulation crash, the solid solver hasn’t calculated a timestep.

4

What do you mean by wrongly mapped data values? How do you decide that the data is actually mapped in the wrong way? Why are you in particular sure that the error stems from preCICE or the OpenFOAM adapter?

5

To see if the data is coupled correctly, I calculated the forces with the OpenFOAM postprocessing function to have a reference value. For the 2D, the data matched the expected values when logging the coupled forces from preCICE via the Python bindings (not Python actions).
In the 3D case the forces differ from the postprocessing OpenFOAM values.
Therefore I think something goes wrong between OpenFOAM and preCICE, but I don’t know if the issue is related to the mesh or the chosen mapping method.

6

Could you check the force sum obtained by preCICE using a watchintegral Watch integral configuration | preCICE - The Coupling Library and compare it against the OpenFOAM calculated forces?

7

Hi Julian,
I have the same problem with you. Did you get a solution of it?
This is my results of 3D data mapping.
(N-N mapping)

Fluid-Mesh-Faces-Fluid-Force
Fluid-Mesh-Faces-Fluid-Force4856×3136 430 KB

Solid-Mesh-Solid-Force
Solid-Mesh-Solid-Force1920×1240 38.7 KB

In my simulation, there is only one element on z-axis
The data mapping is random for the front and back surface. This is strange. Although the force sum is the same, the distribution is completely different. So how did you solve this ?

8

Related thread: 3D data mapping problems

@O_K let’s keep the discussion there.