|
[Sponsors] |
March 14, 2012, 11:48 |
Calculation of wall normal gradients
|
#1 |
New Member
Join Date: Aug 2009
Location: Stuttgart, Germany
Posts: 20
Rep Power: 16 |
Hi everybody,
I'm currently having some trouble calculating the surface normal gradients for velocity and temperature using the OpenFOAM 1.7.x post-processing tools wallGradU and wallGradT (modified wallGradU). Both tools use the built-in snGrad() function to retrieve the normal gradient at the wall, but when I calculate the gradients using other post-processing software the results seem to differ especially for temperature. The flow field I'm trying to simulate is a 2D turbulent supersonic flow over a backward facing step, and the wall of interest is the bottom part of the channel, where a recirculation zone is followed by flow reattachment (as can be seen in the Mach number contour plot, the flow is coming in from the left side). The solver is a slightly modified version of rhoCentralFoam which includes turbulence. For turbulence modeling the k--SST model without wall functions is used, the wall itself is resolved with . The grid is structured, so the wall resolution does not change along the channel. The velocity and temperature gradients were obtained by the following tools:
The main problem seems to be in the reattachment zone, for the very beginning and end of the wall the curves fit quite well. As the basic dataset is the same for all tools this strange behaviour does not seem to be related to the solver settings and the calculation, but mainly to the post-processing utilities I used. However, assuming the snGrad function used in OF is working correctly I don't have any clue what could cause this deviations... Because there is no constant factor between the results I think a grid connection (i.e. wrong cell centre / node distances) can also be ruled out. I already tried refining the grid and also changed the snGrad treatment in fvSchemes from corrected to uncorrected, but without any considerable improvement of the results. Does anybody have an idea why these results are that different or maybe did observe similar problems? I saw that some more people tried to use a wallGradT tool, but the programming seems to be more or less the same for all - did it work correctly for your simulations? Also I'm fairly sure the wallGradU utility has been used quite a lot, but does anybody have some experience using it for supersonic flows? Thanks a lot! |
|
April 12, 2012, 09:18 |
|
#2 |
New Member
Join Date: Aug 2011
Location: Paris
Posts: 20
Rep Power: 14 |
Hallo,
I am interested in wallGrandT too, and I am wondering : Did you find out an explanation for the gradient of T "error" ? Mehdi |
|
April 13, 2012, 03:08 |
|
#3 |
New Member
Join Date: Aug 2009
Location: Stuttgart, Germany
Posts: 20
Rep Power: 16 |
Hi Mehdi,
no, I did not yet manage to find an explanation for this deviations in gradient calculation. However, I am currently validating it against other codes and analytical solutions for a much simpler flow field (i.e. laminar and turbulent flat plates) and up to now it seems that the error is considerably smaller for that kind of flow. But this would basically mean that the more complex the flow the higher the error in gradients... As soon as I have final results for the flat plate I'll try to post a comparison, maybe that will help to find the cause of this problem. What surprised me was that apparently nobody else had difficulties with the gradients, but as I can definitely rule out errors regarding mesh and boundary conditions (checked that several times and the solution itself looks very reasonable apart from the difference in gradients) I don't know what I possibly could have done wrong with the backward facing step. Regards, Nils |
|
April 13, 2012, 05:16 |
|
#4 |
New Member
Join Date: Aug 2011
Location: Paris
Posts: 20
Rep Power: 14 |
Hi Nils,
Did you try to use nsGradCorr in wallGradT instead of snGrad ? Do you think it could be the reason of the discrepancy ? Mehdi |
|
April 13, 2012, 06:06 |
|
#5 |
New Member
Join Date: Aug 2009
Location: Stuttgart, Germany
Posts: 20
Rep Power: 16 |
No, I did not yet do that, but it indeed may be worth a try.
However, as far as I understand this correction is mainly designed for curved surfaces, or am I wrong? So as in all my cases all boundaries are perfectly plane I suppose it won't improve much. But I'll try that as soon as possible. Regards, Nils |
|
June 17, 2014, 09:06 |
|
#6 | |
New Member
Chris
Join Date: May 2014
Posts: 2
Rep Power: 0 |
Quote:
i tried to replace it to get a better solution for my cylinder Problem but by compiling it gives me an error : struct Foam::fvPatchField<double> has no element called 'snGradCorr' hope you can help |
||
June 18, 2014, 05:48 |
|
#7 |
Super Moderator
Philip Cardiff
Join Date: Mar 2009
Location: Dublin, Ireland
Posts: 1,086
Rep Power: 34 |
Hi,
By default in OpenFOAM, boundary snGrad neglects non-orthogonal correction; this may be the cause of the discrepancy. You could check by comparing OpenFOAM and CFX for a perfectly orthogonal mesh and a non-orthogonal mesh. Boundary non-orthogonal correction is important in some applications, such as solidMechanics. Take a look at the fixedDisplacementFvPatchVectorField BC in foam-extend-3.0; it implements boundary non-orthogonal correction within its implementation of snGrad in contrast to fixedValueFvPatchVectorField. Philip |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
normal distance for wall trubulence | jeff | Main CFD Forum | 2 | August 13, 2017 16:55 |
WALL normal velocity | Luca | Main CFD Forum | 1 | October 8, 2014 06:21 |
Errors running allwmake in OpenFOAM141dev with WM_COMPILE_OPTION%3ddebug | unoder | OpenFOAM Installation | 11 | January 30, 2008 21:30 |
NACA0012 geometry/design software needed | Franny | Main CFD Forum | 13 | July 7, 2007 16:57 |
momentum equation (Normal to wall_ | kk | Main CFD Forum | 0 | July 3, 2006 00:10 |