Problems with nearest-neighor mapping on conforming interface

Using preCICE
, ,
1

Hi,

I’m trying to debug a potential mapping issue between openfoam (well, actually blastfoam) and a custom solid mechanics FE solver. The goal is to take the force values from openfoam and apply them as nodal forces to the solid mesh. The problem we are having is that the force data seems very noisy and is producing unrealistic deformations on the solid side.

To simplify the problem, we created a fluid mesh and solid mesh that are identical on the interface, and then used a nearest-neighbor mapping, in the expectation that precice needs to do a minimum of interpolation and thus the force data would be passed most accurately. To my surprise, the force data at the face centers on the openfoam side and the nodes on the solid side
are very different. Most surprisingly, although there are no zero forces on the openfoam side (there is a constant pressure being applied), there are numerous zero nodal forces on the solid side. This seems very puzzling since, again, the meshes at the interface of both codes are identical.

If anyone has insight into what is going on I would greatly appreciate it. I’m not sure what I can attach here to clarify the problem, but I’ve attached the file containing the fluid forces at face centers (Fluid-Mesh-Faces-Fluid.dt1.vtk), and the nodal forces passed to the solid solver (Solid-Fluid.dt1.vtk). Let me know if there is anything else I can share that may help in debugging the issue.

Thanks in advance!

Steve

Solid-Fluid.forces.zip (165.1 KB)

2

Could you also add your preCICE configuration file? It would be interesting to see what type of coupling and acceleration you use.

In general, for a first test/debugging an explicit coupling without accelerators is a good start. There are some general hints by @Makis in this thread about debugging.

3

Thanks for the reply. I’ll definitely check out that thread, but in the meantime, I’ve also attached the precice-config.xml file.
precice-config.xml (2.0 KB)

Thanks,

Steve

4

Could you share your preciceDict? Which locationType do you use for your interface? Do you select the faceCenters?

5

Please find the precicedict file attached. Yes, we are using faceCenters.

preciceDict.zip (411 Bytes)

6

The exports look indeed weird.

Are you completely sure that the meshes are the same. If you use a conservative mapping on non-matching meshes, you could theoretically get ‘zero’ forces on the output mesh.

What might be a good idea in order to debug your case is using the forces functionobject of OpenFOAM. You can configure this in the controlDict (e.g. https://github.com/precice/tutorials/blob/8e71370f0700caa25892af04145be79a3f79aff5/turek-hron-fsi3/fluid-openfoam/system/controlDict#L44-L62) and can compare the result to a watch-integral of preCICE so that you can narrow down the error to the OpenFOAM adapter or something different. The preciceDict looks good.

7

Hi @DavidSCN

Thanks for your reply. Could you please elaborate on what you mean by “you could theoretically get ‘zero’ forces on the output mesh”. Since I am still new to FSI, perhaps I misunderstand how these mappings work. I was surprised to get zero forces, but if it is possible to get zero forces, then that might simply be the explanation.

Also, do you have any recommendations on what the best mapping should be for an FSI problem? I suspect that might be somewhat problem dependent, but any recommendations on choosing the mapping would be very helpful. FYI, we’ve been exploring some other mappings, and we have had some success with mapping stress instead of forces using the rbf-gaussian mapping, although that is creating some other issues (poor correlation between the pressure on the fluid side, and stress on the solid side).

Thanks in advance!

Steve

8

In the end, the mapping is conservative, which means that the sum of all forces on each side needs to be equal. If you have more nodes on one side compared to another side, you could theoretically have nodes with ‘zero’ force, because the sum of the values was already reached. In your case, it looks wrong, though, since the zeros are distributed within your mesh.

Hm. I would recommend to start as easy as possible, i.e., a nearest-neighbor mapping and then slowly start increasing the complexity of your setup. For small setup, global rbfs such as volume splines or thin-plate-splines should work as well. For bigger setups, the (local) Gaussian RBFs should be fine, but it requires quite some tuning with respect to the shape parameter (RBF shape calculator | preCICE - The Coupling Library). Covering around 5 vertices in radial direction should be fine.

However, I’m still not sure if your setup is completely clean. I would start debugging with a nearest-neighbor mapping and a minimal problem setup.

9

I went back to my test problem with identical meshes on the interface and then using nearest-neighbor mapping.
In this case, the fluid has a constant homogeneous pressure field. The solid is a sphere, completely surrounded by fluid. The expectation is that the constant pressure will create a homogenous, radial displacement of the sphere’s surface.

Here you can that the fluid pressure indeed is constant at the interface.

image
image979×839 110 KB

I then looked at the forces, calculated by OpenFOAM at the face centers.

image
image930×796 119 KB

These appear to be as expected, in the sense that the forces are the face normals, scaled by pressure and area.

Then, I looked at the nodal forces on the fluid interface.

image
image937×768 118 KB

I’m not sure who (OpenFOAM or preCICE) and how they are calculated.
These force vectors are then passed directly node-to-node, due to the conforming interfaces and nearest-neighbor mapping, to the solid solver.

image
image852×854 107 KB

Unfortunately, on the solid solver side, these forces do not represent the equivalent nodal forces for a homogeneous pressure and therefore do not produce a homogeneous radial deformation.

I didn’t try nearest-projection, but since the interfaces are conforming, I expect the same results.

The source of the problem seems to be the mapping from face-centers to nodes on the fluid side. It is unclear how this mapping occurs, since I don’t see anything in the precice config file that controls this. Or perhaps these are mapped in the OpenFOAM adapter? In any case, the result of this mapping does not appear to be an accurate representation of the equivalent nodal forces needed to apply the same homogeneous pressure on the solid side. Or did I miss something? Could this still be the result of a problem in our setup, and if so, how can we fix it? TIA!

Steve

10

Yes, this looks fine.

I don’t get this: why and how do you look at the nodal force values. Usually, the forces only live on faceCenters on the fluid side so there are no nodes and no nodal forces involved. Or do you just use another representation created by paraView? In the usual setup, the center values of the forces are immediately passed to preCICE. Note that selecting another location type for the forces is just wrong. If you have a constant pressure (and velocity) on the fluid side you should get an exact result (ignoring the difference due to the cell size).

11

I think I misunderstood something. The fluid forces indeed only live on the face centers. But the precice-config file defines two meshes on the fluid side (Fluid-Mesh-Faces and Fluid-Mesh-Nodes). We have the export:vtk tag in both the fluid and solid participant, so there are files with force data on the nodes in the fluid folder. I misunderstood and assumed that the nodal force files in the fluid folder were the result of some other unknown projection and used as the starting point of the nearest-neighbor projection to the solid mesh, but based on what you are saying, I understand now that these are in fact the result of the nearest-neighbor mapping. They just happen to be stored on both the fluid side and the solid side. Is my understanding correct?

12

Terminology becomes a bit tricky here: do you mean now you have Force data on the Fluid-Mesh-Nodes on the fluid side? This would be erroneous? If you installed the adapter via git and use the current develop branch of the adapter. I would like to encourage you to pull the latest changes.

If you define an export in your configuration file, you will get the respective data sets only on meshes, which ‘use’ the respective data, i.e. where you defined a use-data tag. For a coupled simulation, this means that you usually have at least two meshes using a data and two exported meshes holding this data. In your case, I would expect that Fluid-Mesh-Faces-Fluid, (mesh on the fluid side), Solid-Fluid (solid mesh on the fluid side) and Solid-Solid have Force data. The mapping happens on the Fluid side so that the data of Solid-Solid and Solid-Fluid should be the same.