CFD Online Discussion Forums

CFD Online Discussion Forums (http://www.cfd-online.com/Forums/)
-   OpenFOAM Running, Solving & CFD (http://www.cfd-online.com/Forums/openfoam-solving/)
-   -   Moving mesh problem with a FSI solver (http://www.cfd-online.com/Forums/openfoam-solving/58690-moving-mesh-problem-fsi-solver.html)

mathieu July 29, 2008 11:03

Hi ! I am currently develop
 
Hi !

I am currently developing a FSI solver (based on icoFsiFoam) that takes into account large deformation and strong coupling cases since I am interested in 2D oscillating flexible wing simulations. I did the following modifications to icoFsiFoam :

- I modified the structural solver to take large deformations into account;

- I implemented an external loop to ensure convergence of strong coupling cases.

Then, I managed to run a simulation of a 2D oscillating (relatively thick) plate with a rectangular profile. I made the case relatively easy (coarse grid, low Re number, weak coupling) and the simulation gave reasonable results. Then I ran a more realistic case (fine grid, naca profile, but still low Re and weak coupling) and the simulation crashed because of a mesh motion problem at the fluid-structure interface. The problem seems to be related with the patchToPatchInterpolator but I am really not sure... Take a look at the following picture :

http://www.cfd-online.com/OpenFOAM_D...ges/1/8542.png

Any help will be appreciated. Best regards,

Mathieu

nadine July 29, 2008 11:59

>Take a look at the following
 
>Take a look at the following picture :

So what?

mathieu July 29, 2008 12:37

Sorry, that was not clear.
 
Sorry, that was not clear.

Here is another picture :

http://www.cfd-online.com/OpenFOAM_D...ges/1/8549.jpg

Initially, the distance between points A and B is almost the same as the distance between C and D. After a few time step, points A and B are getting closer and closer and of course, once they are too close the simulation crashes. However, as you can see, points C and D remain at a correct distance (as many other points). Since the point motion at the fluid-solid interface is given (after interpolation) by the displacement field calculated on the solid mesh, I was wondering if that problem was caused by the interpolation itself.

Regards,

Mathieu

nadine July 29, 2008 14:13

You write that you are develop
 
You write that you are developing a FSI solver. Generally I find those developments interesting.

But how do you expect any guesses about your problem if you don't at least describe which algorithms you use and what is different compared to icoFsiFoam? Your problem can have thousand explanations, but it makes no sense to start discussion given your explanations.

mathieu July 29, 2008 16:28

Hi, I just run that simulat
 
Hi,

I just run that simulation again with the original icoFsiFoam solver and I get the same problem so I don't think the modifications I did in the code have something to do with that issue. Since the problem is located on the patch itself, I suppose it is a problem related with the interpolation. Is it the patch to patch interpolation, is it the fact that the displacement on the structural nodes is interpolated from the cell center values or is it something else... ?

So, if someone has encountered a similar problem using icoFsiFoam, then I would be pleased to have some feed back.

Thank you !

Mathieu

WiWo January 20, 2010 08:51

Hi mathieu,

I'm also working on adapting the icoFsiFoam solver to work for strongly coupled systems (blood - blood vessel - interaction).
I would be curious about how exactly you did implemented the external loop ...

I tried to loop over the block containing setPressure.h, solveSolid.h, setMotion.h and solveFluid.h ... unfortunately the mesh blows up very quickly and I don't quite understand why.

Could you help? I would be very grateful for any advice.

Best,
Wolfgang

mathieu January 20, 2010 15:18

Hi Wolfgang,

setMotion.H, line 4 :

You should replace

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

With something like

pointVectorField solidPointsDispl =
cpi.interpolate(Usolid - UsolidFromPreviousOuterIteration);

Of course, you'll need to define UsolidFromPreviousOuterIteration properly and update it at each outer iteration.

Mathieu

WiWo January 21, 2010 06:01

Hi Mathieu,

Thanks a lot for you very quick response! I was trying to implement the solution you suggested. By outer iteration you refer to the while loop of runTime? I tried to set UsolidFromPreviousOuterIteration right after runTime++ inside the while loop using
?volVectorField UsolidFromPreviousOuterIteration == Usolid' ... or should I use '=' instead? What's the difference?

Still, the situation did not change and my mesh is blowing up within less than 10 time steps. I also tried setting volVectorField 'UsolidFromPreviousOuterIteration == Usolid;' inside my inner interation cycle. Still not much changed.

It seems to me that updating the mesh and moving the stressMesh several times per time step is a problem. Should we somehow conserve the mesh structure that was present at the start of the time step?

Refering to Zeljko Tukovic's presentation slides (p.9-10) it seems that only pressure is transferred in the loop while all other parameters (and maybe also the meshes) retain their values present at the start of the time step ...

Maybe I'm getting the idea of the partitioned strong coupling approach by iterations totally wrong. Could you explain?

Thanks for your help and efforts!

Best,
Wolfgang

WiWo January 25, 2010 10:08

Hi Mathieu,

I found out that rotating the order of the called header files changes the comportment of icoFsiFoam significantly. To date I've been using the original order ...

while (runTime.run())
{

...

runTime++;
Info<< "Time = " << runTime.timeName() << nl << endl;

for (int myLoopCount = 0; myLoopCount < nLoops; myLoopCount++)
{
# include "setPressure.H"
# include "solveSolid.H"
# include "setMotion.H"
# include "solveFluid.H"
}
}

Moving solveFluid.H to top of that list prevents the mesh from blowing up. It changed the shape of the solution domain significantly though.

I also inserted the line 'UsolidFromPreviousOuterIteration = Usolid;' between # include "setPressure.H" and # include "solveSolid.H". Is that what you thought of by 'defining UsolidFromPreviousOuterIteration' properly?

It seems that my solutions still grow much too fast as soon as I do more than one cycle of the for loop. What am I missing here?

I'd be very glad for any help!

Cheers,
Wolfgang


All times are GMT -4. The time now is 02:08.