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

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

 December 24, 2011, 12:21 Accuracy problem of HO schemes on unstructured mesh, HO scheme gives 1st order result #1 Member   Join Date: Mar 2009 Location: Istanbul, Turkiye Posts: 47 Rep Power: 17 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.

 December 24, 2011, 13:36 #2 Senior Member   cfdnewbie Join Date: Mar 2010 Posts: 557 Rep Power: 20 Hi gemini, did you test the convergence of your formulation beforehand? Does it give second order for a convergence test? Cheers

December 24, 2011, 15:21
#3
Member

Join Date: Mar 2009
Location: Istanbul, Turkiye
Posts: 47
Rep Power: 17
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 Hi gemini, did you test the convergence of your formulation beforehand? Does it give second order for a convergence test? Cheers

 December 24, 2011, 15:31 #4 Senior Member   cfdnewbie Join Date: Mar 2010 Posts: 557 Rep Power: 20 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

December 24, 2011, 17:47
#5
Senior Member

Arjun
Join Date: Mar 2009
Location: Nurenberg, Germany
Posts: 1,278
Rep Power: 34
Quote:
 Originally Posted by gemini 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.

December 24, 2011, 18:14
#6
Senior Member

cfdnewbie
Join Date: Mar 2010
Posts: 557
Rep Power: 20
Quote:
 Originally Posted by arjun 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!

December 24, 2011, 18:25
#7
Senior Member

Arjun
Join Date: Mar 2009
Location: Nurenberg, Germany
Posts: 1,278
Rep Power: 34
Quote:
 Originally Posted by cfdnewbie 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.

 December 24, 2011, 18:34 #8 Senior Member   cfdnewbie Join Date: Mar 2010 Posts: 557 Rep Power: 20 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! Last edited by cfdnewbie; December 24, 2011 at 19:28. Reason: Better sense!

December 24, 2011, 20:01
#9
Senior Member

Arjun
Join Date: Mar 2009
Location: Nurenberg, Germany
Posts: 1,278
Rep Power: 34
Quote:
 Originally Posted by cfdnewbie 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.

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

December 24, 2011, 20:37
#10
Senior Member

cfdnewbie
Join Date: Mar 2010
Posts: 557
Rep Power: 20
Quote:
 Originally Posted by arjun 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!!

 December 25, 2011, 02:22 #11 Senior Member   duri Join Date: May 2010 Posts: 245 Rep Power: 17 Gemini, check you limiter implementation, I think it some how pushes to first order reconstruction at face.

December 26, 2011, 04:45
#12
Member

Join Date: Mar 2009
Location: Istanbul, Turkiye
Posts: 47
Rep Power: 17
Quote:
 Originally Posted by arjun 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

Last edited by gemini; December 26, 2011 at 06:28. Reason: problem solved.

December 27, 2011, 21:01
#13
Senior Member

Arjun
Join Date: Mar 2009
Location: Nurenberg, Germany
Posts: 1,278
Rep Power: 34
Quote:
 Originally Posted by gemini 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.