Gradient at the boundary
Hi all,
one important thing came to my mind yesterday and I would appreciate your comments on this! Let's say we have a fixedGradient BC, and consider evaluate method for our field: Code:
template<class Type> fi(wall) = fi(cell_center) + Grad0 * d Is this a really correct estimation??? For example, if we use fourth order inside the domain for the interpolation and we end up with only (2nd?) order at the boundary using such BC type? I would really appreciate your comments! Have a nice day! Alexander |
Dear Alexander,
The lower order estimation on the boundary is correct. Of course you would also like a higher-order estimation on the boundary, but because it makes the implementation of such a scheme more complex, a lower order estimation on the boundary is acceptable. It should not influence the order of convergence of the solution in your domain. So your overall solution will not degrade from forth order accurate to second order accurate because you only use a second order accurate gradient estimation scheme on the boundary. I hope this helps! Kind regards, Francois. |
Francois, thank you for your reply!
Another point to discuss: there is no non-orthogonal correction at the boundary: Code:
00161 //- Return gradient at boundary |
Dear Alexander,
Could you not try a dot product between the velocity component and the the face area? Something like: Code:
boundaryUxValue = ( Ux & yourBoundaryPatch.patch().Sf() ); François. |
François, what should I check with this? Do you mean dot product between total velocity and normal vector to estimate flux?
|
Dear Alexander,
Yes. If you are afraid that the inbuilt implementations do not compute/use the solutions you expect, you can easily check that the values OpenFOAM uses are similar to those you would use in your own implementation. I thought this might help for your boundary. Kind regards, Francois. |
Hum. A quick look at the wiki also returned the following answer. This should take care of the issues altogether.
Quote:
Kind regards, Francois. |
Correction at boundary
Hi all,
can anyone clarify me this point, please: chosen a corrected scheme for the Laplacian computation, the non-orthogonal correction is applied automatically to the boundaries too? Thank you Andrea |
Correction at boundary
Hi all,
I'm confused about 2 points: looking into http://foam.sourceforge.net/doc/Doxy...8C_source.html I see on line 309: Code:
// Boundary correction vectors set to zero for boundary patches seems to be not implemented. And I read from many source that DeltaCoeffs() should be simply the inverse of the cell center to cell center vector while in the code is replaced by Code:
// Stabilised form for bad meshes Comments on these are appreciate Andrea |
2 Attachment(s)
Hi,
I have been looking at the calculation of gradients (fvc::grad) and surface-normal gradients (fvc::snGrad, and fvc::laplacian). As far as I can see, the snGrad is calculated incorrectly on non-orthogonal fixedValue boundaries. There should be non-orthogonal correction on fixedValue boundaries but it is set to zero (in surfaceInterpolation.C). I have prepared a simple utility to check: Code:
\*---------------------------------------------------------------------------*/ grad(alpha) should have the constant components (-0.00015, 0.017452, 0, -0.017452, -0.00015, 0, 0, 0, 0) and laplacian(alpha) should be (0, 0, 0).The alpha field actually corresponds to rigid rotation about the z-axis. fvc::grad(alpha) is calculated and seems correct, but the fvc::laplacian(alpha) is incorrect on non-orthogonal fixedValue boundaries! I have attached a non-orthogonal test case which shows the problem. Does anybody have any thoughts on this, am I misunderstanding something? Philip Edit: by the way, fvc::laplacian(alpha) is correct for fixedGradient boundaries because they don't need non-orthogonal correction as the surface-normal gradient is already known. Edit2: I tried this on OpenFOAM-2.1.x and OpenFOAM-1.6-ext with the same results. Also I checked old foam code and it seems to have no correction on the boundaries too, hmnnn... |
Hi,
for future reference, OpenFOAM sets non-orthogonal correction to zero on the boundaries. As described in Hrv's thesis, it is assumed that the dependent variable is uniform along the boundary face and hence no non-orthogonal correction is applied. However, there are cases (for instance in solid mechanics) when this is a poor assumption and it is assumed that the dependent variable varies linearly along the boundary face and boundary non-orthogonal corrections are imperative. So if you need boundary non-orthogonal correction then custom boundary conditions must be used where non-orthogonal corrections are imposed (see here). Philip |
All times are GMT -4. The time now is 17:00. |