
[Sponsors] 
upwind schema strange results; Solution of Versteeg example differs from OpenFOAM sol 

LinkBack  Thread Tools  Display Modes 
May 9, 2011, 05:26 
upwind schema strange results; Solution of Versteeg example differs from OpenFOAM sol

#1 
Senior Member
Claus Meister
Join Date: Aug 2009
Location: Wiesbaden, Germany
Posts: 241
Rep Power: 10 
Hello Foamers,
I have a problem concerning the upwind scheme; there is something wrong. I recreated the example 5.1 case 2 in Versteeg; for the "Gauss linear" scheme I obtained the values exactly as in the book. However, the switch to upwind didn't give the curve as in the book. Has anybody ever done the same example and got similar results? To do this, I used the scalarTransportFoamSolver at statdyState. I specified a couple of time iterations. Cheers! 

May 9, 2011, 09:28 

#2 
Member
Logan Page
Join Date: Sep 2010
Posts: 38
Rep Power: 8 
Hi
I played around with this example and for case i and iii i get the same results for both the upwind and central differencing schemes which correspond to the text book. Only in case ii is there a difference in the results between the two discretization schemes (upwind was less deviation from the exact solution than central). Regards 

May 9, 2011, 12:04 

#3 
Senior Member
Claus Meister
Join Date: Aug 2009
Location: Wiesbaden, Germany
Posts: 241
Rep Power: 10 
What difference do you get? I get a curve which looks like an exponential growing curve.


May 9, 2011, 12:23 

#4 
Member
Logan Page
Join Date: Sep 2010
Posts: 38
Rep Power: 8 
See attached
Take note that T is phi in this case. 

May 9, 2011, 13:41 

#5 
Senior Member
Claus Meister
Join Date: Aug 2009
Location: Wiesbaden, Germany
Posts: 241
Rep Power: 10 
Okay! I have to corrected my graph; I use sample and R to visualize data so I had to extent about the initial condition points. Now you can see either graphs are identically. So, from my point of view, there is something wrong. I trying to report the error!


May 9, 2011, 15:20 

#6 
Senior Member
Santiago Marquez Damian
Join Date: Aug 2009
Location: Santa Fe, Santa Fe, Argentina
Posts: 430
Rep Power: 16 
Hi, this problem was discussed in extenso (Wrong fvm::div assembling) few months ago because I had the same question and posted it in the bug tracker and forum. Conclusion was upwind BC in FOAM is assembled in a different way respect Versteeg book. FOAM version in less diffusive in general (because is pseudo central difference) but it is unbounded for Pe>1, just the opposite in case of Versteeg formulation. So that, the guys involved in the thread could't say which is "the best" of both schemes (I personally prefer the Versteeg option).
Finally if you want to obtain Versteeg book results you have to code your own upwind or fixedValue BC. Regards.
__________________
Santiago MÁRQUEZ DAMIÁN, Ph.D. Research Scientist Research Center for Computational Methods (CIMEC)  CONICET/UNL Tel: 543424511594 Int. 7032 Colectora Ruta Nac. 168 / Paraje El Pozo (3000) Santa Fe  Argentina. http://www.cimec.org.ar 

May 9, 2011, 17:10 

#7  
Senior Member
Arjun
Join Date: Mar 2009
Location: Nurenberg, Germany
Posts: 490
Rep Power: 13 
Quote:
Thanks for that link to discussion. I myself brooded over it and never got to a definitive decision. The issue is that in my code (inavier.com) , i use proper upwind at the inlets and outlets too. But starccm+ manual mentions about using the value specified at the inlet and outlets, just like the openfoam does as per that thread. Very recently i have tried the approach starccm+ and foam are doing. Anyway it seems using proper upwind is better idea. 

May 9, 2011, 19:13 

#8 
Senior Member
Santiago Marquez Damian
Join Date: Aug 2009
Location: Santa Fe, Santa Fe, Argentina
Posts: 430
Rep Power: 16 
Arjun, thanks for sharing your experiencie as a developer, congrats for your code! I think that much of this discussion relies on who is the boss in the cells near a boudary: the face value or the scheme.
Regards.
__________________
Santiago MÁRQUEZ DAMIÁN, Ph.D. Research Scientist Research Center for Computational Methods (CIMEC)  CONICET/UNL Tel: 543424511594 Int. 7032 Colectora Ruta Nac. 168 / Paraje El Pozo (3000) Santa Fe  Argentina. http://www.cimec.org.ar 

May 9, 2011, 19:31 

#9  
Senior Member
Arjun
Join Date: Mar 2009
Location: Nurenberg, Germany
Posts: 490
Rep Power: 13 
Quote:
i now read through that thread and i understood the problem is that  if a pure advection scheme is used and if someone has to apply fix value at the outlet then the value might get ignored. (I think this is what is Henri's comment). My thinking is, if he made this comment then he is partially correct. Why? Because this happens only when you use first order scheme. In the second order scheme though you have contribution due to gradients and the way gradients are calculated face value does affect it. So if you are using second order scheme you are safe even if you use fixed value outlet and upwind scheme. You can try that. 

May 9, 2011, 19:51 

#10 
Senior Member
Arjun
Join Date: Mar 2009
Location: Nurenberg, Germany
Posts: 490
Rep Power: 13 
5 minutes of thinking and this is my cure to that problem.
Lets say p is CV center and b is boundary face. phi_p or phi_b if using upwind scheme you get one value out of these two , if solver chose phi_b things work, if solver chose phi_p then we might be in trouble. Here is the cure, irrespective of what user chooses (1st order or 2nd order), face values shall be constructed in second order manner. So we have dPhidR = (phi_b  phi_p) / r phi_face = phi_p + r * dPhidR if p was chosen because of upwind scheme phi_face = phi_b if b was chosen by upwind scheme. Now initially even if phi_p is 0, dPhidR is not and thus boundary value affects the solution path. This scheme is consitent with upwind way and also converge to correct face value upon convergence. 

May 10, 2011, 04:15 

#11 
Senior Member
Claus Meister
Join Date: Aug 2009
Location: Wiesbaden, Germany
Posts: 241
Rep Power: 10 
Thanks santiagomarquezd for you reply!
I must admit that I haven't yet fully understood the problem; I must let it cross my mind several times. Another question: Can I set the BCs in such a way, that the result is equal to the book, i.e. when the upwind scheme in OF is different, how do I have to adjust the BC to get the curve in Versteeg? Cheers in advance 

May 10, 2011, 04:29 

#12  
Senior Member
Arjun
Join Date: Mar 2009
Location: Nurenberg, Germany
Posts: 490
Rep Power: 13 
Quote:
I can explain that to you (as per my understanding): First think that there are two cells  1. cell center and 2. boundary cell. At the boundary you have flux, this could be ve (flow coming in) or +ve flow going out. so far so good, now think how upwind scheme works. This is upwinding: If flux is ve then value of variable at face is same as face value. if flux is +ve then value of variable at face is same as of cell center value. Now consider this situation  you start with 0 initial guess. That means value at cell center is 0. Further you know that at the outlet flux is +ve , that is value at boundary by upwinding is of cell center. Which is 0!. so in this case no matter what value you specified at boundary , that will be ignored. so what can you do?? Well you can force the boundary always value to be of face , which is what is done in openfoam etc. But if you do this, now your scheme is no longer upwind and thus prone to stability issues. I hope this clears the problem. 

May 10, 2011, 05:38 

#13 
Senior Member
Claus Meister
Join Date: Aug 2009
Location: Wiesbaden, Germany
Posts: 241
Rep Power: 10 
Okay, I think I have understood! The implementation of upwind in OpenFOAM occurred to me as the attempt to be independent from flow direction.
So when I wanna build my own upwind: what do i do? I had a look into upwind.H, but i couldn't recognize anything. Can anybody gimme an advise. 

Thread Tools  
Display Modes  


Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
Why results differs between upwind and vanLeerV  kjetil  OpenFOAM Running, Solving & CFD  1  November 10, 2012 05:55 
OpenFOAM  Validation of Results  Ahmed  OpenFOAM Running, Solving & CFD  9  June 22, 2011 18:59 
OpenFOAM 1.6 and 1.7 with interFoam, groovyBC give different strange results  Arnoldinho  OpenFOAM  7  December 9, 2010 17:29 
Velocity spots in openFoam results  Valle  OpenFOAM Running, Solving & CFD  4  August 19, 2009 05:53 
Strange results from interFoam solution converges but sum of all forces not equal to zero  nicasch  OpenFOAM Running, Solving & CFD  0  April 15, 2008 02:01 