Hi all,
After reading the ‘‘step-by-step’’ in the preCICE documentation and watching videos about preCICE, I have a few questions about the FSI coupling using preCICE:
As the in-house solver requires ‘pressure’ instead of ‘Force’ from OpenFOAM, should there be only one interface (Fluid-Mesh-Nodes) to do both read displacements and write pressure in preciceDict?
For multiphase flow solver such as interFoam, since the density and kinematic viscosity of water and air are different and there is a surface tensioin coefficient, do we need to add these coefficients into preciceDict?
As stated in this thesis Alexander Rusch’s thesis, the displacements are set as coordinate variations relative to the nodal positions of the last time step, I wonder if it is achieved by overwrite the ‘‘points’’(in polymesh) which includes all the nodes coordinates before solving the next step? Where can I find the codes that describe the mesh deformation process? Or what is the exact format of the coordinate variations that the in-house solver needs to transfer to OpenFOAM?
What kind of configuration file should be adopted by an in-house solver (written in Fortran)? A YAML file like CalculiX?
I don’t have experience with multiphase FSI, but the adapter will not read anything else than these parameters. I am not sure about interFoam, but in general, a compressible solver should compute these values already. We only need to read them for incompressible solvers.
We refer to this as “displacement deltas” or “relative displacements”. The OpenFOAM adapter supports both absolute and relative displacements, you just need to select what you need in the adapter config. The mesh deformation is handled by OpenFOAM, we only give new values to pointDisplacement (face nodes) or cellDisplacement (face centers).
We only use YAML in some adapters because we once dreamed of a global configuration format for each adapter. We quickly realized that this was unnecessarily complicated and we now recommend using the native format of each solver (if a good one), or whatever you find more comfortable working with. One popular option is YAML, one other popular option is JSON. In Fortran, .ini files seem to be popular, but I am not sure if there is a standard way to read them.
Since the structure solver only needs water pressure and OpenFOAM adapter is able to write pressure, I think I’ll use pressure instead. And yes, the usage is described quite clearly in the case you mentioned.
Additionally, there are a few problems about the ‘‘checkpoint’’ that make me confused. Firstly, it is illustrated that the “saveOldState” and “reloadOldState” need to be provided by the solver in Step 6 - Implicit Coupling. However, I don’t quite understand the necessity of this checkpoint. It is stated that “for two times the same input (the values you read from preCICE), the solver also needs to return two times the same output (the values you write to preCICE)”. As the solving process in this step diverges, even if the “OldState” is reloaded, the following process is supposed to diverge too. Could you please tell me where I misunderstand? Besides, it is also illustrated that “you need to include as much information in the checkpoint as necessary to really be able to go back in time”. Thus, taking FSI simulation as an example, since the only value we read from preCICE is Force/Pressure for solid solver and Displacement for fluid solver, does it mean that for solid solver, what we need to store is only Force/Pressure?
In order to build an adapter, I downloaded the solverdummy in Fortran and tried to modify the code to make it suitable for our in-house solver. As I’m just a beginner in coding, I wonder if I have to modify the functions in Fortran bingdings (.cpp file) into subroutines so that these functions can be used in the adapter? Or there is already a module including those functions which we can ‘use’ directly in our ‘program’?
I see that we need to improve the documentation here: the fluid pressure is only available through the FF (fluid-fluid coupling) module. But at least in theory, you could enable both FSI and FF, and it should work.
We actually need much more than that: we need to save the complete state of the solver: all internal fields (at least those that cannot be derived from other), the mesh state, and the time. In the OpenFOAM adapter, we do this by blindly copying all fields that the OpenFOAM solver registers in its objects registry (+ time). We reset a checkpoint by reloading all these fields, moving the mesh to its previous state, and resetting the time.
The reason that we need full checkpointing is exactly what you mentioned: the solver state will diverge if we don’t do this but keep repeating timesteps.
You are not supposed to change any code in the bindings themselves (unless you know why you want to do that, i.e. you want to add a feature or fix a bug).
Since we are trying to enforce a “one thread per question/topic”, let’s try to conclude on the first questions and we can always continue in as many new threads as we need.
Thanks for the explanations. I’ll take some time to fully understand them.
Since we are trying to enforce a “one thread per question/topic”, let’s try to conclude on the first questions and we can always continue in as many new threads as we need.
Yes, next time I’ll start a new thread as you suggested.
