
[Sponsors] 
May 25, 2012, 07:35 
OpenFOAM2.1 instability problems?

#1 
New Member
Ali Q Raeini
Join Date: Feb 2010
Posts: 24
Rep Power: 9 
I had some problems with using OpenFOAM2.1, and I was wondering if anybody else had similar problems, or if they have worked on finding the solution.
I have noticed when I run my two phase simulations using OpenFOAM2.1 they are more prone to instability, specially when run in parallel. When using the OpenFOAM1.6extend, however, my simulation are more stable, The instabilities occur after some time from the beginning of the simulation and appear in terms of some nonphysical velocities slowly increasing and finally destroying the simulation results. When I run my code in serial if I just use smaller timesteps then the simulations are less likely to diverge. I haven't seen these instabilities when using OF1.6ext. So my first question is what has made the OF1.6ext more stable. It should be some improvements in discretization algorithms, but it would be great if we know more exactly what are these improvements. There is another problem which is more an issue for me. It happens when using OF2.1 in parallel, where I have seen instabilities mainly occurring in the processor boundaries. This time the problem can be due to a looser coupling of the linear equation solvers (I use GAMG most of the times), or maybe improper handling of the boundary conditions. I don't have this problem when using OF1.6ext, with identical algorithm, so this is not a problem with my code. My simulations are twophase flow at low capillary numbers, and these instabilities happen when capillary forces are active on the processor boundaries. At this time, I use OF2.1 for preprocessing and post processing, while OF1.6ext for running my simulations. So it is not that bad, but it would be better if I could figure out what is the problem. Is there anybody else having similar problems? 

May 25, 2012, 07:55 

#2 
Senior Member
Olivier
Join Date: Jun 2009
Location: France, grenoble
Posts: 265
Rep Power: 11 
hello,
If i remember correctely, Co calculation has changed with the 2.0/2.1 version, so this may be a starting point to investigate : try with lower time step and compare with 1.6ext . regards, olivier 

May 25, 2012, 16:42 

#3 
Super Moderator
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,036
Blog Entries: 39
Rep Power: 110 
Greetings to both of you!
I knew I had seen reports about this sometime ago in OpenFOAM.org bug tracker and here they are:
Bruno
__________________


May 26, 2012, 15:07 

#4 
Senior Member
Alberto Passalacqua
Join Date: Mar 2009
Location: Ames, Iowa, United States
Posts: 1,911
Rep Power: 28 
What solver(s) is showing this problem? InterFoam?
__________________
Alberto Passalacqua GeekoCFD  A free distribution based on openSUSE 64 bit with CFD tools, including OpenFOAM. Available as in both physical and virtual formats (current status: http://albertopassalacqua.com/?p=1541) OpenQBMM  An opensource implementation of quadraturebased moment methods. To obtain more accurate answers, please specify the version of OpenFOAM you are using. 

May 26, 2012, 16:38 

#5 
New Member
Ali Q Raeini
Join Date: Feb 2010
Posts: 24
Rep Power: 9 
Dear Alberto, Bruno and Olivier
Thanks for your help. The modification on Courant number calculation can explain my problem, or part of it at least. I didn't know about it and were using the same maxCo for both OF1.6 and the OF2.1. Nevertheless, I have put an additional constraint on time step size myself, so I need to check to see whether fixing this solves the problem. The code is something based on the interFoam code, but heavily modified. I will test this out further and post back. Thanks again, Ali 

September 24, 2012, 13:23 
update

#6 
New Member
Ali Q Raeini
Join Date: Feb 2010
Posts: 24
Rep Power: 9 
Just to confirm that this problem is NOT due to the timestep size. I have to mention that this happens for parallel cases; the difference is not that significant for the singleCPU simulations. I suspect it is due to the linear eqn solver (the computed pressure is different from the beginning of the simulation), or I may have done something with the boundary conditions which is not consistent with the new version. Anyway, I rather stick to the old OF for now; I might spend more time on this if I have got the time.
Last edited by aliqasemi; September 24, 2012 at 14:09. 

May 17, 2016, 10:46 

#7 
New Member
Join Date: Feb 2016
Posts: 1
Rep Power: 0 
Dear all,
I am experiencing similar problem with my solver (laminar melting with buoyant forces), it works in serial and crashes at some point in parallel. I tried modifying linear solvers, but without much success. Have you solved the problem? Do you have any suggestions? Thanks 

January 16, 2017, 05:51 

#8 
New Member
Join Date: Feb 2014
Posts: 20
Rep Power: 5 
Dear all,
I have exactly the same problem. Using fixed time steps in a boussinesq solver the solution explodes when used in parallel and not in single processor 

January 16, 2017, 06:25 
More details

#9 
New Member
Join Date: Feb 2014
Posts: 20
Rep Power: 5 
Just to give more details:
I use my own solver based on the buoyant boussinesq solver. The simulation runs for a while with adaptable time step. The average time step is approximately 0.23. At ~50 the parallel solver breaks. I reconstruct and run in single and it passes. Then I decompose and run imn parallel and it runs for a while before it breaks. When the simulation breaks I also tried using small fixed time steps (1e3), but to no avail. I use a hierarchical decomposition into 32 processors. 

February 15, 2017, 07:39 
Pressure Diverges

#10 
New Member
Arash Rouzi
Join Date: Feb 2017
Posts: 2
Rep Power: 0 
Hello dear users,
I'v got stock within the problem that the pressure solver diverges with the following error. This is naca airfoil low reynolds simulation using pimpleFoam. I would be eager if anybody can help me with this problem. a timestep 1E8 results in the same problem. Bests, Error:  Courant Number mean: 5.23271e+031 max: 6.07791e+036 Time = 8e008 PIMPLE: iteration 1 smoothSolver: Solving for Ux, Initial residual = nan, Final residual = nan, No Iterations 1000 smoothSolver: Solving for Uy, Initial residual = nan, Final residual = nan, No Iterations 1000 GAMG: Solving for p, Initial residual = nan, Final residual = nan, No Iterations 1000 GAMG: Solving for p, Initial residual = nan, Final residual = nan, No Iterations 1000 > FOAM FATAL IO ERROR: wrong token type  expected Scalar, found on line 0 the word 'nan' file: C:/OpenFOAM/16.10/ACER3.0.x/run/NACA2415finegrid/system/data.solverPerformance.p at line 0. From function operator>>(Istream&, Scalar&) in file lnInclude/Scalar.C at line 93. FOAM exiting Mesh:  Mesh stats points: 69172 internal points: 0 faces: 136901 internal faces: 67729 cells: 34105 faces per cell: 6 boundary patches: 4 point zones: 0 face zones: 0 cell zones: 0 Overall number of cells of each type: hexahedra: 34105 prisms: 0 wedges: 0 pyramids: 0 tet wedges: 0 tetrahedra: 0 polyhedra: 0 Checking topology... Boundary definition OK. Cell to face addressing OK. Point usage OK. Upper triangular ordering OK. Face vertices OK. Number of regions: 1 (OK). Checking patch topology for multiply connected surfaces... Patch Faces Points Surface topology VELOCITY_INLET 433 868 ok (nonclosed singly connected) PRESSURE_FARFIELD 195 392 ok (nonclosed singly connected) AIRFOIL_WALL 334 668 ok (nonclosed singly connected) frontAndBackPlanes 68210 69172 ok (nonclosed singly connected) Checking geometry... Overall domain bounding box (1.39977 1.5 0.046096) (2.1 1.5 0.046096) Mesh has 2 geometric (nonempty/wedge) directions (1 1 0) Mesh has 2 solution (nonempty) directions (1 1 0) All edges aligned with or perpendicular to nonempty directions. Boundary openness (3.35274e017 2.62186e018 1.42503e019) OK. Max cell openness = 1.59929e013 OK. Max aspect ratio = 218.673 OK. Minimum face area = 5.05592e011. Maximum face area = 0.0183235. Face area magnitudes OK. Min volume = 4.66115e012. Max volume = 0.0014232. Total volume = 0.878736. Cell volumes OK. Mesh nonorthogonality Max: 89.8884 average: 11.482 *Number of severely nonorthogonal (> 70 degrees) faces: 423. Nonorthogonality check OK. <<Writing 423 nonorthogonal faces to set nonOrthoFaces Face pyramids OK. Max skewness = 0.637561 OK. Coupled point location match (average 0) OK. Mesh OK. End 

Thread Tools  
Display Modes  


Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
Can openfoam solve problems in cylindrical and spherical coordinate systems?  GGerber  OpenFOAM Running, Solving & CFD  6  February 5, 2015 11:37 
New OpenFOAM Forum Structure  jola  OpenFOAM  2  October 19, 2011 06:55 
64bitrhel5 OF installation instructions  mirko  OpenFOAM Installation  2  August 12, 2008 18:07 
OpenFOAM installation on SUSE92 problems  derath  OpenFOAM Installation  1  April 3, 2006 06:44 
Problems of numerical instability because of high gradients  Xiangyang Ye  Main CFD Forum  4  September 28, 1998 03:48 