[doerschlott]

Dear fellow Foamers,

lately I digged into some very old (though helpful) threads about Low-Re modelling in OpenFOAM. I suppose that since then, a lot of implementations have changed. So I decided to start this new thread and hopefully gather some up-to-date information and valuable discussions on this topic. Unfortunately, the first post will be quite lengthy, as I want to present my current state of understanding, uncertainties and open questions.

To clear some misunderstandings beforehand, I’d like to point out that Low-Re modelling refers to modelling the wall-near turbulence with fine meshes that resolve the viscous sublayer (meaning yPlus ~1). In particular, this thread is not about transitional turbulence modelling (laminar to turbulent), which is a different topic.

Furthermore, most of the information on specific boundary conditions are taken from the User/API Guide from the v2006 ESI Version of OpenFOAM, as this documentation became quite extensive lately and the descriptions offer a good insight into the implementation (apart from the actual source code of course).
https://www.openfoam.com/documentati...es/latest/doc/
However, experience with the Foundation version of OpenFOAM (e.g. 6, 7, 8) is welcomed.
For the following, let’s assume a fully turbulent pipe flow and a two-equation eddy viscosity turbulence model:

The boundary conditions for inlet / outlet look as follows for all cases:

k:
fixedValue / zeroGradient

omega:
fixedValue / zeroGradient

epsilon:
fixedValue / zeroGradient
 
nut:
calculated / calculated

Starting with the “classical” approach of High-Re modelling, so coarse meshes with yPlus > 30, first cell in logarithmic region -> relies on wall-functions to better approximate the velocity profile at the wall according to the law of wall. I hope that this law is already known to everybody, as it will be an important subject for the following discussion.
The boundary conditions (BCs) for the wall would look like:

k:
kQRWallFunction

omega:
omegaWallFunction

epsilon:
epsilonWallFunction

nut:
nutkWallFunction (for example)

In detail, kQRWallFunction inherits from a zeroGradient, whereas omegaWallFunction and nutkWallFunction inherit from fixedValue basically. In my experience, these setups are quite stable and I rarely have problems with them.

Things change however, when I started doing Low-Re meshes and setups. I have to admit, that it took quite a bit to realise, that these setups require special treatment. I know Ansys CFX where the automatic wall treatment does quite a lot of magic without demanding the user at all. Now I did some research and want to discuss my planned approach.
So for the Low-Re modelling (fine meshes, yPlus ~1, viscous sublayer resolved with some cells), I realised that dedicated turbulence models should be used, for example LaunderSharmaKE, LamBremhorstKE or kOmegaSST (though this is applicable to High-Re as well, I think).

k:
kLowReWallFunction

omega:
omegaWallFunction

epsilon:
epsilonWallFunction (?)

nut:
nutLowReWallFunction

nutLowReWallFunction seems to be only a placeholder for a fixedValue zero for nut, but holds some inherited information like yPlus calculation and coefficients/constants from nutWallFunction.
kLowReWallFunction, omegaWallFunction and epsilonWallFunction are fixedValue patches, but also inherit the specified coefficients from the nut patch (for the sake of consistency).
I recently realised, that many of those patches are now able to blend between a Low-Re and a High-Re mode with different blending methods, which might be deactivated by default (lowReCorrection for epsilonWallFunction). That sounds like an automatic wall treatment to me and until now I thought that only the omegaWallFunction or nutUSpaldingWallFunction is capable of such.

With this I’d like to leave a comment on a setup with only “classical” boundary conditions, such as fixedValue and zeroGradient and why I think that those might not be applicable anymore:

k:
fixedValue {uniform 1e-10}

omega:
omegaWallFunction

epsilon:
fixedValue {uniform *high value*} (or zeroGradient?)

nut:
fixedValue {uniform 0} (or calculated)

Physically, k is zero at the wall but for numerical reasons, it is set to a very small non-zero value.
nut is physically zero and numerically unproblematic, so it is set to zero.
I have to admit that I’m not sure for epsilon, but omega should definitely be possible with the omegaWallFunction, regardless of the OF version.
However, as the new implementation of some BCs, like omegaWallFunction, rely on the coefficients from nut, I think fixedValue zero is no longer applicable for nut.
Though I have to admit that I’m not sure at all, about this classical setup and I’d really like to hear your opinions on that.

Congratulations, you’ve made it to the end! And still I didn’t cover everything I wanted, like wall roughness, heat transfer and Reynolds Stress Models. But I think this offers more than enough fodder for conversation and the rest will hopefully be topics for later.
As I’ve said, don’t consider this post as a fountain of truth but rather how I perceived the current implementation and I most likely have gotten some stuff wrong. I would really appreciate a vast discussion with you and your experiences with Low-Re modelling in (preferably recent versions of) OpenFOAM.

Best regards
doerschlott

[dlahaye]

Are there low-Re tutorials that one could explore to gain more insight into this matter?

[doerschlott]

At least not for the low-re boundary conditions like kLowReWallFunction.
There are cases, like
"$FOAM_TUTORIALS/incompressible/boundaryFoam/boundaryLaunderSharma" or
"$FOAM_TUTORIALS/incompressible/pimpleFoam/RAS/elipsekkLOmega"
which use the nutLowReWallFunction, however I'm not familiar with boundaryFoam solver nor the k-kl-omega turbulence model, so I cannot comment on the usefulness regarding low-re modelling.


Best regards
doerschlott

[sinatahmooresi]

Originally Posted by doerschlott

Dear fellow Foamers,

lately I digged into some very old (though helpful) threads about Low-Re modelling in OpenFOAM. I suppose that since then, a lot of implementations have changed. So I decided to start this new thread and hopefully gather some up-to-date information and valuable discussions on this topic. Unfortunately, the first post will be quite lengthy, as I want to present my current state of understanding, uncertainties and open questions.

To clear some misunderstandings beforehand, I’d like to point out that Low-Re modelling refers to modelling the wall-near turbulence with fine meshes that resolve the viscous sublayer (meaning yPlus ~1). In particular, this thread is not about transitional turbulence modelling (laminar to turbulent), which is a different topic.

Furthermore, most of the information on specific boundary conditions are taken from the User/API Guide from the v2006 ESI Version of OpenFOAM, as this documentation became quite extensive lately and the descriptions offer a good insight into the implementation (apart from the actual source code of course).
https://www.openfoam.com/documentati...es/latest/doc/
However, experience with the Foundation version of OpenFOAM (e.g. 6, 7, 8) is welcomed.
For the following, let’s assume a fully turbulent pipe flow and a two-equation eddy viscosity turbulence model:

The boundary conditions for inlet / outlet look as follows for all cases:

k:
fixedValue / zeroGradient

omega:
fixedValue / zeroGradient

epsilon:
fixedValue / zeroGradient
 
nut:
calculated / calculated

Starting with the “classical” approach of High-Re modelling, so coarse meshes with yPlus > 30, first cell in logarithmic region -> relies on wall-functions to better approximate the velocity profile at the wall according to the law of wall. I hope that this law is already known to everybody, as it will be an important subject for the following discussion.
The boundary conditions (BCs) for the wall would look like:

k:
kQRWallFunction

omega:
omegaWallFunction

epsilon:
epsilonWallFunction

nut:
nutkWallFunction (for example)

In detail, kQRWallFunction inherits from a zeroGradient, whereas omegaWallFunction and nutkWallFunction inherit from fixedValue basically. In my experience, these setups are quite stable and I rarely have problems with them.

Things change however, when I started doing Low-Re meshes and setups. I have to admit, that it took quite a bit to realise, that these setups require special treatment. I know Ansys CFX where the automatic wall treatment does quite a lot of magic without demanding the user at all. Now I did some research and want to discuss my planned approach.
So for the Low-Re modelling (fine meshes, yPlus ~1, viscous sublayer resolved with some cells), I realised that dedicated turbulence models should be used, for example LaunderSharmaKE, LamBremhorstKE or kOmegaSST (though this is applicable to High-Re as well, I think).

k:
kLowReWallFunction

omega:
omegaWallFunction

epsilon:
epsilonWallFunction (?)

nut:
nutLowReWallFunction

nutLowReWallFunction seems to be only a placeholder for a fixedValue zero for nut, but holds some inherited information like yPlus calculation and coefficients/constants from nutWallFunction.
kLowReWallFunction, omegaWallFunction and epsilonWallFunction are fixedValue patches, but also inherit the specified coefficients from the nut patch (for the sake of consistency).
I recently realised, that many of those patches are now able to blend between a Low-Re and a High-Re mode with different blending methods, which might be deactivated by default (lowReCorrection for epsilonWallFunction). That sounds like an automatic wall treatment to me and until now I thought that only the omegaWallFunction or nutUSpaldingWallFunction is capable of such.

With this I’d like to leave a comment on a setup with only “classical” boundary conditions, such as fixedValue and zeroGradient and why I think that those might not be applicable anymore:

k:
fixedValue {uniform 1e-10}

omega:
omegaWallFunction

epsilon:
fixedValue {uniform *high value*} (or zeroGradient?)

nut:
fixedValue {uniform 0} (or calculated)

Physically, k is zero at the wall but for numerical reasons, it is set to a very small non-zero value.
nut is physically zero and numerically unproblematic, so it is set to zero.
I have to admit that I’m not sure for epsilon, but omega should definitely be possible with the omegaWallFunction, regardless of the OF version.
However, as the new implementation of some BCs, like omegaWallFunction, rely on the coefficients from nut, I think fixedValue zero is no longer applicable for nut.
Though I have to admit that I’m not sure at all, about this classical setup and I’d really like to hear your opinions on that.

Congratulations, you’ve made it to the end! And still I didn’t cover everything I wanted, like wall roughness, heat transfer and Reynolds Stress Models. But I think this offers more than enough fodder for conversation and the rest will hopefully be topics for later.
As I’ve said, don’t consider this post as a fountain of truth but rather how I perceived the current implementation and I most likely have gotten some stuff wrong. I would really appreciate a vast discussion with you and your experiences with Low-Re modelling in (preferably recent versions of) OpenFOAM.

Best regards
doerschlott

Hello doerschlott,

Thanks for this very useful thread.

Regarding the applications of low-Re turbulence models, my take on your discussion is that even with a fine mesh that is able to resolve the wall all the way down with (y+~`1), we still need to put low-Re versions of wall functions where these versions are able to automatically provide the fixedValue or zeroGradient B.C.s needed for turbulence parameters (e.g. k, epsilon, omega, nut) at the wall, instead of using fixedValue, ....

Moreover, what if we have y+>~30 and still intended to use low-Re turbulence models? Without hesitation, we use the low-Re versions of wall functions, instantly? Thus, your discussions is a clarification on why we still need to use wall function (low-Re versions, to be specific) even if the mesh is resolving the viscous sub-layer while using low-Re turbulence models?

Thanks

[doerschlott]

Originally Posted by sinatahmooresi

Hello doerschlott,

Thanks for this very useful thread.

Regarding the applications of low-Re turbulence models, my take on your discussion is that even with a fine mesh that is able to resolve the wall all the way down with (y+~`1), we still need to put low-Re versions of wall functions where these versions are able to automatically provide the fixedValue or zeroGradient B.C.s needed for turbulence parameters (e.g. k, epsilon, omega, nut) at the wall, instead of using fixedValue, ....

Moreover, what if we have y+>~30 and still intended to use low-Re turbulence models? Without hesitation, we use the low-Re versions of wall functions, instantly? Thus, your discussions is a clarification on why we still need to use wall function (low-Re versions, to be specific) even if the mesh is resolving the viscous sub-layer while using low-Re turbulence models?

Thanks

Hello sinatahmooresi,


quite some time has passed since I started this thread and I gained some experience since then. I got some convincing results on turbulent heat transfer when using the dedicated low-Reynolds "wall functions" BCs and low-Re turbulence models on a good mesh with yPlus < 1.
I do agree that one should use this setup, as it is generally more convenient (and more correct) than the fixedValue approach, which was just a guess based on the theory behind turbulence.


To your question about using these in case of yPlus > 30:
Looking at the exact implementation in the *.c files, they all should have a switch to decide, whether they apply wall functions or not. (This decision is based on the calculated yPlusLam.) So technically it should be possible, but I would use the high-Re wall functions and turbulence models, when I intend to model my problem with real wall functions and a mesh aiming at yPlus > 40.


So to conclude, the cleaner way that I would suggest is to tune turbulence BCs to the mesh, but I did not test a yPlus>30 mesh with low-Re BCs, so don't take my advice as absolute. But I think in general you should check your BCs and mesh twice if you want to resolve the boundary layer properly.


Best regards
doerschlott