Strange phenomenon during multiphase FSI

Hi all,
Recently I’m doing wave-struction simulation using our in-house solver and OpenFOAM. At first, the wave propogates normally. However, the water near the structure suddenly collapses.
The red part is water and the blue part is air.
1.95s


2.00s

Since the displacement and stress results obtained from our in-house solver seem to be fine, I guess this may be related to the fluid part but I haven’t found mistakes in case setting. May it be that the data mapping doesn’t converge?

Has anyone encountered the similar situation? Any suggestions will be appreciated! :blush:
precice-config.xml (2.6 KB)

Are you maybe using a modified version of the adapter? How did you make the FSI module work with multiphase?

I could imagine that there is a bug here, but I need to understand the context first.

Hi Makis,

Yes, I’ve modified the adapter to pass Pressure to the solid participant, and read the Velocity and Displacement on the interface from the solid.

I didn’t change much. In brief, I adopted a multiphase solver and modified some initial files.

Today, I’m sure basically that the problem is due to the Velocity passed to the fluid part, not the openfoam adapter. For some points on the interface, the velocity values calculated by our in-house solver are quite large which could lead to the non convergence in the fluid part. Once I removed the Velocity from the coupling data, the simulation converged well.

Is the discontinuity maybe related to implicit coupling and redoing iterations? Just thinking in the direction of checkpointing.

Since our solid solver doesn’t have checkpoint function at present, I only use explicit coupling to do my tests ( It may change the structure of our solver in order to do implicit couping, but it’s on the to do list). In my simulations, I found that there is unreal oscillation for the structure. For example, the flap is supposed to vacillate to the left and right once it’s hit by waves. However, when the flap should continue to vacillate to the right, there is a sudden movement to the left. May it be the problem of the discontinuity you mentioned?

Are your code changes available online anywhere?

The changed openfoam-adapter is uploaded here. I mainly changed the files in FSI module to write Pressure to the solid and read Displacement and Velocity from the solid.
openfoam-adapter_modified.zip (2.8 MB)

Since our solid solver is an in-house code and it is directly modified in the source code to adopt functions in preCICE library, I’m sorry this cannot be uploaded.

To be more clear, the strange phenomenon is shown in the figures. Fig.3 shows that the flap suddenly vacillate to the left when it should have vacillated to the right. Then, there is a kind of discontinuity of the water phase near the flap as shown in Fig.4.


Fig.1 & Fig.2

Fig.3 & Fig.4

I have performed a similar case with a flap in a multiphase air/water domain, and also had some stability problems. However, this normally occurred with severe mesh distortion around the flap, causing the openFOAM to diverge. For this case I do not know what could be causing it.

Have you tried various mesh sizes i.e. both coarser and finer meshes?

Hi @KyleDavisSA ,
Thanks for your suggestions. I haven’t since the mesh size is pretty small. But I’ll have a try with more meshes.

By the way, I noticed that there is a time warp after the coupling simulation runs for some time (For example, OpenFOAM Time is 2.9s while our in-house solver Time is 3.2s). Has anyone ever encountered the similar situation? I guess this may also be the reason why OpenFOAM diverges (discontinuity at the interface due to the time warp).

This sounds to me as if your in-house solver does not take the minimum between the timestep size it wants to perform and the timestep size of preCICE: Step 5 – Non-matching timestep sizes | preCICE - The Coupling Library

Actually it does takes the minimum time length, we define the timestep according to this Step 5.
For initialization and advance, we have
1

2
The output in terminal is shown as follow:


So it’s quite confusing for me why the time warp happens.

I can very well be that the instability comes from the explicit coupling. Does it work when you use a very heavy solid?

Concerning the time warp: How do you call advance? Could you please show that code snippet as well?

Hi @uekerman ,
Sorry for the late reply.

Do you mean the density of the solid? For a solid with 2700kg/m^3,there is still a time inconsistency.

Of course, we call advance after calling Precicef_Write_Bvdata in a subroutine:

Yes. I was referring to your stability issues here. Must not necessarily be related to the time inconsistency.

Concerning the timestep size:

In the Fortran bindings the Dt in advance(Dt) is an input and an output argument. You need to use the output value as Precice_Dt in your code snippet above.

More information:

and

Thanks for the clarification. It seems that density doesn’t affect the stability much.

Yes, we always use a shorter timestep between the output value of advance(Dt) and our preset timestep. We’ve checked the code before according to the information you suggested and there seems to be nothing wrong. Anyway, thanks for your help and the suggestions!

and you also pass the correct Dt to advance?

The first half of this video also explains the timestep size handling:

Yes, we passed the correct Dt to advance and our timestep size handling is exactly the method which is shown in this video at 9:22.

Additional information:
The output of DeltaTime and Precice_Dt during the simulation seems to be fine, but the finish time is still different.




In our code, we use our own Total_Time instead of ongoing to control the timeloop. May this problem related to the method of timeloop control?

Hi all,
I found out that the cause of my problem was the adjustTimeStep in OpenFOAM. I usually set adjustTimeStep yes in controlDict to adjust timestep length automatically. Once I close the adjustTimeStep, the coupling times are right for both solvers.


It seems that OpenFOAM adapter does fully support the adjustTimeStep at present. Will it be on the to do list? :smiley:

@Stan there is a related issue on this topic FSI: Subcycling with implicit coupling · Issue #58 · precice/openfoam-adapter · GitHub. Right now, I’m not sure if all descriptions in there are still up-to-date. If you have any related insight or findings into this topic, feel invited to comment there in order to push things a little bit.