accuracy of skew meshes?
Hello,
is it possible to get a 2nd order accuracy for a skew mesh in OpenFoam? My mesh looks like a parallelogram and the single cells look like parallelograms, too. All my results show (only) first order for p and U. Can anybody help me?:confused: Thanks a lot, rupert Here is my fvSchemes: gradSchemes { default none; grad(p) Gauss linear; grad(U) Gauss linear; snGradCorr(U) Gauss linear corrected; snGradCorr(p) Gauss linear corrected; } divSchemes { div(phi,U) Gauss vanLeerV; div((nuEff*dev(grad(U).T()))) Gauss linear; } laplacianSchemes { default none; laplacian(nuEff,U) Gauss linear corrected; laplacian((1A(U)),p) Gauss linear corrected; } interpolationSchemes { default none; interpolate(U) linear; } snGradSchemes { default none; } fluxRequired { default yes; p ; } // ************************************************** *********************** // 
Please post a case and the convergence study.

This is not so easy because the case works only with my solver and uses groovyBC.
I made graphs from my convergence studies. It's the discretization error development (in 2 and maxNorm for all variables) over mesh refinement (called factors). http://www.st.bv.tum.de/index.html?3...stpdfplot2.pdf The second picture shows the convergence rate which is round about 1. http://www.st.bv.tum.de/index.html?3...stpdfplot4.pdf If the mesh is not skew, it is round about 2... Do i something wrong? Is it in general possible to establish 2nd order of accuracy in Openfoam on nonorthogonal meshes? Jasak is writing in his thesis that it should be possible with the nonorthogonal correction... Is this the right setup in my fvSchemes or do i need something more in it? Thanks a lot. http://www.st.bv.tum.de/index.html?3...stpdfplot2.pdf http://www.st.bv.tum.de/index.html?3...stpdfplot2.pdfhttp://www.st.bv.tum.de/index.html?3...stpdfplot4.pdf 
As a first comment: you use vanLeer scheme (a bounded scheme). How often does the limiter kick in? You could easily estimate this by computing the local Peclet number (Pe = Dx*U/nu in the cell), and see where this is larger than 2.

thanks for the reply alberto,
the peclet number is in all directions smaller then 1. 
Other question: what is the skeweness of the mesh (checkMesh will tell you).
One suggestion is to perform the study on a simple case, like a cavity flow, and control the mesh there. 
Checking geometry...
Overall domain bounding box (0 0 0) (1.5 1 0.01) Mesh (nonempty, nonwedge) directions (1 1 0) Mesh (nonempty) directions (1 1 0) All edges aligned with or perpendicular to nonempty directions. Boundary openness (5.2090377e18 4.2269516e18 1.4260487e15) OK. Max cell openness = 1.2490009e16 OK. Max aspect ratio = 1.6250001 OK. Minumum face area = 5.425347e05. Maximum face area = 7.8125004e05. Face area magnitudes OK. Min volume = 5.425347e07. Max volume = 5.4253475e07. Total volume = 0.01. Cell volumes OK. Mesh nonorthogonality Max: 26.565056 average: 26.565051 Nonorthogonality check OK. Face pyramids OK. Max skewness = 0.45000007 OK. this is out of checkMesh But did you have a look on my fvSchemes? Is there some mistake that it couldn't work 2nd order? 
The only reason could be the limiter in vanLeer scheme. You can simply use "linear" to check. The rest should be fine.

I will check using a NVD and this linear scheme instead and i will tell you tomorrow the results.
The thing is that everything works fine (with vanLeerV) as long as the mesh is 100% orthogonal. Could there be another reason beside the convection scheme limiter? Do you prefer another scheme instead of vanLeer for incompressible flows? 
I generally use limitedLinearV, and, if this is not stable enough, linearUpwindV (a 2nd order upwind).

Hello,
i used SFCDV, linear and limitedLinearV. What is the total keyword in fvSchemes that linearUpwindV is working (in my case it will not work :confused: )? But all of them show the same result. When i use the orthogonal mesh, 2nd order is established; but the accuracy drops down to an area between 1 and 1.5 when the mesh is not totally orthogonal... The checkMesh information of this is given in #7. Some other suggestions? thanks 
I forgot to tell you: use leastSquares for gradients. Gauss linear is not second order on arbitrary meshes.

Hi again,
i tested several different ways to use this leastSquares for the gradient schemes. The problem is now converging with a rate lower then 1. SO it was "better" with Gauss linear instead, but even not 2nd order... Did i some mistake? Could you check it please?:confused::confused::confused: My simpleTolerance is 1e12 and my relTol is 0.01 Here is again my fvSchemes: gradSchemes { default none; grad(p) leastSquares; grad(U) leastSquares; snGradCorr(U) Gauss linear corrected; snGradCorr(p) Gauss linear corrected; } divSchemes { div(phi,U) Gauss GammaV 0.2; div((nuEff*dev(grad(U).T()))) Gauss linear; } laplacianSchemes { default none; laplacian(nuEff,U) Gauss linear limited 1.0; laplacian((1A(U)),p) Gauss linear limited 1.0; } interpolationSchemes { default none; interpolate(U) linear; } snGradSchemes { default corrected; } fluxRequired { default yes; p ; } 
You should post your case.

the solver and the case is attached.
Just start the case with ./doAllSkript If you have questions, just ask. thanks a lot for your help. rupert 
Hi,
this should give you second order: Code:
ddtSchemes 
I just specify either U or p as dirichlet.
The other one is always specified as fixedGradient (Neumann) BC. This should be OK, if i use the groovyBC the right way. i will test your suggestion for fvSchemes tomorrow. thanks so far.. 
Hi again,
i did it again and it is again 1st order :( Currently i'm not sure if it's really because of the skew mesh. I objected at straight meshes the biggest errors always at the boundary area, too. Maybe the error is already there at straight meshes but they are not influencing the order of accuracy that much... So i invest time now to check if all my boundaries etc. are implemented correctly. Maybe i can reduce the errors at the boundaries... Or does anybody have other suggestions? thanks 
Quote:
Best, 
5 Attachment(s)
Hi,
I hope I'm not annoying or interrupting you. If it is so, please tell and I'll move to a new thread :) I face a problem, that somehow can relate to the topic being discussed here. What I'm trying to do, set up a 3D pointsymmetric (or 1D in spherical coordinates) simulation to test my VOFbased evaporation model. So I made a sphericalsegmentlike mesh, consisting of prism elements, shown in the picture below. The issue is, I'm obtaining nonzero gradients of uniform fields with Gauss linear gradient scheme. Using of "fourths" or "Gaus cubic" schemes doesn't have such effect. I can imagine the gradient can be inaccurate, but I can't imagine how can it be nonzero using Gausslinearscheme, which just is supposed to take difference of some values in neighboring cells and divide it through the distance. If values are same (uniform field), the difference and thus the gradient is supposed to be zero, independent of the mesh, isn't is? Here are some pictures of mesh, alphafiled and it's gradient. In the first case there is a jump in the alphafield but it's uniform elsewhere away form the jump. In the second case I took completely uniform field, but there is still nonzero gradient. I also have zerogradientBCs on the left and right side, wedge BCs on the top and bottom, front and back. Best regards, illya 
All times are GMT 4. The time now is 03:06. 