|
I'm trying to make FSI simulation of elastic pipe. icoFsiElasticNonLinULSolidFoam is used for this. When I use default values for material my simulation works OK. But when I try to change them to actual (increase fluid density from 1 to 1141), my simulation crashes on second FSI iteration with
--> FOAM FATAL ERROR: zero and complex eigenvalues in tensor: (1.67727e+31 -3.07921e+31 -1.86008e+29 -2.51065e+31 4.60916e+31 2.78429e+29 -4.70076e+31 -3.74209e+31 6.17348e+31) From function eigenValues(const tensor&) in file primitives/Tensor/tensor/tensor.C at line 129. The test case and log file are here: https://yadi.sk/d/OAfhaP7egdTHG Can some one help me ? Thanks. |
Hello Svensen,
I also have the same problem. I use the icoFsiElasticNonLinULFoam Solver to run the HronTurekFsi Case. Unfortunately I allways get this mistake. Did you find a solution? I would be very grateful for anyone's help, thank you and best regards, Stephie |
I can only guess where the problem exists. As you know, in all classical OpenFOAM cases you never write the fluid density value. Here (in FSI cases) we need to define it explicitly. I've searched the code of icoFsiElastic...Foam solver and find only one line where this density value is used. It is used for calculation of the force action by fluid on the solid and formula looks like nu*rho. All looks fine, but in the HronTurek case you can see that the nu value is 1e-3 and rho is only 1 (ONE !!) it's very low ! So, using the formula we have 1e-3 *1 = 1e-3. But when I put my actual data into the fluid parameters, using this formula (nu*rho) I've got something like 6.5e-3. I only can guess that this value is to big for this solver or the discretization schemes which it used by default. So it's become unstable and crashes.
It's only the suggestion... If you will find the solution please let me know ! I need it very very much !! |
Hey, yes you might be right. I am running the case with a density of 1000 (water) which is really high in comparison.
Today I tried the hint of Philip Cardiff some posts before (#209). I changed in the rotateSolidFields.H rho = rho/J into //rho = rho/J My case run around 0.476 s, after it become struggeling and stops, because of floating point except. Time = 0.476, iteration: 34 Current fsi under-relaxation factor (Aitken): 3.47732e-08 Maximal accumulated displacement of interface points: 0.00970624 DILUPBiCG: Solving for Ux, Initial residual = 0.00112037, Final residual = 2.90452e-07, No Iterations 3 DILUPBiCG: Solving for Uy, Initial residual = 0.0060397, Final residual = 4.07335e-07, No Iterations 4 GAMG: Solving for p, Initial residual = 0.490316, Final residual = 0.00244083, No Iterations 6 time step continuity errors : sum local = 1.51006e-06, global = 5.84117e-09, cumulative = -0.000922631 Moving mesh time step continuity errors : sum local = 1.51006e-06, global = 5.84117e-09, cumulative = -0.000922625 Setting traction on solid patch Total traction force = (-18.9099 -18.0944 3.34335e-17) Solving for DU, Initial residual = 0.0130961, Final residual = 9.65723e-07, No outer iterations 142 Current fsi residual norm: 0.172987 Time = 0.476, iteration: 35 Current fsi under-relaxation factor (Aitken): 1.73919e-08 Maximal accumulated displacement of interface points: 0.00970624 DILUPBiCG: Solving for Ux, Initial residual = 0.00119781, Final residual = 4.88617e-07, No Iterations 4 DILUPBiCG: Solving for Uy, Initial residual = 0.0070903, Final residual = 1.57914e-07, No Iterations 5 Floating point exception If I irgnore this error, the case stops again, but again because of "Floating point exception". The last time this was the point where I got the error of complex eigenvalues. I am not sure if it helps to comment this line out for stopping the mistake of complex eigenvalues or if it is luck. I will further searching.. maybe there will be a better solution and the case will run. Did you try HronTurekFsi3 from extend-bazaar? It is amazing. It run really fast and it has already a density of 1000 included. Maybe this might be an other possibility for you. |
"Did you try HronTurekFsi3 from extend-bazaar? It is amazing. It run really fast and it has already a density of 1000 included. Maybe this might be an other possibility for you"
I've tried it today. Yes it is very fast, but when I've applyied my geometry and parameters to the test case there were no coupling. The solid domain didn't deformed... but in the old HronTurek case it works ! Very strange... |
Quote:
Yep, the new FSI framework (currently located in foam-extend-3.1/extend-bazaar) supersedes the icoFsiElasticNonLinULSolidFoam solver. Željko presented this framework at the OpenFOAM Workshop 2014 in Zagreb: abstract and slides. The major improvement with regard to FSI coupling is the implementation of the IQN-ILS algorithm: this seems much better than Aitken's/fixed under-relaxation. Also, the plugin approach used for the solid and fluid solvers should allow easier extension to other fluid/solid models e.g. multi-phase, compressible, plasticity, etc. Best, Philip |
Quote:
I think that we are working in the similar field, so we have the same issues with simulation.. |
Hey,
first, thank you Philip for the links to tha abstract and the slides :) I am sorry, but I didn't find a solution up to now. At the moment I try to figure out where the problem might be. The last days I tried to run the new solver of my tutor with the old HronTurek case. But it allways crashes after around 0.4 seconds. Yesterday, I turnd off the FSI to see if the fluid or the solid part might be the problem. With out coupling the case run, I can see the current. Than I tried to use the density and Emodul which is given be the case (density of 1 kg/m³ and E=1.4e6) and the case is still running ( at the moment 2.6sec). At home I startet the normal case with the icoFsiElsaticNon... and an adjusted density of 1000kg/m³. After 5 seconds the case stops because of complex eigenvalues. I am not sure if it works to commend "rho = rho/J" out..there is allways the same mistake with floating point and complex eigenvalues. I think the density might be the problem, but I don't know how to solve it... It would be wonderful if anyone had a solution. I really would like to use the old version to test the new solver of my tutor..it is the same structure. |
Some months ago I had similar problems with FSI calculation. But it was related to mesh displacement. Mesh quality became very poor and floating point exeption was raised.
Better mesh, and my problem disapeared. |
Quote:
Does the new solver work for you with the new cases? The Hron-Turek-FSI-2 and Hron-Turek-FSI-3 are both provided as tutorials and should just work. If your current case has convergence problems, I would closely compare the settings in the new tutorial cases to check if you have appropriate settings. There are some small but important changes in the new code, for example, in the Hron-Turek cases a function object is used to enable FSI coupling once the flow has developed; this overcomes problems at the start with the flag bouncing around before the flow has developed. Philip |
Hello Philip,
I couldn't use our new solver for the new case up to now. Unfortunately there are some differences with some terms. Maybe we will find a way and change this, so that we could run the solver with HronTurekFSI3. While the last days I run HronTurekFSI2 with our solver with a density of 1 für the fluid and a density of 10 for the solid, and an Emodule of 1,4e6. And it works...the simulation ist still running. I don't understand where the problem might be, when I increase the density of the fluid to 1000 and the solid to 10000. The case interrupts allways at 0.476s iteration 35. I tried many things, but it allways stops at this one point. I also tried to turn off the coupling and start with developping the fluid and later join the coupling, but it also didn't work. The fluid part runs without any problems. But together withe the solid part it allways stops. best regards, Stephie |
Hello everyone,
I am also enjoying the new FSI library, but I would like to run the FSI solvers from a different start point (like stopping the solver and then starting it up again), and I don't think that functionality is implemented. If I run the HronTureckFsi3 tutorial (in controlDict I set the startFrom to latestTime) for a few recorded timesteps and then stop it, I can't resume it with fsiFoam, the error that comes up is: Code:
--> FOAM FATAL IO ERROR: Also, when I try and do this in parallel I get this kind of error: Code:
[2]
Any help at all is appreciated. |
Quote:
Yep, having comparable fluid and solid densities is a difficult FSI problem; using a small fixed under-relaxation factor or the new IQN-ILS procedure should help to overcome the convergence problems. Philip |
Quote:
In theory it should not be a problem to restart, we just have to make sure all the relevant fields are written out (something seems to want to old cell volumes V0, and also the golbalFaceZone field in parallel). I will let you know if I get time to look at it. In short to answer your questions, yep it would be intended to include such functionality. Philip |
Stephie, I've found the way how to make FSI simulations stable, but I'm not sure that this way is totally correct. I've tried to analyse the log and I've found that at some value of interface displacement my simulations crashes. After searching the source code I've found the following patter:
Info << "Maximal accumulated displacement of interface points: " << delta << endl; if(delta < interfaceDeformationLimit) { // Move only interface points ... } else { // Move whole fluid mesh ... } When I changed the interfaceDeformationLimit value in the settings file, I've got a stable solution. But the problem is: at the beginning of simulation my elastic pipe deforms very well, but after some period of time the amplitude becomes slower and slower.. and have a value about 1*10^-9 m. I don't know is it a result of my trick or not, but it looks unrealistic for my case. Maybe you will try to make the same thing (increase value interfaceDeformationLimit to 10^6) and run your simulation. I think that together we can solve this problem (with FSI convergence and stability) much faster. Maybe Philipp Cardiff also will give some help to us... |
Hey Svensen,
today I tested your proposal -interfaceDeformationLimit 1e6 and the computation stops after 0.288 because of floating point exception..the displacement goes up to over 150 First I did a mistake and wrote 10e6..the simulation chrashes after 0.288 with a displacement of around 170.... I also tried to changed the number just a litte bit, I took 0.1, but it also stops after 0.216 seconds because of complexe eigenvalues. I am not sure if it is a goog idea to change this value.. the results seem to be unrealistic. I also tried the hint of Philip and changed the fixed under-relaxation factor and used the new IQN-ILS procedur.. but I didn't get better results. I will try further.. we will hopefully find a solution. |
1 Attachment(s)
Dear Cardiff and others,
HronTurekFsi3 in extend-bazaar was working fine, and then I tried to implement the similar case given in http://www.sciencedirect.com/science/article/pii/S0045782505005177 p. 5768 but unfortunately it gives me error I think that error belongs to blockMeshDict file. I went through that case many times but I couldn't notice the error. If any one could go through my attached case and let me know what is the problem, I will be really appreciated. Lots of thanks in advanced. Maimouna |
Hey guys,
Since I have been working on my master thesis with fsiFoam these past few months and since I had lots of problems that other people in these thread had that remain unanswered up at this point, I thought I would shed some light on these that I managed to solve (or temporarily bypass) and throw out a new issue I have encountered hoping that someone may shed some light. Also I want to thank the developers of this package and the continued support for the software and the community. First, to address the globalFaceZones issue during decomposition, there is a simple explanation. After some searching through the source code I realized that there exists a different utility called decomposeParFsi compiled along with the rest of the FluidStructureInteraction package of the extend-bazaar. This works like a charm for decomposing a parallel case, just make sure to setup the face zones of the interface between the 2 meshes properly. Took some search to find, maybe there should be some documentation included along with the solver in some of the tutorials for parallel decomposition, in my opinion at least (maybe an Allrun script for parallel? Shouldn't be that hard to make!) Also, for the restarting issue, I found that the problem lies with the backward d2dt2 scheme for the solid, when the solver can't find the old cell volume file for the solid, it should automatically switch to an Euler scheme (normally) but it doesn't. I haven't messed with the code to fix this, but I found a simple solution to bypass this. You simply need to delete the uniform folder, along with all the "old" values files (like D_0, D_0_0, V0 for the fluid mesh, U_0 and so on) for the time you want to restart from along with using an Euler d2dt2 scheme for the solid mesh and you should be fine restarting your case. Now for a new issue I haven't seen addressed by anyone else yet. I have been trying to use the updated Lagrangian stress model for my simulation since I am working on an HPC model and resources are not really an issue (while simulation time is). I take it that the unsIncrTotalLagrangian stress model implemented along with the solver is the equivalent to an updated Lagrangian stress model from the old icoFsi...SolidFoam solver from the solid Mechanics branch of foam-extend-3.1. I seem to get a segmentation fault as soon as I reach the point in the simulation that the stress modelling happens and I haven't been able to figure out why this happens when I use the unsIncrTotalLagrangian model, while the simple unsTotalLagrangian works just fine. Also I tried using similar settings with my simulation in one of the tutorial cases (the 3dTube) and the unsIncrTotalLagrangian stress model and it seems to run perfectly. I have also enable the built-in debug flag in the stressProperties file, it doesn't print anything out so I guess it doesn't get very far before it crashes. Here is the log file from before my case crashes: Code:
Create timeBest regards, Vasilis |
Seeking literature for large strain solid dynamics in OpenFOAM
Dear All,
I am currently in the process of publishing my research on large strain solid dynamics implemented in OpenFOAM. The method we employ (visit my website for more details) is based on a mixed formulation which eliminates the shortcomings posed by the conventional displacement based formulations. As part of the literature review, I am looking for literature (journal publications only) that anyone of you has published regarding large strain solid dynamics in OpenFOAM. After a quick search, I only found one article detailed as follows: @Article{cardiff2014, Title = {A large strain finite volume method for orthotropic bodies with general material orientations}, Author = {Cardiff, Philip and Kara{\v{c}}, A and Ivankovi{\'c}, A}, Journal = {Computer Methods in Applied Mechanics and Engineering}, Year = {2014}, Pages = {318--335}, Volume = {268}, Publisher = {Elsevier}, } I would be pleased to know if there are more articles already published or in the process of publication on this topic. Thanks. |
Quote:
I had a look at the presentation on your website, your approach looks very interesting. I would be very interested in seeing more details on your discretisation and solution methodology. By "mixed", do you mean that your primary variables are displacement/velocity and pressure? As regards publication of large strain solid dynamics in OpenFOAM, I am not aware of another journal paper but there are a few conference papers, such as:
Best regards, Philip |
| All times are GMT -4. The time now is 06:21. |