[skabilan]

Hi All,

I tried a simple case, transient flow through a cylinder. I am interested in the pressure gradient in the face normal direction at the boundaries. The output from gAverage(p.boundaryField()[patchIndex].snGrad()) is way off compared to the manual pressure gradient calculation, i.e, (pressure@inlet - pressure@outlet)/length of cylinder

Any help with the Sngrad() operator to compute the pressure gradient would be appreciated.

Thanks
Senthil

[mattijs]

You posted in the OpenFOAM-bugs forum. This does not seem to be a bug. The snGrad returns the (discretised) face-normal gradient. See programmers guide P-40.

[niklas]

may I suggest that you use your new supermoderator-powers and move the thread

[skabilan]

Hi Mattijs,

Shouldn't the face normal gradient at the oulet returned by the gAverage(p.boundaryField()[patchIndex].snGrad()) be closer to (pressure@inlet - pressure@outlet)/length of cylinder?

Warm Regards,
Senthil

[deinstein]

Originally Posted by mattijs

You posted in the OpenFOAM-bugs forum. This does not seem to be a bug. The snGrad returns the (discretised) face-normal gradient. See programmers guide P-40.

Mattijs,

I think there is a bit of misunderstanding here. snGrad appears to assume that one is using a structured grid in which the front and back faces are parallel. Clearly, in the case of a tetrahedral grid, this will not work. Since the two faces will never be parallel. We have confirmed that the order of error is equal to the cosine of the angle between the two faces. If snGrad was designed ONLY to work with structured hex meshes, than this is not a bug, but this limitation is not documented. If snGrad was designed to be general, than this is a bug.

Kind Regards,
Dan

[hjasak]

(I got this question in an E-mail, hence the response)

Sorry, I cannot follow what you are talking about: snGrad()
is a surface normal gradient:

(p_b - p_P)/delta

where p_b is the value at the boundary and p_P the value in
the next cell. There is no assumption of th mesh structure,
apart from there being a cell in front of a boundary face
(whatever its shape may be).

The other option you have got is to use the cell-centred
gradient next to the boundary and dot it with the direction.

volVectorField gradP = fvc::grad(p);

gradP.boundaryField()[patchI].patchInternalField() & patch.n().

I must have missed the point: what are you trying to tell me?

Hrv

[deinstein]

Dear Hrv.

No doubt we are doing something wrong. When we do as you suggest with a tet mesh (something we did before posting). We find that using the two cell centers and dotting with the normal we get the right answer (we are doing this on a cyclinder so we know the right answer). Instead, when we use snGrad, we get the wrong answer, and the answer appears to be off by the angle between back face and front face, where front face is on the boundary. snGrad is convenient. A workaround we have settled upon is to extrude the tet mesh a little bit such that the boundary elements are prisms with perfectly parallel front and back. We just thought it might be useful to let others know.

Dan