Undefinable abort of FSI of a 3D case with Openfoam and Calculix

Hi everyone,

I am calculating a plate mounted over a propeller, as you can see in the picture. For simplification, the plate is fixed on the edges. I want to evaluate the pressure and resulting displacements caused by the propeller.


I am using Openfoam in parallel and CalculiX and testet both cases seperately, they work well.
When coupling with precice, Openfoam calculates the first timestep and aborts after that. I couldn’t find out, which participant is causing the abort.
I testet the mesh motion in Openfoam before and tested the coupling of Openfoam and CalculiX via precice with the FSI3 Benchmark, both work. Unfortunately, my case is more complex than FSI3, it is 3D, has a rotating AMI and a complex mesh. I included the log-files of both solvers and the precice-config file. Maybe someone has an idea of how I can improve my setup, I am not very experienced with precice.

log-fluid.out (237.9 KB)
log-solid.out (9.7 KB)
precice-config.xml (2.6 KB)
turek.inp (961 Bytes)

Regards,
Alina

Hi @Alina,

I would assume your simulation needs some OpenFOAM feature that the adapter does not support. I don’t have any experience with the rotating Arbitrary Mesh Interface feature. Maybe @JulianSchl has some idea of alternatives here, based on his work.

Do you also face the same problems with fewer parallel ranks? Did you also try with the latest version of the OpenFOAM adapter? (v1.1.0)

Hi @Alina,

Maybe you could explain how the motion is coupled to OpenFOAM in more detail.
Do you send the full rotation motion from CalculiX to preCICE or just the relative displacement of a static propeller?
Is the AMI rotation still performed directly by OpenFOAM or are you trying to couple the whole motion through preCICE?

1 Like

Hi Julian,

I only couple the plate with preCice. The propeller rotation happens only in Openfoam and I just want to transfer the resulting forces of the pressure that reaches the plate to CalculiX. As I said, I tried the Openfoam setup before with the rotating AMI and a prescribed motion for the plate. Then I modified the boundary conditions in the dynamicMeshDict similar to the FSI3 Benchmark for preCice.

I use the new version of the adaper.

Thanks for your reply!

Okay,
as far as I have understood, the issue must not be related to a rotation motion.
Maybe @Makis or somebody else could assist here (I’m not familiar to CalculiX in particular).

@Alina to better understand what is going on, could you maybe upload a short animation of the problem, showing the mesh in ParaView, before the simulation crashes?

@DavidSCN
slurm-fluid.out (593.6 KB)
slurm-solid.out (7.8 KB)

@JulianSchl why do you conclude that AMI and the preCICE adapter mesh movement do not interfere? The difference here is that the OpenFOAM adapter works on a different portion of the mesh and according to the log file our current workflow looks as follows:

→ store checkpoint → execute AMI motion → reload checkpoint, but on a different (rotated mesh) :bomb:

I was expecting, that the AMI encloses the propeller and not the coupled plate.
Therefore the mesh coupled via preCICE would not be rotated (only the propeller inside the AMI) or did I get something wrong?

We have two AMIs, one for the propeller to ensure the rotation. This one is not coupled with precice. To enable two different motions, theres is a cellZone around the plate, which is also treated as an AMI. Only the plate is coupled with preCICE.

Hi @Alina,
sorry for jumping late into the conversation. Unfortunately, I was also late during your discussion yesterday at the preCICE workshop, you were ahead in the discussion and probably I missed some information. My understanding is that you want to perform the FSI computation on a plate, I’d like to ask you if you would consider using MBDyn as the solver. I’d be interested in simulating things in naval applications, I have some (little) experience in simulating hydrofoils with openFOAM+preCICE+MBDyn and I’d be curious to test also this setup.
My understanding is that your simulation blows up at some point: my experience might be summarized as follows:

  • I generally try to progressively apply the load to the structure. In general it is not enough to start with a developed flow
  • always use implicit coupling, and maybe the the order of the solvers has an impact
  • check the mesh from time to time to see if and where it deforms too much

If you are interested, I’d like to analyze this setup with you more in detail.
Claudio

@Alina I just set up a small case using displacementLaplacian and the AMI solid body rotation mesh motion and it works for me when I solve first for the displacementLaplacian mesh motion and afterwards for the AMI mesh motion (but not the other way around).

It might be worth trying to change this in your settings (put the plate and the corresponding displacementLaplacian solver before the ami in the dynamicMeshDict). I’m not sure if it will finally resolve the issue. If not, what happens if you completely remove one or both AMI mesh motions?

For me it still did not work with the plate before the ami in the dynamicMeshDict. But I managed to run a parallel explicit coupling by using a greater distance between the plate and the ship and a bigger gap for compensation, so the pressure does not blow up. Unfortunately, I won’t be able to put more effort into this project because it will be closed soon.
Thanks for your inputs and help!

1 Like