Accuracy problem of HO schemes on unstructured mesh, HO scheme gives 1st order result
 

Hi,

I am trying to develop an unstructured finite volume solver and it has problem with solution accuracy. Here the details;

- The test problem is standard lid driven cavity flow at Re = 1000.
- Colocated arrangement is used with MIM
- MESH is triangular and about 2000 cells
- The convective terms are discretized using 1st order upwind FOU or MUSCL scheme
- SIMPLE algorithm is used

The point I am stuck is that; when I select FOU scheme, my solver gives exactly the same result that is obtained from using a commercial solver using the same mesh. However, I cannot obtain the same agreement when I used MUSCL scheme.

The difference between my solver result and that of commercial is very big. Actually my solver give nearly the same result when FOU scheme is used. I tried several different HO formulations, ie. TVD , NVSF , GAMMA scheme, but my solution accuracy did not changed from first order.

Any help with this would be greatly appreciated.

Thanks in advance.

Hi gemini,
did you test the convergence of your formulation beforehand? Does it give second order for a convergence test?

Cheers

hi,
I could not get the point what you meant. could you give me more specific examples.

both FOU and HO SCHEME implementation of my code converges well and i did not observe any convergence difficulty.

on the other hand, is there any critical issues in FV discretization on unstructured meshes? I have used over-relaxed approach and MIM (majumdar formulation) in my code and as I point before the results with FOU scheme match closely with literature results.

Hello, I will try to make more clear what I meant.
If you write your own code, it is customary to test the code with an analytical example before starting to do "real" computations. For example, for linear scalar advection, you could use a simple transport to test your scheme. For Euler or Navier-Stokes, the transport of a density profile gives you a first clue if something is wrong.

The basic idea is to test your implementation with examples for which you know the solution, so you can be sure that your code itself is ok.

If you need more help, let me know!

read e.g.:
http://www.innovative-cfd.com/manufa...-overview.html
http://csm.mech.utah.edu/content/201...ation-testing/
http://www.personal.psu.edu/jhm/ME54...MS_summary.pdf

cheers

Your implementation may have some problem.

In all the higher order scheme implementation, a normalized variable at the face is calculated. Based on this variable it is decided that whether to use higher order scheme or just use first order upwind scheme.

In your case it seems the normalized variable at face that you calculate is such that always FOU is selected.

So check your implementation.

But wouldn't that totally depend on how/if he implemented it that way? I can implement a MUSCL with a decent Riemann solver without any switch to FOU, or am I misunderstanding your remark?

cheers!

Yes you can, but it does not say that everyone else is doing what you are doing.

So how come you assumed that he had such a switch implemented, and how come you stated that all codes had such a switch? Am I the one making assumptions and invalid generalizations here, or is it you, my friend? :))

Maybe we should stop this cat fight and try to help the guy asking his question! :))

Cheers!

I have already answered him and to him it will make sense. It is clear that you do not have much experience implementing the schemes he was talking about.

Spend some time with this page:

http://www.cfd-online.com/Wiki/Discr...onvection_term

Good, I'm looking very much forward to his response! I'm sure it will be very clear to him now! And thank you for the link, that was a true eye opener!!

Gemini, check you limiter implementation, I think it some how pushes to first order reconstruction at face.

Hi,

I found the mistake, it is indeed a simple mistake of implementation of flux direction check. flow direction check must be performed using face normal velocities (or simply normal mass flux) not V_x for x-momentum and V_y for y-momentum :)

Thanks to everybody

glad it worked out for you. Generally it is a silly mistake that creates problems.