CFD Online Discussion Forums (http://www.cfd-online.com/Forums/)
-   OpenFOAM (http://www.cfd-online.com/Forums/openfoam/)
-   -   accuracy of skew meshes? (http://www.cfd-online.com/Forums/openfoam/91686-accuracy-skew-meshes.html)

 fisch August 19, 2011 02:48

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:

{
default none;
}

divSchemes
{
div(phi,U) Gauss vanLeerV;
}

laplacianSchemes
{
default none;
laplacian(nuEff,U) Gauss linear corrected;
laplacian((1|A(U)),p) Gauss linear corrected;
}

interpolationSchemes
{
default none;
interpolate(U) linear;
}

{
default none;
}

fluxRequired
{
default yes;
p ;
}

// ************************************************** *********************** //

 alberto August 21, 2011 03:59

Please post a case and the convergence study.

 fisch August 22, 2011 02:34

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 max-Norm 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 non-orthogonal meshes?
Jasak is writing in his thesis that it should be possible with the non-orthogonal 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

 alberto August 22, 2011 10:09

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.

 fisch August 22, 2011 10:52

the peclet number is in all directions smaller then 1.

 alberto August 22, 2011 11:04

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.

 fisch August 22, 2011 11:09

Checking geometry...
Overall domain bounding box (0 0 0) (1.5 1 0.01)
Mesh (non-empty, non-wedge) directions (1 1 0)
Mesh (non-empty) directions (1 1 0)
All edges aligned with or perpendicular to non-empty directions.
Boundary openness (5.2090377e-18 -4.2269516e-18 1.4260487e-15) OK.
Max cell openness = 1.2490009e-16 OK.
Max aspect ratio = 1.6250001 OK.
Minumum face area = 5.425347e-05. Maximum face area = 7.8125004e-05. Face area magnitudes OK.
Min volume = 5.425347e-07. Max volume = 5.4253475e-07. Total volume = 0.01. Cell volumes OK.
Mesh non-orthogonality Max: 26.565056 average: 26.565051
Non-orthogonality 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?

 alberto August 22, 2011 11:13

The only reason could be the limiter in vanLeer scheme. You can simply use "linear" to check. The rest should be fine.

 fisch August 22, 2011 11:23

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?

 alberto August 22, 2011 11:26

I generally use limitedLinearV, and, if this is not stable enough, linearUpwindV (a 2nd order upwind).

 fisch August 23, 2011 02:30

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

 alberto August 23, 2011 09:35

I forgot to tell you: use leastSquares for gradients. Gauss linear is not second order on arbitrary meshes.

 fisch August 24, 2011 10:33

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 1e-12 and my relTol is 0.01

Here is again my fvSchemes:
{
default none;
}

divSchemes
{
div(phi,U) Gauss GammaV 0.2;
}

laplacianSchemes
{
default none;
laplacian(nuEff,U) Gauss linear limited 1.0;
laplacian((1|A(U)),p) Gauss linear limited 1.0;
}

interpolationSchemes
{
default none;
interpolate(U) linear;
}

{
default corrected;
}

fluxRequired
{
default yes;
p ;
}

 alberto August 24, 2011 11:53

 fisch August 25, 2011 02:26

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

 alberto August 25, 2011 11:10

Hi,

this should give you second order:

Code:

```ddtSchemes {     default        steadyState; } gradSchemes {     default        leastSquares; } divSchemes {   div(phi,U)              Gauss linear;   div((nuEff*dev(grad(U).T()))) Gauss linear; } laplacianSchemes {     default        none;     laplacian(nuEff,U) Gauss linear corrected;     laplacian((1|A(U)),p) Gauss linear corrected; } interpolationSchemes {     default        linear; } snGradSchemes {     default        corrected; } fluxRequired {     default        yes;     p              ; }```
At a first glance, it looks like you are fixing p and U at all your boundaries, in an incompressible solver. Usually where you fix U you specify a zeroGradient for p. I do not know what you are trying to simulate, but I would double-check.

 fisch August 25, 2011 15:48

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..

 fisch August 26, 2011 10:17

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

 alberto August 27, 2011 21:58

Quote:
 Originally Posted by fisch (Post 321776) 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.
Simply perform the study with simple BC's in a simple test case (a cavity flow or a channel flow, for example), and just change the mesh. If the order is 2, you have your answer ;-)

Best,

 linch September 6, 2011 13:01

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 VOF-based evaporation model. So I made a spherical-segment-like mesh, consisting of prism elements, shown in the picture below. The issue is, I'm obtaining non-zero 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 non-zero using Gauss-linear-scheme, 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, alpha-filed and it's gradient. In the first case there is a jump in the alpha-field but it's uniform elsewhere away form the jump. In the second case I took completely uniform field, but there is still non-zero gradient. I also have zero-gradient-BCs 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 10:19.