2D-3D Coupling OpenFOAM-DUNE

Hello preCICE-Users,

I get the same error as Alphaoo1 posted above, so I thought replying here would be the best option.
I try to couple a Solid-Solver written with DUNE with OpenFoam and the 2d case works fine without further problems. Switching to 3d results in the mentioned errors from above with the same behavior of the coupling methods.
I already checked the meshes of fluid and solid, which both look fine to me (see picture). Also the coordinates that are given to preCICE of the coupling interface are correct.

I use preCICE-Version 2.1 and the fluid setup of the 3d fenics-openfoam testcase
(the one with the flap in the channel).

Has someone an idea for the solution of that problem ? Or at least where it could
come from ?

Best regards,

Hi Max,

If OpenFOAM fails with a floating point error that probably just means that the coupled simulation crashed. It’s the symptom, not the problem.
When does it crash? Which preCICE config do you use? What do the convergence and iteration files of preCICE say?

My best guess right now would be that sth with the 2D-3D mapping does not work. Your case is quasi-2D, but you simulate it in 3D. Does a real 3D case work? Sth like https://github.com/precice/tutorials/tree/master/FSI/3D_Tube/OpenFOAM-CalculiX ?

Btw, great that you use preCICE with DUNE. Please keep us posted how that goes. As far as I know nobody has done that before. Any contributions in that direction would be very much appreciated.



I basically use exactly the same precice-config as in the 3d fenics FSI tutorial with the flap. I can either use nearest-neighbor or rbf mapping, but the result is always, that the simulation crashes in around 1-5 time windows after the start of the simulation. I begin with the fluid part and the first mapping to the structure part works fine. Then it crashes, while mapping from structure to fluid. The same behavior is true for both explicit- and implicit-coupling.

For me trying to simulate the flap in 3d (or quasi-2d) was the most sensible way after the 2d one was working. So i don’t know, if a real 3d case would work, haven’t tested one.


@MaxFirmbach could you please post the preCICE-related log from both participants? I assume that you only get this error with RBF mapping?

We have seen such problems with CalculiX lately, but maybe there is something that we need to look deeper into here.

Hey Makis,

unfortunately it doesn’t work for both mappings.
I hope the log files are the ones you need, there are the ones for convergence and the debug ones
that are written/configured via the precice-config.xml file.

I also thought that for the 2d case preCICE does a 2d-3d mapping, due to the fact that OpenFoam always uses a 3d mesh and in the quasi-2d case the coupling is done on surfaces so this is a 3d coupling… Or am I misunderstanding something there ?

precice-FluidSolver-iterations.log (69 Bytes)
precice-FluidSolver-iterations.log (69 Bytes)
precice-StructureSolver-convergence.log (2.2 KB)
debug_Solid.log (253.3 KB)
debug_Fluid.log (9.7 KB)

What is your preCICE config?
Could you also please upload precice-StructureSolver-iterations.log?
Your coupling convergence measures seem rather tight. Does it get more robust if you loosen those?

No, you are right. In the 2D-3D case, the OpenFOAM adapter does the mapping between 2D and 3D. If you do 3D-3D for a quasi-2D case, however, you can mess up things in the span-wise direction. Which coupling mesh (which coordinates in z direction) do you use in DUNE then? Try to export all coupling meshes as vtk.

It seems like the Fluid-iteration.log and Structure-iteration.log files are the same.

I use gmsh for creating the mesh as .msh file. I can load it in with Dune and can loop over the mesh entities like the vertices. In this case each vertex has three coordinates, where the z-coordinate is related to the spanwise direction. I then pick all vertices related to the coupling interface and write them into the array that preCICE needs for the setup.
So the coupling mesh should be consisting of the vertices on the surface of my flap, like in the picture from above, where red and grey have the same interface.

precice-config.xml (3.5 KB)
precice-StructureSolver-iterations.log (69 Bytes)

You currently use no acceleration. For a strong physical coupling this is known to diverge. What happens if use the acceleration you have currently commented out? Then, the structure iterations file will also contain more information than the fluid iterations file, namely information about the acceleration, which only the second participant of the coupling scheme knows (StructureSolver in your case).

There could be a problem with how you currently treat the z coordinates. OpenFOAM provides forces at the cell centers, which you try to read at the cell vertices of DUNE. In between, you use a nearest-neighbor mapping. For each cell, both DUNE vertices have the same distance from the OpenFOAM cell center … on which side the force gets mapped to is arbitrary. You could circumvent this problem by e.g.

<mapping:rbf-thin-plate-splines z-dead="true" direction="write" 
  from="Fluid-Mesh-Faces" to="StructureMesh" constraint="conservative" timing="initial"/>

z-dead means that the z coordinate is ignored in the mapping. The mapping problem is reduced to a 2D problem.
Was that understandable?


yes that was understandable. So I tried to run the simulation with the
recommended changes and it shows a bit of a better behavior.
Still, the simulation crashes. I’ll attach the structure iterations file
with the acceleration information.

Thanks for the help so far.

precice-StructureSolver-iterations.log (146 Bytes)
precice-StructureSolver-convergence.log (767 Bytes)

I also tried to play with different parameters. The maybe most interesting thing is, that for a lowering of the fluid density, the simulation archives a max-time of around 2s before the floating point exception occurs.
During the simulation the flap also shows the physical behavior of bending backwards, which looks correct. Why it is breaking randomly is still strange, because the simulation shows no oscillations or strange mesh movement.

Lowering the fluid density decreases the added-mass effect / instability. See e.g. Causin et al. or Brummelen. So it’s not unexpected that the coupling becomes more stable.

So, it might be just a coupling instability, no bug.

For this case, which breaks after two seconds could you please provide:

  • your preCICE config,
  • the iterations and convergence files,
  • the tolerance and convergence measures, which you use within your solvers, and
  • a screenshot of your setup just before diverging (ideally also showing the mesh).