3D coupling OF/Fenics: watchpoint function, OF output forces and serial coupling procedure

Hi all,

First of all, sorry for the long post. I can divide it in several ones if needed.

I’m currently trying to validate a 3D-FSI case (OF/fenics) with experimental data of a 3D cantilevered flexible hydrofoil in a hydrodynamic channel. The hydrofoil is a 3D NACA0015 and the flow is turbulent. Here, the precice-config.xml (2.7 KB) that I adapted from the perpendicular-flap, from the elastic-tube-3D tutorial and from this topic for the mapping options: Running preCICE on a Cluster: The linear system of the RBF mapping from mesh Solid-Mesh to mesh Fluid-Mesh has not converged - #7 by JulianSchl.

I have several questions regarding my model.

  1. First of all, the watch-point function doesn’t give the same time evolution of the displacement in paraview for example. As the function works without any problem in 2D, is there any warnings to use it in 3D ? I verified several time that I’m comparing the same node, but I might have made a silly mistake. Can preCICE messes with the input coordinates in config.xml ?
    Regardless the fact that there is less time value from paraview, you can see that the y displacement is not even of the same order:

    Also, for now, both displacements are not what we should have. It should converged to a equilibrium state, as in the perpendicular-flap case.

  2. The drag and lift force are also very noisy in my opinion. The coupling convergence are still high, so it might come from that… Can it come from the mapping procedure ?

  3. Also, I had to filter the forces.dat generated by Openfoam as it ouputs the values of all the coupling iterations. Have you already experienced something similar ? An example of what OF generates here: force.txt (614.5 KB).

  4. Also, as expected, the serial-coupling is kind of slow (note that I’m still not working on a cluster). Do you have any idea of how to make the fenics fonction get_point_source parallel for 3D ? And how much time it would approximatively take to implemented it ?

  5. Our objectives is to make simulations of 3D flexible hydrofoils at high Reynolds. Therefore, at one point, we’ll need the parallel option. Fenics might not be the proper choice ? As we want a FEM code based on the PETSc toolkit, do you have any ‘ready-to-use’ other suggestion ?

Sorry for the long post again, if needed I can provide the case. The fluid mesh has more than one million cells though.

Thanks for reading :slight_smile: . Any leads are welcome !


Hi again,
In order to make another verification on my first point above, I have plotted the displacement output of the node located at 0.325, 0.096, 0.191 from the watchpoint function, from Fenics and from Paraview. This is what I get:

As you can see Fenics and paraview give similar values but not preCICE…

I made this verification several days ago for the 2D tutorial perpendicular-flap and the 3 curves were exactly superimposed.
Any idea on what cause this strange behaviour ?

Thanks !

Hi @Paul,

I suspect that something is wrong/incompatible with the (x,y,z) assumption of the FEniCS code. I would try two things here:

  • Export the preCICE meshes, plot them both in Paraview, and verify that the two solvers understand the same coordinate system.
  • Also plot the watchpoint on the fluid participant (you currently plot it on the solid).

I am not sure why this could be, but I think it really depends on (1).

I have not tried that, but I expect that this is happening, indeed. We currently take care that OpenFOAM rewrites results when the coupling time window completes, but we don’t do anything special for external function objects. This could be an issue for the OpenFOAM adapter repository.

For anything FEniCS-related, @IshaanDesai and @BenjaminRodenberg are the people to talk to. :grin:

I am not sure I understand the requirement for PETSc, but have you considered deal.II?

Hi @Paul

When we parallelized the FEniCS adapter, we realized that working with PointSource objects in parallel is problematic in the legacy FEniCS. See my first comment in the issue where I describe the restrictions for 3D cases. I had also asked about the problem on the FEniCS Discourse but unfortunately there was no possible fix and the development of the legacy FEniCS has stopped now.

At some point in the near future we will parallelize the FEniCSx adapter as the problem with PointSource objects should be resolved in FEniCSx. Sorry that there is no fix for this right now, but once FEniCSx comes into play, we should be able to fix this.


This is what I get:

So, the two solvers understand the same coordinate system, and the foil is exactly where I expected it to be. However, the exported solid mesh(white dots) does not go “until the end”. I would also have expected white dots at z=0 (the left face, this is the boundary where the foil is fixed, so it is not part of the FSI interface). I added the two bounding boxes based respectively on the fluid and solid domains to help make myself clear.

Also, is it normal that the exported solid mesh takes into account the nodes inside the solid domain ?

So both sides of preCICE are coherent, which is good.

I understood that it is possible to plot the local forces via the watch-point functions but I have not find anything on the global forces exported by preCICE. Is there a way to plot them via preCICE ?

As soon as I find a solution to my installation of OF on our cluster, I’ll have a look a Deal.II.


Hi @IshaanDesai,
Thanks for the clarifications.

So, if I understood correctly, I should consider using FeniCSx if I choose to continue with this solid participant ?


Well the FEniCSx adapter is still very experimental and also only runs in serial. We will probably develop the adapter further this year, and also see how FEniCSx progresses. So if you want to do a full 3D parallel FSI case, then the FEniCSx adapter is not the solution right now.

1 Like

This does not look correct to me and it would mean that something is wrong in how you specify the mesh interface of the solid. Since you are using a conservative mapping for forces, I could imagine that the forces you get on the solid are wrong. Still, this does not explain why the watchpoint shows different values than FEniCS.

By the way, are you sure that “FEniCS output” really means y-displacement and not the total displacement magnitude? This could be an explanation of why FEniCS shows higher displacement.

What do you mean by “global” and “local”?

Ok, so I change the way I declare my interface on the solid participant (Fenics) and this is Fluid-Mesh-Fluid.init.vtu and Solid-Mesh-Fluid.init.vtu and it does look better (only the nodes at the interface are shown), am I right ? :

Yes I’m sure. I extract the x, y, and z value of the displacement vector.

In fact, I’m not sure of what “force0,1,2” means in the precice-fluid-whatchpoint*.log ? I guessed it was the computed forces on the face of the cells related to the (x, y, z) node which is tracked by the whatchpoint function. But I might be wrong ?

The last figure does indeed look better! :slight_smile:

I think this is correct, but currently not documented. A nice opportunity to use the “edit me” button in the documentation! :smile: Watchpoint configuration | preCICE - The Coupling Library


I apologize for the late reply, I had some urgent work to do.
Also, I took some time to better understand the precice configuration. I replaced my hydrofoil with a 3D square-based beam to make my case easier and run faster.

To explain what I think I did wrong and change:

  • I did not define properly the fluid-structure interface in Fenics leading to a wrong mapping.
  • The wrong displacement was transferred from fenics to OF.
  • The watchpoint function gives in my case (I think) the DisplacementDelta and not the Displacement that I plotted with Fenics. So, it is two different variables. Below you can see that when *DeltaDisp is positive, *Disp increases and vice versa.

  • As discussed above, OF outputs the forces and moments at every coupling iterations. I made a python script to delete the unnecessary sub-iteration values for post-processing that I could share if needed but it is not rocket science.

  • As all the figures in this reply are for the simpler geometry:

I can share some images of the real case when I’ll have time to make it, if needed. The next step is to make a comparison with an experimental cases.

Do you want me to edit it ? I do not have a problem to do it but I just made a wild guess, which could be false :grin: .

Thank you again for your advice.

Yes, please! Don’t worry, someone will review your suggestion before merging. And even if something wrong went through the review process, it is always very easy to fix it. So, feel free to always just click this “edit me” button whenever you see something you know would be nice to have on the documentation! :smiley:

Do I understand correctly that now your last post can be marked as a solution for this thread?

1 Like

Interesting work @Paul !
Please also consider writing about your experiences and your application here:

1 Like

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.