Hi Matteo and Jaas,

How did things work out with your strong FSI solvers? I'm a little bit stuck at the moment. The problem seems to be related to the "moving timestep continuity error" which is blowing up sooner or later. I have not yet found a way to keep that under control.
How did you go about implementing the strong FSI at densities of fluid/solid being very close to each other?

I would be grateful for hints as I'm uncertain about where to search for the cause of my problem.

Cheers,
Wolfgang

Hi Wolfgang,

I've been following this and other topics about icoFsiFoam for a while and recently started working with this solver, too.

At the moment I'm at the process of validating icoFsiFoam on the 2006 benchmark of Turek and Hron [1]. It's a 2D geometry with a submerged cylinder with a flexible beam attached which gets deformed by the vortex separation at the cylinder.

The density ratio is always set to 1, so depending on inlet velocities and structural properties Turek and Hron proposed "easy" as well as "hard" versions of the same case. I think it could be a suitable test case since you can easily control the FSI difficulty and the geometry is simple and 'blockMeshable', just have a look at the details (paper | slides).

I'm still at the beginning of my evaluation but I can already say that first results are quite promising despite the fact I'm using an unmodified icoFsiFoam (just added stress and displacement components output).

I noticed that the solution has a noticable dependance on solid mesh size which prevents me from getting any closer than about 10% to the published displacement results at least on the "hard" case. I could not yet figure out what's the reason, so I'll have to run additional tests on that issue.

It would we great if we could collect all of the existing additions and modifications of icoFsiFoam currently floating around at a central place (maybe the wiki?) so that they could be compared, combined and improved. At least it would make things easier for users like me who would like to start modifying icoFsiFoam.

Best regards,
Johannes

[1] Turek, S.; Hron, J.: Proposal for numerical benchmarking of fluid-structure interaction between an elastic object and laminar incompressible flow, Bungartz, H. J.; Schäfer, M., Lecture Notes in Computational Science and Engineering, 53, 371--385, Fluid-Structure Interaction - Modelling, Simulation, Optimization, Springer, ISBN 3-540-34595-7, 2006

Hi Johannes,

Thanks for pointing out the paper - it's a quite interesting read!

It's a great idea to collect the different modifications of icoFsiFoam circulating at the moment. Probably someone with some experience in the field would even be able to merge them to a pretty powerful new FSI solver. I suppose it would be of great value for many OpenFOAM programmers.
You should publicize this idea to a larger audience and see if people are interested - I most definitely am interested :-)

Cheers,
Wolfgang

icoFsiFoam foa a 3D case
 

Hi foamers,
Can you help me setting up a icoFsiFoam for a 3D case?
I know it uses stressedFoam as the structural solver but it's been used only for a 2D case I haven't found any 3D tutorial about that.
Is there somebody ho has just make it?
thanks
Aldo

Even the 2D cases are "real 3D cases" but with a thickness of "1".
Do not forget =>OpenFOAM uses always 3D cases!
goto
http://www.tfd.chalmers.se/~hani/kurser/OS_CFD_2009/ and search for fsi
or the stuff by Karl Jacob Maus:
Weakly coupled fluid-structure interaction
Solvers for weakly coupled fluid-structure interaction problems are built by combining existing solvers and methods for mesh-movement in a generic way. Test-cases are set up for a variety of problems to be solved.
Report, Presentation, Code, Cases

So learn to use some of the preprocesseing tools other than blockmesh.
Maybe http://www.discretizer.org/ or netgen or gmsh or engrid salome
i remember that somewere @
http://www.dhcae.de/ there is the bambreak in a more complex "city" exampleas a presentation

greetings

elvis

what's going wrong?
 

So I guess it's my fault,
I set up a 3D icoFsiFoam case of a pipe deforming under the pressure load of the fluid passing through (it is close to the 'arteria' case in http://www.dhcae.de/ ) . It is a transient case but I have no convergence, can you give me some advice of what could be wrong in order to take care?
how to set up icoFsiFoam? What kind of dinamic mesh to use?
thanks

I am sorry but I am not an FSI-expert.
All I can advise you to read
http://www.openfoamworkshop.org/2007...re_Interaction
http://powerlab.fsb.hr/ped/kturbo/Op...Zagreb2007.pdf
=> there stands small timesteps to have a courant number around 1

3d icoFsiFoam
 

Hello Aldo,
no, no solution yet. I'm working on 3d sonicLiquidFsiFoam solver in 3d.
If i have results i could send it, or we could cooperate if you are interested in compressible viscous fluid-structure coupling. What's your application ?
Thank you, Frank Böhnke, Munich Germany

of course, let's try reach a solution together
 

Hi Frank,
My application is an incompressible Fsi but I'm interested in all Fsi studies. My problem is a lack of convergence in a transient case in icoFsiFoam. I can tell you:
- I imported a gambit mesh of a 'L' shaped pipe costrained in the first end
- I have doubt about the choise of plane stress/strain (for a real 3D case is neither the first nor the second case)
- What kind of dynamic mesh to use? (it is not a 2D motion of course)

I'm going to change case (a simplier mesh) of a 3D cantilever beam (already studied by OpenFOAM community but I haven't the case files)

what about your problem? Have you got convergence?

Hello Aldo,

it´s me again.
Have you used Bernard Gschaider´s http://openfoamwiki.net/index.php/Contrib_PyFoam PyFoam?
=> pyFoamPlotRunner.py it can plot residuals or Courant No., so you might have a idea if your case converges.

No, I haven't, but my log is clear, courant number diverges at the second/third iteration. I think is a structural solver fault but I can't define where exactly.

Hi everybody,

Frank, you were mentioning that you're working on a compressible FSI version. This sounds most interesting to me.
So far I have been using icoFsiFoam but as Elvis was pointing out quite correctly this solver runs into a lot of trouble when using smaller time steps. For my envisaged application, though, I'll need to work on very small time scales.
I was told that employing a compressible solver for the fluid and just rendering the fluid 'almost' incompressible could solve the time-stepping problem.

Could you give some ideas or hints about which compressible solver you included into the FSI and how you implemented the whole thing?

Cheers,
Wolfgang

sonicLiquidFsiFoam
 

Dear Wolfgang,
as a foundation for the sonicLiquidFsiFoam solver I will use the decompressionTank example from the Programmers Guide. Right now I work on an extension to the stressFoam solver to use it for orthotropic solids for the fsi coupling.
Best regards, Frank Böhnke, Munich

Dear Frank,

Thanks for your speedy reply!
I had a go on sonicLiquidFoam and was able to integrate it into a small test scenario I built. This solver seems to fit my needs very well - so I'm happy :-)

Thanks again!

Best regards,
Wolfgang

icoFsiFoam problem with restarted simulations
 

Hi,
For future interests in doing FSI simulations, we are taking a look at icoFsiFoam in OF 1.5-dev in conjunction with the flappingConsole case (flappingConsoleSmall_HJ_21Mar2008.tgz), which includes several steps of saved field data up to t = 0.024 [s] and the simulation is setup to start from the latestTime. However, we are having problem in restarted simulations.

Here I attach a figure where the x-directional displacements at the top of the console are plotted for three cases: the red line is a restarted simulation from the saved data at t = 0.024 [s] (which is how one would usually run icoFsiFoam), the green line is a fresh simulation started from t = 0 by deleting the saved data, and the blue line is also a freshly started simulation but stopped at t = 1 [s] and restarted from there. There's no wonder in the difference between the red and the green/blue lines if the saved data and our data are calculated by e.g. different solvers, but what was problem to us was the discrepancy between the green and the red lines after t = 1 [s].
Attachment 4082

The main cause of the discrepancy, besides other unsignificant ones, was sorted out to be the patch-to-patch interpolation weights between the fluid and the solid moving meshes not being updated per time step basis, hence the interpolation weights calculated at the time of simulation (re)start were constantly used during the simulation run regardless of the mesh movements. So here is what we tried to correct the issue:
And the results with the patched icoFsiFoam are:
Attachment 4083
This time the green and the blue line agrees perfectly (up to around four significant digits) and the oscillating frequencies of all cases as well. Besides, combined with the results of other runs we have a general impression that the stability is also better. However, the displacements changed too drastically, to around an order of a magnitude smaller compared to those with the unpatched icoFsiFoam. Thus we are unsure if the omission of movePoints() as shown in the patch is a bug or intended for some reasons.

We'd appreciate any inputs, thoughts, comments. Thanks!

Takuya

Hello takuya,
your post is very interesting and the results you show are quite surprising: there should should be no effect in "restarting" the case but evidently there is!

I thought that the mesh::movePoints would have called automatically also the path-to-patch=interpolation:movePoitns() but evidently not otherwise your extra call should have made no difference...

I believe that the weigths HAVE to be recalculated at every time step (as much as one can try to move both patches unifromly, the two meshes are sliding a little bit one respect to the other.. and in any cases, if they are not, recomputing the weights should make no difference...) ...

Thus , yes, what you posted is very interesting and very worrying!
Thanks for posting it,
matteo

Hi matteo,
Thanks for the encouraging comment :) However, we're finding tracking down the other problem (the varying results) is not so simple because even changing face ordering of the interface patch (by tweaking the patch definition in blockMeshDict) radically changes the results. According to my fellow the static displacement at converged steady state agrees with the theory only when a certain face ordering is used. We'll keep you posted if we make a progress.

Takuya

hello takuya,
one more thing that has come to my mind: are you running in serial or parallel? because the patchtopatchInterpolator doesn't work in parallel at the moment (You have to modify it and use globalZone-reduce-etc etc..).

anyway I will try on my FSI test case i f i have the same issue you report and let you know..

Thanks about the input matteo. We are currently running only in serial, but may take a look at the interpolator (not so soon though).

Takuya

Ok, i have tried to restart one of my FSI simulations and indeed things changes.. in my case actually my FSI coupling fails to converge (!) but anyway definetely there is something wrong there..