[ndr]

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:

• OF post-processing tools wallGradU / wallGradT.
• CFXPost, using the built-in gradient calculation. The OF dataset was imported into CFX completely, so no interpolation errors because of sampling should have occured.
• Excel, using both a linear and a second order approach for the gradient. Here also the velocity and temperature data was taken directly from the OF result files at the location of the first cell centre above the wall (and additionally the second cell centre for the second order approach).

So in my opinion all three programs should have used exactly the same dataset. But as you can see in the attached plots there are considerable differences between the OF results and the other tools, especially for the temperature gradient. CFX nearly exactly reproduces the linear approach from Excel. The second order calculation should be slightly more accurate than the linear one, but those two fit each other quite well.
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!

[M3hdi]

Hallo,

I am interested in wallGrandT too, and I am wondering :

Did you find out an explanation for the gradient of T "error" ?

Mehdi

[ndr]

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

[M3hdi]

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

[ndr]

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