I have been having troubles im
 

I have been having troubles implementing the fourth order surface normal gradient interpolation scheme. Each time I try, I receive an error message stating that only corrected, uncorrected and limited can be chosen.

I have checked the config dictionary files for FoamX, and they appear to contain the Fourth entry. Is there a different location where the solvers look for valid schemes?

Has anyone else experienced this issue, and if so, would you have any suggestions on how I can implement the fourth order scheme.

Thank you,

Adam

I just stumbled on the same pr
 

I just stumbled on the same problem. It has nothing to do with FoamX, cause I've never used it. Must be a list somewhere...

What version are you using? I'm still in 1.3.

/Ola

Even though it is listed in th
 

Even though it is listed in the user's manual,
the fourth order surface normal gradient interpolation scheme simply does not exist anymore!!
(as well as the bounded scheme)

have a look at: $FOAM_SRC/finiteVolume/finiteVolume/snGradSchemes

This is for OF 1.3 and above.
However in OF 1.2 if you look there:
$FOAM_SRC/OpenFOAM/finiteVolume/snGradSchemes,
tada! boundedSnGrad and fourthSnGrad are available.

Why did those schemes get removed after OF 1.2?
Hrv, Henry, any comments?

Another question related to surface normal gradient schemes:
the current snGradSchemes (based on a central finite difference between neighbour and owner cell centres) limit the application of OF to orthogonal or midly non-orthogonal meshes. Wouldn't a linear interpolation of the cell gradients at the face provide an estimate as accurate, yet able to tackle severly non-orthogonal meshes (such as the ones with anisotropic tetrahedral elements in the boundary layer of a wall-bounded high Re flow -- see picture below for an example)?

http://www.cfd-online.com/OpenFOAM_D...ges/1/5469.jpg

Fourth order snGrad still pres
 

Fourth order snGrad still present and correct in the dev line - you should be able to simply pick up the files and add to the compilation...

Hrv

It's actually present in my OF
 

It's actually present in my OF 1.3 installation (from Hrv) as well, but it's still not a valid runtime selection. Should it appear somewhere else as well?

/Ola

? Just tested it: Both thin
 

? Just tested it:

Both things like:

laplacian(nu,U) Gauss linear fourth;

and


snGradSchemes
{
default fourth;

}

work just fine. I have found that it was missing in the Make/files for the finiteVolume library, added it there (checked in the change into SVN) and all is well.

Hrv

Hrv, Is there any reason wh
 

Hrv,

Is there any reason why surface normal gradients are always approximated by:
{phi_N - phi_P}/|d| + nonOrthoCorrectors.

Why is the approach based on interpolating the cell gradients at the face intersection (like in the skew correction) discarded?
How can one accurately compute the normal gradients in the case depicted in my previous message? The nonOrthogonal correction seems only to work if the non-orthogonality is moderate...

Yes, this is fundamental - if
 

Yes, this is fundamental - if you do not have the phi_N - phi_P/delta bit, the implicit Laplacian will not be formed correctly on the compact molecule. Everything else is treated as a correction, including any non-orthogonal or skewness terms you may want to have. For details, see my Thesis.

Enjoy,

Hrv

ok, I got that part. My qu
 

ok,

I got that part.
My question was in fact about the alternative way to compute the surface normal gradients:
Instead of using {phi_N - phi_P}/|d| + ..., why not evaluating the cell-centred gradient for the 2 cells adjacent to the face at hand (using, say, Gauss linear), and interpolate it to the face. This involves a bigger computational molecule but on the other hand, it does not require any non-orthoganility correction and therefore should be more robust wrt non-orthogonality.
Has it ever been implemented in FOAM?

Patrick