CFD Online Discussion Forums

CFD Online Discussion Forums (http://www.cfd-online.com/Forums/)
-   Main CFD Forum (http://www.cfd-online.com/Forums/main/)
-   -   Accuracy problem of HO schemes on unstructured mesh, HO scheme gives 1st order result (http://www.cfd-online.com/Forums/main/95606-accuracy-problem-ho-schemes-unstructured-mesh-ho-scheme-gives-1st-order-result.html)

gemini December 24, 2011 13:21

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.

cfdnewbie December 24, 2011 14:36

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

Cheers

gemini December 24, 2011 16:21

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.

Quote:

Originally Posted by cfdnewbie (Post 336932)
Hi gemini,
did you test the convergence of your formulation beforehand? Does it give second order for a convergence test?

Cheers


cfdnewbie December 24, 2011 16:31

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

arjun December 24, 2011 18:47

Quote:

Originally Posted by gemini (Post 336929)
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.


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.

cfdnewbie December 24, 2011 19:14

Quote:

Originally Posted by arjun (Post 336945)
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.

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!

arjun December 24, 2011 19:25

Quote:

Originally Posted by cfdnewbie (Post 336948)
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.

cfdnewbie December 24, 2011 19:34

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!

arjun December 24, 2011 21:01

Quote:

Originally Posted by cfdnewbie (Post 336951)
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

cfdnewbie December 24, 2011 21:37

Quote:

Originally Posted by arjun (Post 336954)
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!!

duri December 25, 2011 03:22

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

gemini December 26, 2011 05:45

Quote:

Originally Posted by arjun (Post 336945)
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.

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

arjun December 27, 2011 22:01

Quote:

Originally Posted by gemini (Post 337028)
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.


All times are GMT -4. The time now is 12:26.