Coupling scheme for quasi-steady-state FSI

Hello,

I am trying to set up an FSI simulation. For the fluid part, I am using my own solver, which is steady-state (not time-dependent), and for the solid part, I’m using the deal.II adapter provided by preCICE which is time dependent.

The subject of my simulation is a foil (a kind of wing) submerged in water.
At first, I tried with an explicit coupling between the two solvers and observed some vibrations of the wing. Since the simulation is quasi-steady, I suspected this behavior might be due to numerical errors. So, I decided to switch to implicit coupling.

Because of an error raised by preCICE, I added the two checkpoint statements (read and write state) in my fluid solver, as well. However, I’m not actually doing anything inside these two if-statements, since in my case there’s no need to reset any old variables or go back to a previous state.

That said, this part is still not entirely clear to me. So, I would like to ask if this reasoning makes sense, or if I am missing something or doing it incorrectly.

I just posting the configuration file here:

<?xml version="1.0" encoding="UTF-8" ?>

<precice-configuration>
  <log>
    <sink
      filter="%Severity% >= debug and %Rank% = 0"
      format="---[precice] %ColorizedSeverity% %Message%"
      enabled="true" />
  </log>
  
    <data:vector name="Displacements"/>
    <data:scalar name="Pressure" />

    <mesh name="FluidMesh" dimensions="3">
      <use-data name="Displacements"/>
      <use-data name="Pressure" />
    </mesh>

    <mesh name="StructureMesh" dimensions="3">
      <use-data name="Displacements"/>
      <use-data name="Pressure" />
    </mesh>

    <participant name="FluidSolver">
      <provide-mesh name="FluidMesh" />
      <receive-mesh name="StructureMesh" geometric-filter="on-secondary-ranks" from="SolidSolver" safety-factor="5."/>
      <read-data  name="Displacements" mesh="FluidMesh"/>
      <write-data  name="Pressure" mesh="FluidMesh"/>
      <mapping:nearest-neighbor direction="read" from="StructureMesh"
                                to="FluidMesh" constraint="consistent"/>
    </participant>

    <participant name="SolidSolver">
      <provide-mesh name="StructureMesh" />
      <receive-mesh name="FluidMesh" geometric-filter="on-secondary-ranks" from="FluidSolver" safety-factor="5."/>
      <write-data name="Displacements" mesh="StructureMesh"/>
      <read-data  name="Pressure" mesh="StructureMesh"/>
      <mapping:nearest-neighbor direction="read" from="FluidMesh"
                                to="StructureMesh" constraint="consistent"/>
    </participant>

    <m2n:sockets acceptor="SolidSolver" connector="FluidSolver"/>

    <coupling-scheme:serial-implicit>
      <participants first="FluidSolver" second="SolidSolver"/>
      <max-time-windows value="100" />
      <time-window-size value="1.e-3" />
      <exchange data="Displacements" mesh="StructureMesh" from="SolidSolver" to="FluidSolver" initialize="yes"/>
      <exchange data="Pressure" mesh="FluidMesh" from="FluidSolver" to="SolidSolver" initialize="yes"/>
      <max-iterations value="50"/>
      <relative-convergence-measure limit="1.e-6" data="Displacements" mesh="StructureMesh"/>
      <relative-convergence-measure limit="1.e-6" data="Pressure" mesh="FluidMesh"/>
      <!--<acceleration:constant>
        <relaxation value="0.5"/>
      </acceleration:constant>-->
      <!--<acceleration:aitken>
        <data name="Displacements" mesh="StructureMesh"/>
        <initial-relaxation value="0.1"/>
      </acceleration:aitken>-->
      <acceleration:IQN-ILS>
        <data name="Displacements" mesh="StructureMesh"/>
        <!--<data name="Pressure" mesh="FluidMesh"/>-->
        <preconditioner type="residual-sum"/>
        <filter type="QR2" limit="1e-3"/>
        <initial-relaxation value="0.1"/>
        <max-used-iterations value="100"/>
        <time-windows-reused value="20"/>
      </acceleration:IQN-ILS>
    </coupling-scheme:serial-implicit>
</precice-configuration>

Also, I don’t fully understand the difference between parallel and serial coupling, as I’m seeing completely different convergence behavior in the two cases.

Hi there,

An implicit scheme using a single time window is a good way to configure a steady state problem. This essentially tells preCICE to rerun the entire simulation until some steady state is reached.
We could add a configuration example in the documentation to make this clearer.

You are computing multiple time windows, which is an indicator to me that you may need to reset some internals of your steady state solver.

In a serial coupling scheme, solvers run one after the other.
This means that once the second solver runs, it has access to the initial data of the time window along the resulting data of the first solver of this time window.
In the first iteration of a time window, the first solver has only access to the initial data of the time window. In later iterations, it has access to the possibly accelerated resulting data of the previous iteration of the second solver.
The downside is that one solver always needs to wait for the other leading to a low overall utilization of the compute resources.

In a parallel coupling scheme, both solvers run at the same time.
Hence, in the first iteration of a time window, both solvers only have access to the initial data and compute the result of the time window.
In successive iterations, both solvers then have access to the initial data of the time window and the possible accelerated result data of the last time window.
This leads to a better and possibly full utilization of the compute resources but may result in more total iterations.

Hope that helps!
Frédéric

Hello, thank you for your reply.

I get the serial and parallel coupling scheme!

Regarding my specific problem, the coupling is not completely steady state because the deal.ii adapter is time-dependent. That’s why I tried an implicit scheme across multiple time windows. The system oscillates with damping until convergence after a certain number of iterations of the time windows.

1 Like

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