CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM > OpenFOAM Running, Solving & CFD

simpleFoam: switch so second order fvSchemes

Register Blogs Members List Search Today's Posts Mark Forums Read

Like Tree4Likes
  • 3 Post By roby
  • 1 Post By roby

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   June 7, 2012, 10:46
Default simpleFoam: switch so second order fvSchemes
  #1
New Member
 
Join Date: Oct 2011
Posts: 19
Rep Power: 14
okroud is on a distinguished road
Hi all,

I've been working on my case in openfoam 1.7.x for some weeks now, but since the results aren't satisfying (I'm comparing it to fluent Data) I'd like to switch to second order divSchemes.
Sadly, despite several tries, I am unable to get a well converging Solution.

These are my original fvSchemes which are converging well:

ddtSchemes
{
default steadyState;
}

gradSchemes
{
default leastSquares;
}

divSchemes
{
default none;
div((nuEff*dev(grad(U).T()))) Gauss linear upwind;
div(phi,U) Gauss upwind;
div(phi,omega) Gauss upwind;
div(phi,k) Gauss upwind;
}
laplacianSchemes
{
default Gauss linear corrected;
}

interpolationSchemes
{
default linear;
}

snGradSchemes
{
default linear;
}
fluxRequired
{
default no;
p ;
}

Now i only changed the divSchemes, nothing else. These are the Residuals and their gradSchemes:



First try: Ux, Uy, Uz don't realy converge.

divSchemes
{
default none;
div((nuEff*dev(grad(U).T()))) Gauss linear upwind;
div(phi,U) Gauss linear;
div(phi,omega) Gauss linear;
div(phi,k) Gauss linear;
}





Second try: Here the Calculation exits with an Error.

divSchemes
{
default none;
div((nuEff*dev(grad(U).T()))) Gauss linear upwind;
div(phi,U) Gauss QUICKV leastSquares;
div(phi,omega) Gauss QUICK leastSquares;
div(phi,k) Gauss QUICK leastSquares;
}











Third try: Here the Residuals are relatively high and by using foamToTecplot360 there appears to be a floatingpoint Error. (I guess this means the Results are bad?)

divSchemes
{
default none;
div((nuEff*dev(grad(U).T()))) Gauss linear upwind;
div(phi,U) Gauss linearUpwindV leastSquares;
div(phi,omega) Gauss linearUpwind leastSquares;
div(phi,k) Gauss linearUpwind leastSquares;
}


It would be really helpful if someone could give me a hint how to use second order schemes. I would post back the results if you are interested.
If you have any questions please ask!


Greetings and thanks for answers!


okroud
okroud is offline   Reply With Quote

Old   June 8, 2012, 05:04
Default
  #2
Member
 
fisch
Join Date: Feb 2010
Posts: 97
Rep Power: 16
fisch is on a distinguished road
Hi,

Maybe i don't get your question right, but in steady state calculations you will not see the error reduction by the order of accuracy of your schemes (because you're doing only more iterations and not refinement).
Independent if it is first or second order.
fisch is offline   Reply With Quote

Old   June 8, 2012, 13:43
Default
  #3
New Member
 
roberto putzu
Join Date: Mar 2012
Posts: 9
Rep Power: 14
roby is on a distinguished road
I quite agree with fisch, but still how can you pass the schemes to a second order?

kind regards
roby is offline   Reply With Quote

Old   June 10, 2012, 05:21
Default
  #4
New Member
 
Join Date: Oct 2011
Posts: 19
Rep Power: 14
okroud is on a distinguished road
Quote:
Originally Posted by fisch View Post
Hi,

Maybe i don't get your question right, but in steady state calculations you will not see the error reduction by the order of accuracy of your schemes (because you're doing only more iterations and not refinement).
Independent if it is first or second order.
Thank you very much! Although it wasn't my primary question this is very interesting because it would even spare me to experiment with second order schemes. It would be nice if you could tell me why it doesn't matter at all in a steady state solution. Certainly derivations in time distinguish in a steady state solution. But since the divergence operator contains derivations in space, I thought that second order schemes would improve the accuracy. Why don't they?

PS: If anyone has any answer about the convergence problem it would still be interesting to know more about why my new gradSchemes don't work.
okroud is offline   Reply With Quote

Old   June 11, 2012, 03:12
Default
  #5
Member
 
fisch
Join Date: Feb 2010
Posts: 97
Rep Power: 16
fisch is on a distinguished road
Hi,

in steadystate calculations the order of the used schemes are important, too.
But you won't see this 2nd order behavior in the graphs you are plotting. If you want to see it you have to compare calculations on different refined meshes...

For your problem with the gradScheme: Try the Gauss linear scheme.
fisch is offline   Reply With Quote

Old   June 11, 2012, 10:04
Default
  #6
New Member
 
Join Date: Oct 2011
Posts: 19
Rep Power: 14
okroud is on a distinguished road
Okay thanks, I'll try Gauss linear now.

I know that I won't see the different results in the convergence, I'm just trying to get a well converging calculation. Before i don't get any, i think it wouldn't make sense to compare the calculations (first/second order on the same Mesh) in detail.

I'm a bit confused by your statement about the second order schemes. First you say it is independent if it is first/second order. Then you say I might see differences on refined meshes. Do you mean differences in convergence or the result?

Would you agree, that if I'll be able to configure a converging second order calculation (as I tried), there could be some improvement/differences in the Solution of the field variables compared to a first order calculation on the same Mesh?

Thanks for taking your time!

okroud
okroud is offline   Reply With Quote

Old   June 11, 2012, 14:19
Default
  #7
New Member
 
roberto putzu
Join Date: Mar 2012
Posts: 9
Rep Power: 14
roby is on a distinguished road
Hi,

The effect of using a first or a second order scheme is not visible from the residuals (your plots). Nevertheless, the results change.

Forgive me for making it very simple:
In first order schemes you only use two cells in order to determine a derivative. In second order schemes, you use three cells.
Therefore, usually second order schemes are more accurately predicting gradients than first order schemes ("better" solution). Let us say that in steady state you just "converge to a less accurate solution" and you cannot see it from the residuals.

Just pay attention to one thing: in physics nothing is given for free: you pay the bigger accuracy with lower stability. Higher order schemes are usually more unstable than lower order schemes and are more likely to diverge

kind regards
fisch, arvindpj and ArturM like this.
roby is offline   Reply With Quote

Old   June 13, 2012, 10:44
Default
  #8
New Member
 
Join Date: Oct 2011
Posts: 19
Rep Power: 14
okroud is on a distinguished road
Thanks rob, for this good overview.

And fish
Quote:
Originally Posted by fisch View Post
Hi,
For your problem with the gradScheme: Try the Gauss linear scheme.
You mean the divScheme Gauss linear? I already tried it, you can see the result in my first Post.
okroud is offline   Reply With Quote

Old   November 12, 2012, 08:04
Default convergence Problem
  #9
Senior Member
 
Sören
Join Date: Mar 2012
Posts: 102
Rep Power: 14
despaired student is on a distinguished road
Hi,

how did you make the grid? Did you use a mesh-generator like ICEM or gambit? From my limited experience I can think of two problems that lead to such a convergence behavior.

1. There is somewhere the flux completely blocked. E.g. if you accidently created a wall behind the Inlet and now the stream can't go through.
--> Check your Grid for this.

2. You might have some translation errors from your Grid generator or declared a part wrong in constant-> PolyMesh-> boundary
E.g. a wall-part is in the boundary field declared as type "patch" and not as type "wall".
--> Check your boundary file.


Kind regards
despaired student is offline   Reply With Quote

Old   September 6, 2013, 14:48
Default First/secord order scheme steady state
  #10
New Member
 
Juan Pablo Toro Labbe
Join Date: Jun 2013
Location: Davis CA
Posts: 7
Rep Power: 12
jptorol is on a distinguished road
From my understanding (please correct me if I am wrong), when you use a first order numerical scheme, you may have a converged solution because you are basically incorporating numerical diffusion. Thus, your "solution" may not be true even though it looks nice. On the other hand, if you try a second order numerical scheme (for example div(phi,U) bounded Gauss linear) and you don't get a converged solution, that means that probably your flow has strong unsteadiness (for example, separation vortex). So what to do in that case?
jptorol is offline   Reply With Quote

Old   September 6, 2013, 20:20
Default
  #11
New Member
 
Join Date: Oct 2011
Posts: 19
Rep Power: 14
okroud is on a distinguished road
In my case it finally worked with SFCD Schemes. In my understanding this is a blending between first and second order schemes. So i guess these schemes might be a good choice if you're not sure about how complex or unsteady your flow is. And you were right, there actually was a separation at the end of the turbine blade.
Although I'm not sure if this was the reason for the poor convergence, since it didn't even converge at the beginning, and I don't think that the separation developed that early.
okroud is offline   Reply With Quote

Old   September 11, 2013, 13:52
Default
  #12
New Member
 
roberto putzu
Join Date: Mar 2012
Posts: 9
Rep Power: 14
roby is on a distinguished road
Yes. A first order can be demonstrated to be equivalent to a second order to which you add a numerical viscosity, which stabilizes it but "smoothens" sharp gradients. In case your second order does not converge you can do several things:

-First of all make sure you have a good grid (better quality = less troubles). Avoid as much as possible non conformal grids and, if you can, use hexahedral meshses. plot an iso-surface of the the diverging value. look where it diverges. If you see a bad elements in that point or a non conformal surface, this is probably the problem.
-start with a first order. You stabilize a bit the solution and then you run a second order. Some codes (e.g. CFD++. So I guess SFCD schemes) incorporate a blending function passing from one to another scheme during the solution.
-In case you have troubles to converge one equation (turbulence, energy equation) start turning it off. After a little convergence put it in again.
-in case you are still not able to converge, in an unsteady case you can reduce the Delta t. But you increase the solving time
-in case of steady cases, you can under-relax your solver. It also increases your solving time.
Other stabilisation techniques exist but the most times are not necessary.

Roby
wc34071209 likes this.
roby is offline   Reply With Quote

Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
2nd order upwind vs 2nd order upwind!!! Far Main CFD Forum 7 March 14, 2013 13:29
First order simulation better than second order Torque_Converter CFX 7 January 8, 2013 05:07
Trying to run a benchmark case with simpleFoam spsb OpenFOAM 3 February 24, 2012 10:07
Unstable flow simpleFoam 2nd order Valle OpenFOAM 0 August 26, 2009 09:12
2nd Order Scheme for SimpleFoam bastil OpenFOAM Running, Solving & CFD 0 February 22, 2009 17:20


All times are GMT -4. The time now is 05:22.