[Jonathan]

hi,

can anyone give me any idea how much non-orthogonal correction i should use for various degree's of mesh non-orthogonality? i.e. does anyone have any rules of thumb which they use, or is there a reference which gives a correlation which is useful?

attached is the checkMesh log for my mesh:

Checking geometry...
    Overall domain bounding box (0.130442 -0.0549428 -0.037182) (0.203 0.0872362 0.13)
    Mesh (non-empty, non-wedge) directions (1 1 1)
    Mesh (non-empty) directions (1 1 1)
    Boundary openness (7.59581e-16 -3.63295e-15 5.78617e-16) OK.
    Max cell openness = 1.68871e-14 OK.
    Max aspect ratio = 231.559 OK.
    Minumum face area = 7.34819e-12. Maximum face area = 1.23274e-06.  Face area magnitudes OK.
    Min volume = 7.08378e-16. Max volume = 9.05793e-10.  Total volume = 0.000532329.  Cell volumes OK.
    Mesh non-orthogonality Max: 83.0423 average: 27.5722
   *Number of severely non-orthogonal faces: 315461.
    Non-orthogonality check OK.
  <<Writing 315461 non-orthogonal faces to set nonOrthoFaces
    Face pyramids OK.
    Max skewness = 3.19643 OK.
    Coupled point location match (average 1.33389e-10) OK.

Mesh OK.

many thanks
Jonathan

[billie]

Originally Posted by Jonathan

hi,

can anyone give me any idea how much non-orthogonal correction i should use for various degree's of mesh non-orthogonality? i.e. does anyone have any rules of thumb which they use, or is there a reference which gives a correlation which is useful?

attached is the checkMesh log for my mesh:

Checking geometry...
    Overall domain bounding box (0.130442 -0.0549428 -0.037182) (0.203 0.0872362 0.13)
    Mesh (non-empty, non-wedge) directions (1 1 1)
    Mesh (non-empty) directions (1 1 1)
    Boundary openness (7.59581e-16 -3.63295e-15 5.78617e-16) OK.
    Max cell openness = 1.68871e-14 OK.
    Max aspect ratio = 231.559 OK.
    Minumum face area = 7.34819e-12. Maximum face area = 1.23274e-06.  Face area magnitudes OK.
    Min volume = 7.08378e-16. Max volume = 9.05793e-10.  Total volume = 0.000532329.  Cell volumes OK.
    Mesh non-orthogonality Max: 83.0423 average: 27.5722
   *Number of severely non-orthogonal faces: 315461.
    Non-orthogonality check OK.
  <<Writing 315461 non-orthogonal faces to set nonOrthoFaces
    Face pyramids OK.
    Max skewness = 3.19643 OK.
    Coupled point location match (average 1.33389e-10) OK.

Mesh OK.

many thanks
Jonathan

First of all I would try to improve the mesh. 83 degree is high, probably to high. Try to get down to below 70. For meshes below 70 setting the non-orthogonal corrector to 1 works here most of the time.

[Jonathan]

Originally Posted by billie

First of all I would try to improve the mesh. 83 degree is high, probably to high. Try to get down to below 70. For meshes below 70 setting the non-orthogonal corrector to 1 works here most of the time.

hi - thanks a lot - the mesh is a little tricky unfortunately, so what i want to do is use a limited 0.3 / 0.5 scheme for the laplacian term in fvSchemes, and i was wondering how much correction to do?

regarding the nOrthoCorr loops, i am running a steady-state simulation, so as far as i understand it, i dont need to use additional 'corrector' loops in the SIMPLE loop - i think the iterative nature of the steady-state SIMPLE routine takes care of that? Would you be able to comment on that from your experience (i.e. do i understand it correctly)?

Also, does non-orthogonal correction (i.e. nOrthoCorr loops) work without setting the laplacian to some form of corrected / limited scheme? i.e. if i just add nOrthoCorr loops but no correction to the laplacian term, am i actually achieving anything??

Many thanks and regards in advance
Cheers
jonathan

[billie]

Originally Posted by Jonathan

regarding the nOrthoCorr loops, i am running a steady-state simulation, so as far as i understand it, i dont need to use additional 'corrector' loops in the SIMPLE loop - i think the iterative nature of the steady-state SIMPLE routine takes care of that? Would you be able to comment on that from your experience (i.e. do i understand it correctly)?

What do you mean with additional 'corrector' loops? If you are taking about nCorrectors, this is only used with PISO based solvers or nOuterCorrectors in addition with PIMPLE based solvers. So for SIMPLE solvers there are no additional loops beside the nNonOrthogonalCorrectors.

Originally Posted by Jonathan

Also, does non-orthogonal correction (i.e. nOrthoCorr loops) work without setting the laplacian to some form of corrected / limited scheme? i.e. if i just add nOrthoCorr loops but no correction to the laplacian term, am i actually achieving anything??

That is a good question. I do not know how this is related. However I noticed with a non-orthogonal mesh setting the laplacianSchemes to uncorrected and the snGradSchemes to corrected as well as using leastSquares as gradientScheme lead to quicker convergence. The individual iterations took longer but all in all the simulation time was reduced.

[Jonathan]

hi billie,

Originally Posted by billie

What do you mean with additional 'corrector' loops? If you are taking about nCorrectors, this is only used with PISO based solvers or nOuterCorrectors in addition with PIMPLE based solvers. So for SIMPLE solvers there are no additional loops beside the nNonOrthogonalCorrectors.

in SIMPLE controls in fvSolution, you can add

SIMPLE
{
    nNonOrthogonalCorrectors 0;

    residualControl
    {
    p    1e-8;
    Urel    1e-8;
    k    1e-8;
    omega    1e-8;
    }
}

which loops over this section of code

    // Non-orthogonal pressure corrector loop
    while (simple.correctNonOrthogonal())
    {
        fvScalarMatrix pEqn
        (
            fvm::laplacian(rAU, p) == fvc::div(phi)
        );

        pEqn.setReference(pRefCell, pRefValue);

        pEqn.solve();

        if (simple.finalNonOrthogonalIter())
        {
            phi -= pEqn.flux();
        }
    }

in the SIMPLE procedure, and runs additional non-orthogonal correction loops.

That is a good question. I do not know how this is related. However I noticed with a non-orthogonal mesh setting the laplacianSchemes to uncorrected and the snGradSchemes to corrected as well as using leastSquares as gradientScheme lead to quicker convergence. The individual iterations took longer but all in all the simulation time was reduced.

ok, thanks - that is interesting. My simulation blew up with leastSquares for gradSchemes, even though this is supposed to be better for nonorthogonal meshes and more accurate in general. Using uncorrected for the laplacian should stabilise and aid convergence since i think the solution matrix becomes poorly conditioned with non-orthogonal correction.

btw, i would be interested to know where snGradSchemes is used explicitly in the code - i thought that the snGradScheme for the laplacian (which is what i am trying to correct) was specified separately in the laplacian dictionary - i.e.

laplacian(nuEff,Urel)     Gauss linear corrected; //uncorrected etc

what do you think?

cheers
jonathan

[billie]

Originally Posted by Jonathan

hi billie,



in SIMPLE controls in fvSolution, you can add

SIMPLE
{
    nNonOrthogonalCorrectors 0;

    residualControl
    {
    p    1e-8;
    Urel    1e-8;
    k    1e-8;
    omega    1e-8;
    }
}

which loops over this section of code

    // Non-orthogonal pressure corrector loop
    while (simple.correctNonOrthogonal())
    {
        fvScalarMatrix pEqn
        (
            fvm::laplacian(rAU, p) == fvc::div(phi)
        );

        pEqn.setReference(pRefCell, pRefValue);

        pEqn.solve();

        if (simple.finalNonOrthogonalIter())
        {
            phi -= pEqn.flux();
        }
    }

in the SIMPLE procedure, and runs additional non-orthogonal correction loops.

Now I understand. You are questioning the use of nNonOrthogonalCorrectors for SIMPLE based solvers. Well there must be a reason the code is there, so it probably makes sense to use nNonOrthogonalCorrectors even for SIMPLE based solvers.

Originally Posted by Jonathan

btw, i would be interested to know where snGradSchemes is used explicitly in the code - i thought that the snGradScheme for the laplacian (which is what i am trying to correct) was specified separately in the laplacian dictionary - i.e.

laplacian(nuEff,Urel)     Gauss linear corrected; //uncorrected etc

what do you think?

I found nothing in the code as well, so it depends on the solver and simpleFoam does not require it. You can just remove snGradSchemes from fvSchemes. In my case I was using chtMultiRegionSimpleFoam which requires it.