[fisch]

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?

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((1|A(U)),p) Gauss linear corrected;
}

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

snGradSchemes
{
default none;
}

fluxRequired
{
default yes;
p ;
}


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

[alberto]

Please post a case and the convergence study.

[fisch]

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.

[alberto]

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]

thanks for the reply alberto,

the peclet number is in all directions smaller then 1.

[alberto]

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]

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]

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

[fisch]

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]

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

[fisch]

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 )?

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]

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

[fisch]

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?

My simpleTolerance is 1e-12 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((1|A(U)),p) Gauss linear limited 1.0;
}

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

snGradSchemes
{
default corrected;
}

fluxRequired
{
default yes;
p ;
}

[alberto]

You should post your case.

[fisch]

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]

Hi,

this should give you second order:

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]

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]

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]

Originally Posted by fisch

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]

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