Turek-Hron FSI with OpenFOAM and CalculiX

Hey,

I am currently trying to simulate the Turek-Hron FSI case with OpenFOAM and CalculiX since the tutorial is only available via deal.II.

I’ve created my own mesh for the flap with Gmsh and used this post as a guide.

For OpenFOAM I’ve tried both, the settings from the tutorial and the settings from the above mentioned reference. In addition, I’ve tried to stabilize both of them, but neither worked like I wanted to.

The reference didn’t make it through the first Iterations beacuse OpenFOAM crashed with a Printstack Error, that’s why I sticked with the tutorial.

Here are my files for the case:
precice-forum-turek.zip (124.0 KB)

For this case my simulation runs until 2.941s, then it surprisingly crashes. The courant number and the residual looks fine, that’s why I’m surprised.
I’ve tried to run the simulation till 2.9s and restart it with a smaller writeInterval and the writeFormat in ascii to analyze the results.
Unfortunately this didn’t work because the restarted simulation crashed in the first iteration although I have not changed anything crucial.

Any help is greatly appreciated, thanks!

1 Like

Note that the case of @Ulrich and the tutorial simulate different scenarios (FSI2 vs FSI3).

Could you please also upload your solver log? That would be more helpful to understand what is going on.

Hi @Makis ,

thanks for your reply!

I’ve checked my solver log again and saw that the residual of the pressure is diverging.

Here are both log files for the last few iterations:
log_CX.log (3.7 KB)
log_OF.log (7.7 KB)

Hi @Makis

Did you find anything remarkable?

I’ve tried to get the restart to work but unsuccessfully. I don’t know why my simulation runs longer than 2.9s, but when I try to restart it at 2.9s, it won’t run.

I don’t see anything useful in the log files. However, here are a few things to consider:

  • One issue could be that the fluid mesh is getting too distorted. Have you checked the quality of the mesh just before it crashes? It can be that cells get too skewed or even too small (essentially collapsing). Different mesh motion solvers could help, but options are limited (and I think in the reference you used, they are using a special mesh motion solver).
  • What kind of elements are you using in CalculiX? We recently discovered that it is very easy to get much better results using different types of finite elements: Change C3D8 elements to C3D8I elements in perpendicular-flap solid-calculix by AndresPedemonteFIUBA · Pull Request #250 · precice/tutorials · GitHub
  • How do the results compare to Turek-Hron for the times you already have? Plotting the watchpoint (displacement of the tip of the flap) could help. I assume that you get higher displacement than expected, which makes everything worse.

By the way, @DavidSCN’s expertise may be helpful here.

Hi @Makis

I’m sorry for the delayed response. I was doing a lot of testing on this case and ran from one problem into another.

That was my first guess too, so I tried to get a picture of it but the problem was that the simulation takes up too much storage with a writeinterval of 0.001 in ascii as well as in binary.
So my next try was to restart the simulation at a previous time to save some storage like I stated before. But this still doesn’t work and I don’t know why because in other cases it works out fine.

I tried using the C3D8I elements for CalculiX but as you have already predicted, it has only gotten worse. The Simulation crashed after the first few 100 Iterations.

After some research I’ve found this post and tried to copy this FSI2 case but can’t get it to run. Is there any way that I can download the whole case from Github like the tutorials? (I’m not that into Github) At the moment I can only take a look at the code.
For now I would try this FSI2 case to ensure that the error is not with my adapters.

Hi @Makis

To keep you updated:

In the near future I will run the simulation on a large cluster with a lot of storage.
Therefore I will get the exact timestep where the simulation crashes and can analyze the distortion.

I will post the results so we hopefully can get a better picture of the problem.

1 Like

Sorry for the late reply. Yes, you can do:

git clone -b nithinadidela-patch-1-Turek-Hron1 https://github.com/nithinadidela/tutorials.git
cd tutorials/FSI/Turek-Hron

Hi @Makis

I’ve done a lot of testing and got some progress.
Currently I’m running successfully the FSI2 case of the Turek&Hron benchmark.

I’ve made serveral mistakes and ony could get it to work with the help of the GitHub repository!
The problem was mainly at CalucliX:

  • I didn’t use DIRECT
  • The C3D8 elements are quite weird. I’ve switched to C3D20 and C3D20R.
  • Reducing the thickness of the z-axis (which is marked as dead in the precice-config) helps, so there are no ‘super streched’ elements

Towards FSI3:
The simulation is running really stable until 0.141s then it suddenly stops with a (to me) meaningless error message.
It is kinda strange because I did a lot of research and considered the following things:

  • End-time for both participants are set to more than the actual end-time of preCICE
  • The INC in the CaluliX inp file is set to 100000000
  • My precice-config is set to max-time and not max-time-windows
  • It doesn’t care if I adjust the time-step

The simulation always stops after the mapping of the force, where usually the mapping of the displacement starts. Could it be a distorted mesh?
The only error message I get is the following:

(0) 15:53:40 [com::SocketCommunication]:730 in receive: ^[[31mERROR: ^[[0mReceive using sockets failed with system error: read: End of file

CalculiX is therefore ending with an broken-pipe error.

Is there any progress regarding FSI3 in the preCICE-universe? Because I know that many other people tried it before in the forum.

UPDATE:

FSI3 is now running properly. I messed up the inputs while setting up the case…

Now I’m facing a new problem:
Since im working on a cluster, I have a limited simulation time of 24 hours.
Therefore I have to restart both FSI2 and FSI3 simulations to get to 35 and 20 seconds.

But the restart doesn’t work quite well. It fullfills the whole 100 subiterations before it crashs at the beginning of the second timestep.
I did infact turn on initialize=1.
Set both solvers to the same endTime so the .rout is constructed.
Reconstructed the last timeStep for OpenFoam and copied it to the new restart directory.
Set the startFrom to latestTime.
Set max-time-windows instead of max-time because it works better with Calculix.
And my .inp file looks as follows:

*RESTART, READ, STEP=1
*STEP, NLGEOM, INC=100000000
*DYNAMIC, DIRECT
0.001, 20.0
*END STEP

I really have no clue what I am doing wrong at this point after reading every entry in this forum regarding a restart of the simulation.
I would grately appreciate any help, because I have to finish my thesis soon and this is the last step to get my results done for comparing with the literature of Turek & Hron.

1 Like

Could you please provide your complete case you are trying to restart including the results (especially the preCICE convergence and iterations files)?
Restarting can also be tough numerically.

Thanks for your fast reply! Appreciate it!

Here is the whole case:

I’ve cut out the processor and .frd files because they are really big and they sit on the cluster itself.

The “…start” folders are the ones that ran from start to 15 and 10 seconds for the FSI2 and FSI3 case.

EDIT:
I’ve noticed that the blockmesh and potentialFoam is still in the run.sh file of OpenFOAM from the restart. Removing them leads to a crash in the third iteration due to large forces in CalculiX.

Hi @Johannes_S,

another thing you could try out is to use ALPHA=0.0 similarly to the following configuration of another tutorial case.

I did not see any hints into this direction above and I remember Richard having trouble with the FSI3 benchmark during the work on his bachelor’s thesis when using certain parameters in his time stepping scheme (see section 5.2.3 in Richard’s thesis).

For the perpendicular flap tutorial case we compared different solvers and got identical results in the latest preCICE reference paper. Therefore, I’m optimistic that ALPHA=0.0 in CalculiX produces something that is similar to our FEniCS-based case, where we use the Newmark-beta method.

Disclaimer: I’m not 100% sure how the timestepping scheme that CalculiX uses actually works.

@Johannes_S

Could you please upload the files precice-Solid-convergence.log and precice-Solid-iterations.log of your restarted run?

Could be tough for the quasi-Newton scheme to restart, but maybe tweaking the filter could help. The iterations file should tell us how well the filter works.

How does the structure look like after restarting? Do you get the correct displacements in OpenFOAM through the data initialization?

(sry for my slow reply)

Hello everybody,

I’ve finished my thesis on the case above. I’ve got really great results and I’m looking forward to make a paper of my thesis, so I can upload it here.
I’ve also made a pull request on GitHub for the CalculiX files. The OpenFOAM ones should also be uploaded, because there are some differences.

Regarding the problem of the restart, I couldn’t figure it out… I simply requested a longer computing time on our HPC cluster.

4 Likes

Thank you for contributing, @Johannes_S!
Related PR: Turek-Hron FSI with OpenFOAM and CalculiX - #16 by Johannes_S

Hi @Johannes_S ,

I am trying to use your CalculiX files for Turek-Hron FSI, however, when I run the solid participant, it throws an error: Read data ‘Stress’ does not exist!

I guess there’s incompatibilty between the original Openfoam files and your Calculix files. Could you please give some help?

Thanks in advance,
Yang

Hi @Yang_Zhang ,

yes that is right. I’m currently working on it and I will open another pull request for the OpenFOAM files I’ve used, because the ones in the tutorial won’t work with my CalculiX files. Then the case should be compiling.

I think this will happen today or tomorrow. I will link the PR here.

2 Likes

I’ve created my own repository for the case.

The code for the whole case files is here. With this files, the case is able to run and produce good results that I’ve compared to different literature data in my Bachelor’s thesis.

EDIT:
Is there an easy way to implement this as a pull request into the precice/tutorials fork?

NOTE:
I used Force instead of Stress like it’s in the tutorial for deal.ii