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

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 scalarTransportFoam-Solver at statdyState. I specified a couple of time iterations.

Cheers!

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

What difference do you get? I get a curve which looks like an exponential growing curve.

See attached
Take note that T is phi in this case.

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!

Hi, this problem was discussed in extenso (http://www.cfd-online.com/Forums/ope...ssembling.html) 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.

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.

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.

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.

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.

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

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.

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.