- **OpenFOAM Running, Solving & CFD**
(*https://www.cfd-online.com/Forums/openfoam-solving/*)

- - **icoFsiFoam implementation with Turek/Hron benchmark**
(*https://www.cfd-online.com/Forums/openfoam-solving/101712-icofsifoam-implementation-turek-hron-benchmark.html*)

icoFsiFoam implementation with Turek/Hron benchmark1 Attachment(s)
Hello All,
I've been using/struggling with OpenFOAM and more specifically icoFsiFoam for awhile now. I too am trying to run the Turek/Hron FSI benchmark with icoFsiFoam using a self made mesh and cobbling together the rest of the case files from the flapping console example. checkMesh is fine with my mesh, but I'm getting a floating point exception which I am unsure of how to track down. I'm currently running everything in OpenFOAM-1.5-dev on Ubuntu 9.10 if that helps. Attached should be the case file. Any help would be greatly appreciated. BTW, my end goal is to build a solver that can handle the heat transfer from solid to fluid or vice versa. |

icoFsiFoam implementation with Turek/Hron benchmark1 Attachment(s)
Hello,
I'm attempting to use icoFsiFoam to solve the basic FSI benchmark set forth by Turek/Hron. I've created a mesh for both the fluid and solid which checkMesh seems to indicate is OK. I've run just the fluid part using icoFoam with great results, but when I try and use icoFsiFoam, I end up with a floating point exception which leads me to believe there is an issue either with the solid part of the domain or the coupling of the two domains. I've attached the case file if anybody is interested. My end goal is to create an FSI solver that incorporates heat transfer between the solid and fluid and vice versa. It seems though that an easy way around this would be to just specify the BC at the interface with a uniform temperature and see how it diffuses into either domain. This of course would only be for a simple case (ex. if the solid "tail" is at a constant temperature and we want to see how the effect of oscillation on heat transfer). If anybody has any questions regarding regarding the setup or my goals, feel free to ask. I have tried to do my best at looking through all of the other related icoFsiFoam threads, and they have gotten me this far, but now I'm stuck. Any help would be appreciated. -Andrew |

Hello!
The original IcoFsiFoam is a partitioned explicit/weak FSI solver. I managed to run the first of the three FSI cases proposed by Turek-Hron, but not the other two, this is simply because of the weak coupling between the fluid and the solid in the original solver. In order to solve the strong physical problem of the third case, i.e. fluid/solid ratio =1, you need to "tighten" the coupling. In other words you need an implicit/strong FSI solver. You can do this simply by rewriting the code to sub-iterate within each time-step, a strong physical coupling requires strong numerical coupling. Now, the original code has been re-written many times in order to solve strongly coupled FSI problems. I think you can ask H. Jasak for these implementations. For the heat-transfer I would recommend Robert Campbell work previously suggested in other icoFsiFoam threads. |

Hi,
take a look at Multi-Region Conjugate Heat/Mass Transfer MRconjugateHeatFoam: & Files or Block-coupled solvers, those Block-coupled stuff comes with OF1.6-ext so you might what to download the LiveDVD that was made for the 6th OpenFOAM Workshop |

Hello,
Thank you very much for your response. Do you happen to recall how you implemented the initial FSI benchmark as proposed by Turek & Hron. (I'm assuming you are referring to the example where U=2 m/s; however the data I have shows that to have the fluid/solid ratio = 1) I am guessing that I need to reduce my time step possibly a bit more and turn off run time modifiable to eliminate the floating point exception. Any pointers on how to just run the basic icoFsiFoam on a weak FSI case or eliminate floating point exception errors would be greatly appreciated. Thank you also for pointing me in the direction of Campbell's work. Andrew |

FSI and Courant NumberAs a general question, when trying to ensure the Courant number remains less than one, why does the density matter? It was my impression that it was mainly based on velocity and time step. Does the density play into the wave equation and the propagation speed of the wave? What am I missing here? Reducing my fluid density by an order of magnitude or two seems to eliminate my floating point exception which I thought was caused by my velocity BC. Any help or pointers would be appreciated.
Regards, Andrew |

Hello!
Sorry but I didn't have time to check your implementation, I think you are mixing CFD, CSM and FSI tests. Before going to FSI cases make sure your CFD subcases are ok, it is here you have to consider Courant number and all other CFD convergence criterion discussed in many threads here. On the CSM side it is quite easy setup and will not be any problem, dont forget that E-module is changed, not just the density later in FSI setups. Now, when coupling these together (already checked and converging on theire own) starting with solid/fluid density ration od 10, decreasing the time-step will make it worse, there are many articles describing this phenomena and just googling FSI convergence will give you hundreds of them. The current icoFsoFOAM will diverge as I remember when the ratio is between 5-6 for Turek-Hron case, i.e. starting with the density ratio case of 1 will not converge. This has been proven in many articles as well, 20-30 so far just on the Turek-Hron case. Once again, the strong physical coupling requires a strong numerical coupling, in practise this means that you have to: during one single time step, take a small portion of the pressure from the CFD solver (say 10% of total), apply it on the solid, deform it and repeat this until all pressure is applied before going to the next time step. As I wrote before this has been implemented before, you can probably find these, check with the OpenFAOM extension community at their webpage. Looking for reason of diverging FSI solver before insuring CFD and CSM/FE solver convergence is a nightmare and to my knowledge impossible due to the vast number of possible reasons, this is why Turek and Hron proposed first the 3 CFD cases, then 3 CSM cases, and at last, if successful with those, the 3 coupled or FSI cases. This, off course requires knowledge on CFD as well as FEA-analysis before the coupled analysis. I will check your implementation as soon as I can, I can send you mine if I find it, just send me your email-adress. |

Hello,
Thank you so much for your insight. I started by running the CFD cases for certain versions of the case set-up, but possibly not all of them. I'm thinking I may need to sort of start over with my testing and keep better track of all of my cases. I do have a weak background in FEA and CSM so I should probably brush up on that. Thank you for pointing out the issue with decreasing the time step. I thought that I had read somewhere in the FSI forums that decreasing would improve convergence but I found a really good paper explaining time step versus convergence for weakly coupled solvers. I have emailed Prof. Jasak about the more strongly coupled solver but will also check out the extend website as well and see what I can find. I can't thank you enough for your help, I've been pretty stuck for a while now. I'll PM you my email address. Regards, Andrew |

I've been working on this problem a little bit more recently and have a couple of questions. How does OpenFOAM know which "U" it is looking for, i.e., velocity in the fluid and displacement in the solid. I know that in the solveSolid.H file there is a reference to Usolid. Where is this variable ever defined? The only include file is readStressedFoamControls.H and it only calls the ncorrectors and convergence tolerance. How does OpenFOAM know to look in the solid directory for Usolid? Any help would be greatly appreciated.
Regards, Andrew |

All times are GMT -4. The time now is 15:19. |