[mathieu]

Hi Pascal,

I guess this post will answer your questions :

http://www.cfd-online.com/OpenFOAM_D...tml?1212050934

Regards,

Mathieu

[boehnke]

Hello Frank,
do you still work on Fluid-Structure coupling using icoFsiFoam. I'm very interested in it concerning Mechanics of Hearing, but i don't know how to get an actual version of it (icoFsiFoam).
Thank you for your answer, Frank Böhnke, Munich

[mathieu]

Hi Frank,

You need the "-dev" version of OpenFOAM from OpenFOAM-extend:

http://sourceforge.net/projects/openfoam-extend/develop

Mathieu

[WiWo]

Hi Christoph, hi everybody,

I was also thinking about how to transform icoFsiFoam into a solver that can treat strongyl coupled systems (blood - vessel wall interaction in my case). Following the suggestions in by Zeljko Tukovic I was also thinking of cycling several times over the solid and fluid parts. But I'm not quite sure about how to da that exactly.

Christoph - did you have success in developing your strongly coupled solver? Could you or anybody else in here give me some advice on how best to tackle this problem?

I would be very greatful for any help, advice, hint, ...

Cheers,
Wolfgang

[boehnke]

Hi Wiwo,
yes , I'm still concerned with fluid-structure coupling, but did not have too much effort up to now. Up to now I was not able to install the needed OpneFOAM-1.5-dev version correctly on 32-bit (or 64-bit) OpenSuse 11.2 System.
I'm grateful for any solutions (wit icoFsiFoam).
Frank Böhnke, Munich, Germany

[Jaas]

Hi everyone,

I am trying to make icoFsiFoam to solve strongly coupled problem. I implemented the inner iterations over solid/fluid solvers but this change only did not help me, my test case is still blowing up. I was wondering if some of you have already working strongly coupled icoFsiFoam code with Aitken under-relaxation algorithm implemented. I would be grateful if you could share this or give more detailed information how to implement these changes.

My goal is to simulate flapping tail of the fish with density ratio 1.2 and low structural stiffness. Right now testing on case with 2d cylinder with flexible plate attached to it.

Jaas

[boehnke]

Hi Jaas,
sorry cannot help for the strongly coupled problem. I am working with the myIcoFsiFoam solver for weakly coupled problems by K.J. Maus (Norway) and try to couple a plate to an incompressible fluid (mechanics of the ear). As you are concerned with low structural stiffness you might be successful with the linear elasticity approch in OpenFOAM. I would be looking for an approach implementing the high bending stiffness of anisotropic plates.
Frank Böhnke, Munich

[WiWo]

Hi Jaas,

Seems that we are working on pretty similar problems. I'm concerned with blood in a compliant blood vessel also having a density ratio of pretty close to 1. Would be a good idea to share some ideas?! :-)
What exactly is the problem with your code? Does the mesh blow up (that's what happended to me because i was not compensating the mesh motion in the inner loop correctly) or is it the solution itself? Please give some more details so we can address the problem specifically.

How about the Aitken under-relaxation? Did you succeed in implementing it into your solver? I'm stuck with that because my under-relaxation factors occasionally go below zero or beyond 1.

Cheers,
Wolfgang

[Jaas]

Hi Wolfgang,

I haven't done much with my solver jet. I added inner iterations into time step but with that change mesh blows up if I try to change my test case towards stronger coupling. I don't have any mesh motion compensation in inner loop. Can you give me some hints how to do that?
Unfortunately I don't have Aitken Under-relaxation algorithm either. Still doing some research about that. Thought that someone in this thread must have succeeded with implementing it.
Can you share your progress with Aitken under-relaxation algorithm. I would be more than happy to help figure out what is wrong with it. Right now I just don't know where to begin.

Jaas

[WiWo]

Hi Jaas,

If your mesh is blowing up then you committed exactly the same error as I did at that time :-) Mathieu was so nice as to point that out to me and provide help - see thread.
Ok, so what you have to consider is, that by using the inner loop you're running setMotion.h several time - telling the solver to displace your mesh boundary EACH ITERATION by the amount calculated in solveSolid.h. Now, that's a bit too much :-) So you have to compensate in a way as to ensure that at the end of the timestep your mesh will have been displaced only by the final value of Usolid.

So what you can do is the following - it's Mathieus idea:

Declare a variable "volVectorField deltaUsolidPrevious = 0*Usolid" somewhere before the start of your time loop

change the first statement in setMotion.h to include a variable "deltaUSolidPrevious"

pointVectorField solidPointsDispl = cpi.interpolate(Usolid - Usolid.oldTime() - deltaUsolidPrevious);

and set "deltaUsolidPrevious = Usolid - Usolid.oldTime(); " immediately after that.

Now this is fine within one time step - but to assure that you don't mess up when jumping from one time step to the next you'll have to reset deltaUsolidPrevious to 0 before entering a new time step.

Therefore set deltaUsolidPrevious *= 0 at the start of every new time step (obviously before you enter the inner loop).
... this should work then :-)


With respect to the Aitken stuff ... so far my attempts to implement it failed because the under-relaxation factor quickly went out of the interval [0 1], where it should be confined according to my understanding of the topic. Thomas has drawn my attention to a PhD thesis where the method is described in more detail. So I'll read through the text and see can solve the problem.

Cheers,
Wolfgang

[Jaas]

Hi Wolfgang,

Thank you for the instructions for mesh compensation. I did as you said and my solver went more stable but I still can't get near density ratio O(1). I get very odd deformations of the solid(sometimes it just expands so that solid boundary extends over domain boundary).

In another thread Mathieu mentioned that setPressure.H file should be independent of the solid solution in case of large deformation. Do you know what did he mean by that?

Jaas

[WiWo]

Hi Jaas,

Yes, I read Mathieus note in that thread before. I'm not sure what he was referring to by this remark.
Anyway, maybe you want to consider transferring not only the pressure but also the traction from your fluid to the solid (in setPressure.h). Note that tForce has two members which can be set - pressure and traction (see tractionDisplacementFvPatchVectorField.H / .C for details). I'd guess that in that way your calculation becomes more complete and maybe the odd deformations disappear.

Cheers,
Wolfgang

[matteoL]

Hello all,
I am trying to develop as well an FSI problem and my first test case would be blood flow in an blood vessel..

I have started from the icoFSIfoam solver and added:
-PISO solver instead of SIMPLE (since i want a transient simulation)
-ALE coupling
-subiteration

As you have correctly pointed out, when subiterations are added, special care has to be taken for the update of the different quantities.

My question is: what about the ALE convective term?
Since we are subcycling, at the n-th ietartion the mesh is just a little bit (the extra deltastep) and thus the ALE term should not jus simply be the meshmotion velocity of that subiteration, but the total meshmotion of the substeps.
The problem is thus to identify what the fvc::meshPhi(U) operator actually does. Does it compare the position of every cell with the position at the previous time step (in this with the usual makeAbsolute/makerelative I should be fine ) or just take the meshvelocity of the last meshmotion call (and thus i have to create a variable totalMeshMotion and add the contribution of every subiteration)?
any idea?

2)If instead of passing from fluid to solid just the pressure i wanted to pass the whole stresses (pressure+viscous stresses), how do i do that? is the "traction" member defined in tractionDisplacementFvPatchVectorField.H?

thank you very much,
best regards,
Matteo

[matteoL]

Looking deeper into the code it seems to me that MeshPhi(U) just takes into account the last MeshMotion and thus in case of subiterations it doesn't work.
Here is why i believe so:

-the command meshPhi(U) calls (in case of Euler scheme) simply mesh().phi()

-fvMesh:hi() returns *phiPtr_

-*phiPtr_ is called/created by Foam::fvMesh::movePoints which does
...
surfaceScalarField& phi = *phiPtr_;
....
tmp<scalarField> tsweptVols = polyMesh::movePoints(p);
00582 scalarField& sweptVols = tsweptVols();
00583
00584 phi.internalField() = scalarField::subField(sweptVols, nInternalFaces());
00585 phi.internalField() *= rDeltaT;
....

thus mainly evaluates how much every cell has been moved and divide it by the timestep. This means that in case of subiterations, it is taking into account only the last subiteration movement while, in order to be correct, it should take into account the whole motion, i.e from the previous time step (and not subiteration).

Am I correct?

Thanks,
matteo

[WiWo]

Hi everybody,

First of all - the traction can be set using tForce.traction() in the setPressure.h. You can see how the pressure and/or traction input is treated in tractionDisplacementFvPatchVectorField.C in the updateCoeffs() method. I think, while in the original icoFsiFoam only pressure is transferred from the fluid to the solid region in case of strong coupling one should also take care of the traction to be on the right way. This might also solve part of your problem with the oddly deforming mesh, Jaas.
On what concerns the meshPhi - Matteo made a very interesting observation there. I'll have to give it a closer look. Still, I already assessed that my mesh is also failing in some cases due to "moving mesh time step continuity errors" blowing up. This quantity is calculated in movingMeshContinuityErrs.h and involves phi and meshPhi. So maybe we're all facing the same problem. I have never really tried to find out what meshPhi exactly does or represents. Matteo, can you explain that in a little more detail?

I was wondering what you changed or added in order to implement the ALE and PISO.

Cheers,
Wolfgang

[matteoL]

Hello,
-concerning the meshPhi issue, I have been told by Prof Zeliko Tukovic (thus we can accept as the "the truth") that meshPhi is calculated in respect to the previous time step (and not previous sub iteration) thus I was wrong and the fvc::makeAbsolute and fvc::makeRelative can be used normally.

-Concerning the Ale and piso: if you want to solve a transient problem, then you must take into account the fact that the mesh is moving (ALE contribution) and as NavierStokes solver you cannot use the simple scheme (which is for steady state cases) but you have to use the PISO schemes.
Mainly all you have to do is integrate icoFSIfoam with icoDYMfoam (if i remember correctly, in truth i started from interDymFoam structure for the ALE/PISO part.. ).
How did you do otherwise?


-"I believe that the movingmeshcontinuity error may give error if you solve something in a moving mesh but do not take into account the ALE terms, because of course then there is volume deformation but no counterparts in the NS equations."(NOT SURE ABOUT THIS LAST PART)

Thanks for the traction suggestion, i will give it a try.

-Finally: do you know how to change icoFSIfoam in order to use the velocityLapcian mesh motion (thus FV) instead of the laplaceFaceDecomposition (FE)? the ReadCoulingProperties.H have to be modified accordingly (and also the interpolator call in the setMotion.H) but I am not sure with which term to subsitute the classes...
Anyone managed to do the change or has an older version that worked in that way?
(I would like to try the FV msh motion because in my cases it seems that the longest part of the solver is indeed that one, the solidsulver and NS are faster! And my cases are pretty simple, thus the FV motion solver should be robust enough..)

Thanks,
ciao,
Matteo

[WiWo]

Hi Matteo,

Your points about ALE and PISO are very interesting. I must state that I'm pretty new to the field of CFD in general and OpenFOAM in particular and am trying to catch up on both topics the best I can.
I understand your point about the PISO and I think I'm also going to implement it instead of SIMPLE. I actually was thinking that the movingWallVelocity BC takes care of issues related to ALE. At least that's what Frank Bos is stating (see thread).
Anyway, why does icoFsiFoam (the original version) work for weakly coupled systems without problems (using SIMPLE and no ALE)? Shouldn't there be PISO and ALE as well in order to yield correct results?

Could you give some hints about what to amend in icoFsiFoam in order to incorporate ALE? You mentioned that you basically merged icoFsiFoam and icoDyMFoam ...

I have never tried using the velocityLaplacian mesh motion - sorry, no experience there.

Best regards,
Wolfgang

[matteoL]

the icoFSI foam is correct if you just need the steady state solution, thus no need to make ALE correction.
The mobingMeshBC take care of the Meshmotion just on the boundary, but it doesn't update the internal field (it is indeed just a boundary condition). Thuu using icoFSIfoam with movingwallBC is quite a nonsense to me.

To add ALE just add:
-fvc::makeAbsolute(phi, U); before the cal runtime++ in the .C file.
-add fvc::makeRelative(phi, U); at the beginning of the solveFluid.H file

without subiterations this shoule be correct, while with subiterations some more adjustment has to be taken.
I am still working on it (and i think it is not yet correct what i am doing) thus cannot tell much about it yet..

I hope this helps,
ciao,
matteo

[WiWo]

Hi Matteo,

Thank you very much for your very quick replies and the provided support!

I have changed icoFsiFoam to contain ALE (inserting the lines you indicated) and I substituted SIMPLE by PISO. I took the very basic PISO from icoFoam - is that correct? I can run the flapping wing case and also my blood vessel case as long as rho of fluid stays 1. Otherwise I see a rapid increase in "moving mesh timestep continuity error". Is that also true with your code?

I'll try to do some testing tomorrow.
Cheers,
Wolfgang

[WiWo]

Hi Matteo,


Sorry to bother again. As I stated yesterday I successfully replaced the SIMPLE section in icoFsiFoam (inside solveFluid.h) by the PISO part from icoFoam and I also implemented the ALE.
Now I compared the results when running the flappingBeam case one time with the original icoFsiFoam and one time with the modified PISO-ALE version. It turns out the the beam is barely moving at all (motion 3 orders of magnitude lower than in other case) in the simulation with the PISO-ALE icoFsiFoam while the same case yields a nicely bending beam with original icoFsiFoam (see picture).
Did you also compare the two solvers on a test case like the flapping beam? Maybe I messed up on an important point - at the moment I just can't see where.

Do you have some kind of a tutorial or test case for your improved version of the icoFsiFoam which you would be willing to share?

I'd be very appreaciative for any help you could provide.

Best regards,
Wolfgang