|
[Sponsors] |
July 29, 2008, 12:03 |
Hi !
I am currently develop
|
#1 |
Member
Mathieu Olivier
Join Date: Mar 2009
Location: Quebec City, Canada
Posts: 77
Rep Power: 17 |
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 : Any help will be appreciated. Best regards, Mathieu |
|
July 29, 2008, 12:59 |
>Take a look at the following
|
#2 |
Guest
Posts: n/a
|
>Take a look at the following picture :
So what? |
|
July 29, 2008, 13:37 |
Sorry, that was not clear.
|
#3 |
Member
Mathieu Olivier
Join Date: Mar 2009
Location: Quebec City, Canada
Posts: 77
Rep Power: 17 |
Sorry, that was not clear.
Here is another picture : 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 |
|
July 29, 2008, 15:13 |
You write that you are develop
|
#4 |
Guest
Posts: n/a
|
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. |
|
July 29, 2008, 17:28 |
Hi,
I just run that simulat
|
#5 |
Member
Mathieu Olivier
Join Date: Mar 2009
Location: Quebec City, Canada
Posts: 77
Rep Power: 17 |
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 |
|
January 20, 2010, 08:51 |
|
#6 |
Member
Wolfgang W.
Join Date: Nov 2009
Location: Switzerland
Posts: 57
Rep Power: 17 |
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 |
|
January 20, 2010, 15:18 |
|
#7 |
Member
Mathieu Olivier
Join Date: Mar 2009
Location: Quebec City, Canada
Posts: 77
Rep Power: 17 |
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 |
|
January 21, 2010, 06:01 |
|
#8 |
Member
Wolfgang W.
Join Date: Nov 2009
Location: Switzerland
Posts: 57
Rep Power: 17 |
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 |
|
January 25, 2010, 10:08 |
|
#9 |
Member
Wolfgang W.
Join Date: Nov 2009
Location: Switzerland
Posts: 57
Rep Power: 17 |
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 |
|
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Turbulent compressible solver rhoTurbFoam with dynamic moving mesh | eno | OpenFOAM Running, Solving & CFD | 4 | December 12, 2011 04:38 |
LES with moving mesh solver | gtg627e | OpenFOAM Running, Solving & CFD | 2 | July 23, 2007 11:40 |
Moving mesh forces on patches and turbulence solver | jackdaniels83 | OpenFOAM Running, Solving & CFD | 3 | May 31, 2007 11:29 |
First steps w moving mesh FOAM FATAL ERROR solver table is empty | tehache | OpenFOAM Running, Solving & CFD | 2 | May 14, 2007 05:59 |
moving mesh problem | walid | Siemens | 6 | April 1, 2005 18:31 |