I am interested in using preCICE to implement my FSI coupling schemes to couple in-house FEM codes with openFOAM/SU2. I have a few questions regarding this.
In all of the examples I checked, displacements are passed to the fluid solver and forces are passed to the solid solver. How is the interface velocity calculated from the displacements passed to the fluid solver? How do you ensure that the velocities applied to the fluid solver (as the velocity BCs) are consistent with the velocities of the solid boundaries calculated according to the time integration scheme used for the solid solver? Let’s say that the solid problem is solved using the Newmark-beta method with 2nd order accuracy in time.
Does preCICE support the passing of velocities, along with displacements, to the fluid solver? If it does, what are the necessary changes to the config file? Does it require any fundamental changes to the library to pass the velocity data to the fluid solver?
I will try to answer your questions with what I know. But I will start with the second one.
Yes precice can in fact couple mutiple scalar/vector fields together, regardless of what they represent. They can be on different meshes as well (nodes of the fea mesh or integration points, for example). There are internal interpolation methods to work with non-matching meshes between the fluid/solid solver. In my case, I transfer both velocities and displacements from CalculiX to our in-house flow solver.
I dont think openfoam can read velocities, but I might be wrong. However, implementing this might not be too difficult as it is just a matter of prescribing velocities within openfoam, instead of computing them from the displacements. You will need to add the functionality to read velocities in the precice openfoam adapter as well.
Thanks, @marinlauber!
It is good to know that we can transfer multiple fields. This solves part of the problem.
I hope to get responses from the developers with the details of how the velocity BC is applied to OpenFOAM from the displacements. This is crucial as it affects the accuracy, stability and consistency of interface velocities.
Good questions!
and thanks @marinlauber for the great answer already
Yes, you could also use preCICE to send the velocity values from solid to fluid. Adding this to the preCICE configuration is trivial. The “tricky part” is to realize this in both adapters. I am no OpenFOAM expert, so I cannot say much how complicated this would be for the OpenFOAM-preCICE adapter. @Makis and @DavidSCN can probably tell you more.
With the current implementation in the OpenFOAM-preCICE adapter, I would not expect to get sth better than first-order convergence in time, however.
In principle, one could also get to second order with only communicating displacements. We tried this here (but not with OpenFOAM): https://doi.org/10.1002/nme.6443 (section 4.2 “Fluid-structure interaction”).
We are currently working towards realizing waveform iteration in preCICE (basically what is described in the rest of that paper). With waveform iteration, consistency and higher order in time will be much easier (but still requires some additional work in the adapters). Scheduled for v3.
A corresponding presentation from last year’s workshop:
I don’t understand what exactly you mean by “tricky part” here. In principle, the OpenFOAM-adapter already supports reading velocity values through the Fluid-Fluid module (cf the source code). Hence, reading velocity values and displacement values should work from the technical side
One would need to enable both modules in the preciceDict, i.e.
- modules (FSI)
+ modules (FSI FF)
and add both data fields in the readData, i.e.,
readData
(
Displacement
+ Velocity
);
and everything else should be handled by the adapter (note that the order of data names might matter here, I would process the displacement first). Of course, the boundary conditions in U need to be adapted to fixedValue instead of the movingWallVelocity we rely on right now. I’m not sure whether conservation of mass holds in this scenario, as the mesh movement needs to coincide with the received velocities. However, I would assume that OpenFOAM complains here in case of inconsistencies. I guess no one tried until now. As @uekerman already wrote, the resulting convergence order in this setup is still somewhat of an open question.
An easier, but not supported way, could be the utilization of velocityLaplacian mesh movement instead of the displacementLaplacian we are using right now. For this mesh mover, I would expect the velocity values in the fluid to exactly match the prescribed velocities at the interface mesh. Here, the displacement would not be prescribed at all. This approach would require write access to the cellMotion in OpenFOAM, which is -as mentioned above- not supported, but trivial to add.
While we can achieve second-order accuracy just with displacements using a 2nd-order FD scheme, this is a different issue. My main concern is about the consistency of velocities at the interface. In my experience, inconsistencies in velocities at the interfaces lead to instabilities and loss of accuracy, requiring to use of smaller time steps and more iterations. This is why I prefer passing velocities instead of approximating them in the fluid solver, as it enforces the interface kinematic condition accurately. Passing displacement and calculating velocities in the fluid solver does not.
@DavidSCN
Good points! I don’t think there would be an issue with mass conservation, but I can see the difficulties in passing both displacement and velocity fields to OpenFOAM.
If we pass only the velocity and approximate the displacement in the fluid solver, then the displacement field at the interface is not consistent with that of the solid solver. Passing both displacement and velocity fields to the fluid solver and updating the mesh velocity appropriately is the correct approach to accurately resolving Dirichlet boundary conditions and mesh motion for FSI problems.
What changes would it require to do this in a consistent manner? That is, pass displacement for updating the mesh and pass velocities to maintain the interface kinematic constraint.
The required changes from the OpenFOAM side are described in my former comment (yes, only the preciceDict and the corresponding boundary conditions.
From the global coupling perspective, you will need to update your precice-config.xml configuration file in order to tell preCICE about Velocity in addition to Displacement. This looks mostly trivial as the data is treated in the same way preCICE-wise. You can check out https://github.com/precice/tutorials/blob/master/partitioned-pipe/precice-config.xml for (a physically not-equivalent) an example on how the configuration for multiple data sets could look like.
