
[Sponsors] 
November 4, 2010, 07:00 

#41 
Senior Member
Matthias Voß
Join Date: Mar 2009
Location: Berlin, Germany
Posts: 446
Rep Power: 11 
hi,
by backflow i mean a flapping of the flow somewhere, not just @ the inlet/outlet. if the flow is partial unsteady you won´t achieve a steady solution. regarding the residual check i must admit that i never did such a thing within OF... only knowing that from bigger commercial codes... but mainly it is storing the variable of the residual (for e.g. k, eps, and p,u,v,w) in a volume field (with NO_READ, AUTO_WRITE) for each iteration or at least for every 10th. or smth. similar. You would end up with a bunch of data when storing it every iteration. My idea would be :starting from an already found solution and calculate it for 2 periods of the oscillating residuals (e.g. 40 iterations). neewbie 

November 4, 2010, 09:32 

#42 
Senior Member
Vesselin Krastev
Join Date: Jan 2010
Location: University of Tor Vergata, Rome
Posts: 361
Rep Power: 10 
Mmmmh, still sounds a bit strange to me (for this case, and by my knowledge, it would be quite common to reach a steadystate solution using a standard RANS approach, whether if it is physically correct or not)...Maybe a more "immediate" check should be to run a transient case and see what happens, am I right? However, I'll try to investigate this matter further.
Apart from this, anyone that could tell me something about the setting of the case? Maybe Alberto? Thank you all V. 

November 7, 2010, 13:53 

#43 
Senior Member
Eugene de Villiers
Join Date: Mar 2009
Posts: 725
Rep Power: 12 
Not sure it will help, but putting zeroGradient boundaries on U on the side boundaries is a mistake. You will probably get inflow which will cause you all kinds of problems.
I suggest you set U to type slip on the top and side boundaries and set all other variables to the same as walls. Alternatively, you can just set the top and side boundaries to symmetry and get moreorless the same effect. 

November 9, 2010, 05:44 

#44  
Senior Member
Vesselin Krastev
Join Date: Jan 2010
Location: University of Tor Vergata, Rome
Posts: 361
Rep Power: 10 
Quote:
V. 

November 10, 2010, 10:28 

#45  
Senior Member
Vesselin Krastev
Join Date: Jan 2010
Location: University of Tor Vergata, Rome
Posts: 361
Rep Power: 10 
Quote:
Limiting both the general gradSchemes and the gradient option for the linearUpwindV scheme, a "kind of convergence" seems to be achieved. However, this convergence is reached only with the limited (in this case cellMDLimited) leastSquares choice (both for general gradSchemes and for the linearUpwindV <gradScheme>): using the limited Gauss linear option, the residuals keep to oscillate till the end of time... In addition, the "somewhat converging" runs gave a quite unphysical result for the nosedrag contribution of the body: in particular, after a few hundred of timesteps, the drag coefficient became negative (and I'm quite sure this is not a bug of the forceCoeffs function, because I've tested it before and it works properly) For more clarity, I'll post down below the settings, residuals patterns and Cdrag patterns for the two "best converging" runs: Run14 settings fvSchemes: ddtSchemes { default steadyState; } gradSchemes { default cellMDLimited leastSquares 1; // grad(p) leastSquares; // grad(U) leastSquares; } divSchemes { default none; div(phi,U) Gauss linearUpwindV cellMDLimited leastSquares 1; div(phi,k) Gauss upwind; div(phi,epsilon) Gauss upwind; div(R) Gauss linear; div((nuEff*dev(grad(U).T()))) Gauss linear; } laplacianSchemes { default Gauss linear limited 0.5; // laplacian(nuEff,U) Gauss linear corrected; // laplacian((1A(U)),p) Gauss linear corrected; // laplacian(DkEff,k) Gauss linear corrected; // laplacian(DepsilonEff,epsilon) Gauss linear corrected; } interpolationSchemes { default linear; interpolate(U) linear; } snGradSchemes { default limited 0.5; } fluxRequired { default no; p ; } // ************************************************** *********************** // fvSolution: // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // solvers { // p // { // solver PCG; // preconditioner DIC; // tolerance 1e11; // relTol 0.001; // } p { solver GAMG; tolerance 1e12; relTol 0.0001; smoother GaussSeidel; cacheAgglomeration true; nCellsInCoarsestLevel 1000; agglomerator faceAreaPair; mergeLevels 1; } U { solver PBiCG; preconditioner DILU; tolerance 1e10; relTol 0.1; } k { solver PBiCG; preconditioner DILU; tolerance 1e10; relTol 0.1; } epsilon { solver PBiCG; preconditioner DILU; tolerance 1e10; relTol 0.1; } } SIMPLE { nNonOrthogonalCorrectors 3; } relaxationFactors { p 0.3; U 0.7; k 0.7; epsilon 0.7; } // ************************************************** *********************** // 0/U: // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // dimensions [0 1 1 0 0 0 0]; internalField uniform (40 0 0); boundaryField { inlet { type fixedValue; value uniform (40 0 0); } outlet { type zeroGradient; } body { type fixedValue; value uniform (0 0 0); } nose { type fixedValue; value uniform (0 0 0); } slant { type fixedValue; value uniform (0 0 0); } back { type fixedValue; value uniform (0 0 0); } floor { type fixedValue; value uniform (0 0 0); } side { type slip; } top { type slip; } symmetry { type symmetryPlane; } } // ************************************************** *********************** // 0/p: dimensions [0 2 2 0 0 0 0]; internalField uniform 0; boundaryField { inlet { type zeroGradient; } outlet { type fixedValue; value uniform 0; } body { type zeroGradient; } nose { type zeroGradient; } slant { type zeroGradient; } back { type zeroGradient; } floor { type zeroGradient; } symmetry { type symmetryPlane; } side { type zeroGradient; } top { type zeroGradient; } } // ************************************************** *********************** // 0/k: // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // dimensions [0 2 2 0 0 0 0]; internalField uniform 0.0096; boundaryField { inlet { type fixedValue; value uniform 0.0096; } outlet { type zeroGradient; } body { type kqRWallFunction; value uniform 0.0096; } nose { type kqRWallFunction; value uniform 0.0096; } slant { type kqRWallFunction; value uniform 0.0096; } back { type kqRWallFunction; value uniform 0.0096; } floor { type kqRWallFunction; value uniform 0.0096; } side { type zeroGradient; } top { type zeroGradient; } symmetry { type symmetryPlane; } } // ************************************************** *********************** // 0/epsilon: // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // dimensions [0 2 3 0 0 0 0]; internalField uniform 0.155; boundaryField { inlet { type fixedValue; value uniform 0.00155; } outlet { type zeroGradient; } body { type epsilonWallFunction; value uniform 0.00155; } nose { type epsilonWallFunction; value uniform 0.00155; } slant { type epsilonWallFunction; value uniform 0.00155; } back { type epsilonWallFunction; value uniform 0.00155; } floor { type epsilonWallFunction; value uniform 0.00155; } side { type zeroGradient; } top { type zeroGradient; } symmetry { type symmetryPlane; } } // ************************************************** *********************** // 0/nut: // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // dimensions [0 2 1 0 0 0 0]; internalField uniform 0; boundaryField { inlet { type calculated; value uniform 0; } outlet { type calculated; value uniform 0; } body { type nutWallFunction; value uniform 0; } nose { type nutWallFunction; value uniform 0; } slant { type nutWallFunction; value uniform 0; } back { type nutWallFunction; value uniform 0; } floor { type nutWallFunction; value uniform 0; } side { type zeroGradient; value uniform 0; } top { type zeroGradient; value uniform 0; } symmetry { type symmetryPlane; } } // ************************************************** *********************** // checkMesh report: // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // Create time Create polyMesh for time = 0 Time = 0 Mesh stats points: 350035 faces: 3138087 internal faces: 3025804 cells: 1488208 boundary patches: 10 point zones: 0 face zones: 0 cell zones: 0 Overall number of cells of each type: hexahedra: 0 prisms: 211059 wedges: 0 pyramids: 0 tet wedges: 0 tetrahedra: 1277149 polyhedra: 0 Checking topology... Boundary definition 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 symmetry 22584 12567 ok (nonclosed singly connected) top 1814 994 ok (nonclosed singly connected) side 2602 1393 ok (nonclosed singly connected) outlet 372 213 ok (nonclosed singly connected) inlet 384 219 ok (nonclosed singly connected) floor 14174 7364 ok (nonclosed singly connected) nose 8710 4464 ok (nonclosed singly connected) body 54795 27714 ok (nonclosed singly connected) back 2882 1513 ok (nonclosed singly connected) slant 3966 2067 ok (nonclosed singly connected) Checking geometry... Overall domain bounding box (1.26 0 0.1945) (6.36 1.46 1.1945) Mesh (nonempty, nonwedge) directions (1 1 1) Mesh (nonempty) directions (1 1 1) Boundary openness (1.30596e19 3.09526e19 7.90637e19) OK. Max cell openness = 2.7631e16 OK. Max aspect ratio = 5.38151 OK. Minumum face area = 1.25535e06. Maximum face area = 0.0132756. Face area magnitudes OK. Min volume = 6.89797e10. Max volume = 0.000546044. Total volume = 11.0702. Cell volumes OK. Mesh nonorthogonality Max: 54.7518 average: 14.569 Nonorthogonality check OK. Face pyramids OK. Max skewness = 2.0193 OK. Mesh OK. Additional notes: OpenFOAM version: 1.6 turbulence model: realizableKE Run15 settings The same as Run14, but: with URF's for k and epsilon set to 0.6 instead of 0.7 with relTol parameters for U, k and epsilon lowered to 10e03 instead of 10e01 (and with the smooth solver option instead of thr DILUPBiCG solver one) Regards V. PSThe reddot horizontal pattern corresponds to the experimental nosedrag measured by Ahmed et al. (1984) 

November 15, 2010, 07:10 

#46 
Senior Member
Eugene de Villiers
Join Date: Mar 2009
Posts: 725
Rep Power: 12 
This
default cellMDLimited leastSquares 1; is too restrictive in my opinion. Especially since it is applied to the pressure gradient, which affects continuity. I have also heard that the leastSquares implementation in standard OPENFOAM has some problems. In any case, it is very odd that your result is almost exactly the experimental value times 1. I would check the forces FO and the flow in the vicinity of the object a few more times. 

November 15, 2010, 11:46 

#47  
Senior Member
Alberto Passalacqua
Join Date: Mar 2009
Location: Ames, Iowa, United States
Posts: 1,894
Rep Power: 26 
Quote:
It would be useful to have this reported as a bug report, if there is some way of showing it. P.S. With restrictive you mean the limiter should not be applied to grad(p)?
__________________
Alberto Passalacqua GeekoCFD  A free distribution based on openSUSE 64 bit with CFD tools, including OpenFOAM. Available as live DVD/USB, hard drive image and virtual image. OpenQBMM  An opensource implementation of quadraturebased moment methods Last edited by alberto; November 15, 2010 at 11:49. Reason: Added P.S. 

November 15, 2010, 12:40 

#48 
Senior Member
Eugene de Villiers
Join Date: Mar 2009
Posts: 725
Rep Power: 12 
Hi Alberto,
Check the dev version for the modified leastsquares implementation. I have not studied the issue in detail. For now it is just an unsubstantiated comment, as I can't remember the specifics. Correct, the limiter should not be applied to grad(p) if you can help it. (Sometimes it is better to get a less accurate result than no result at all.) 

November 16, 2010, 02:12 

#49 
Senior Member
Alberto Passalacqua
Join Date: Mar 2009
Location: Ames, Iowa, United States
Posts: 1,894
Rep Power: 26 
I have to look into that more carefully, however the leastsquares implementations for scalars identical (a minor difference in a constructor), but not for vectors, where the weighting factors are different (OpenCFD release uses a surfacebased weighting).
In this post Henry discussed the implementation: Face areas affect scheme switching criterion for leastSquares The two implementations of extendedLeastSquares seem consistent in both 1.7.x and 1.5dev (no surfacebased weights. There are a few other differences, unrelated). Best, 

November 16, 2010, 05:57 

#50 
Senior Member
Eugene de Villiers
Join Date: Mar 2009
Posts: 725
Rep Power: 12 
Hmm, I never noticed it. Thanks.


November 16, 2010, 11:26 

#51  
Senior Member
Vesselin Krastev
Join Date: Jan 2010
Location: University of Tor Vergata, Rome
Posts: 361
Rep Power: 10 
Quote:
Quote:
Quote:
For me, the problems ere that still I cannot find a way to get my runs working on with higher order divSchemes Quote:
Thank you V. 

December 1, 2010, 13:26 

#52  
Senior Member
Alberto Passalacqua
Join Date: Mar 2009
Location: Ames, Iowa, United States
Posts: 1,894
Rep Power: 26 
Quote:
Best, 

December 1, 2010, 13:32 

#53  
Senior Member
Alberto Passalacqua
Join Date: Mar 2009
Location: Ames, Iowa, United States
Posts: 1,894
Rep Power: 26 
Quote:
Quote:
For me, the problems ere that still I cannot find a way to get my runs working on with higher order divSchemes Quote:
Best, 

December 3, 2010, 08:25 

#54  
Senior Member
Matthias Voß
Join Date: Mar 2009
Location: Berlin, Germany
Posts: 446
Rep Power: 11 
hi,
thanks for the answer. Quote:
fakenumerically spoken > fvc:: means to calculate U from smth. known, in this case the momentum eq. with already known U´s. So if i fvc smth. i end up in the explicitly calculated value for each node from the iterated (fvm)solution. I understand that if i calculate smth. from a known rhs i end up with my "failure"(smth. like a residual) on the lhs. Is this correct so fare ? A residual is smth. like res=abs(U_newU_old)/abs(U_old) and all i have to do is to normalize the Ures values ? Sorry for the messy english. neewbie Last edited by mvoss; December 3, 2010 at 11:51. Reason: spelling 

December 3, 2010, 11:57 

#55 
Senior Member
Alberto Passalacqua
Join Date: Mar 2009
Location: Ames, Iowa, United States
Posts: 1,894
Rep Power: 26 
The uRes you compute with fvc is the "distance of UEqn from zero", meaning:
UEqn(U) = uRes where UEqn contains all its terms. Best, 

December 3, 2010, 12:01 

#56 
Senior Member
Matthias Voß
Join Date: Mar 2009
Location: Berlin, Germany
Posts: 446
Rep Power: 11 
hi,
by "distance" from zero you mean lhsrhs= distance ? I tried the approach above and got extremely high values in my uRes field, that´s why i was thinking about normalization. neewbie 

July 12, 2011, 09:56 

#57 
Member
The True
Join Date: Dec 2010
Posts: 80
Rep Power: 6 
I am using kepsilon model. I have set everything to second order scheme, unless the k and epsilon terms. When I make them also second order the simulation blows up.
Why can't k and epsilon be seconder order ? ( I am not sure if both can't be second order) 

July 12, 2011, 13:42 

#58 
Senior Member

They can, but since 2nd order produces numerical oscillations you can try to use underelaxation for k and epsilon to stabilize it.
__________________
Best regards, Dr. Alexander VAKHRUSHEV Christian Doppler Laboratory for "Advanced Process Simulation of Solidification and Melting" Simulation and Modelling of Metallurgical Processes Department of Metallurgy University of Leoben FranzJosefStr. 18 A  8700 Leoben Österreich / Austria Tel.: +43 3842  402  3125 http://smmp.unileoben.ac.at 

July 10, 2013, 06:55 

#59  
Senior Member
saeideh mohamadi
Join Date: Aug 2012
Posts: 229
Rep Power: 6 
Quote:
how we should calculate the "local (cell) Peclet number" ? thank you 

July 10, 2013, 07:33 

#60 
Senior Member
Anton Kidess
Join Date: May 2009
Location: Delft, Netherlands
Posts: 919
Rep Power: 17 
Use the "Pe" tool that comes with OF2.2.x (earlier versions were buggy).
__________________
*On twitter @akidTwit *Spend as much time formulating your questions as you expect people to spend on their answer. *Help define the OpenFOAM stackexchange Q&A site: http://area51.stackexchange.com/prop...oamtechnology 

Thread Tools  
Display Modes  


Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
4th order schemes in channelOodles  maka  OpenFOAM Bugs  9  January 19, 2009 12:58 
Help for fourth order accurate convective schemes  Z.C.Wang  Main CFD Forum  0  January 15, 2009 07:53 
2nd order conservative schemes  taw  Main CFD Forum  1  September 16, 2008 07:05 
CFL condition for higher order schemes  Shyam  Main CFD Forum  2  February 14, 2008 15:24 
High order compact finite difference schemes  Mikhail  Main CFD Forum  6  August 5, 2003 10:36 