Hi, I'm not really sure it i
 

Hi,
I'm not really sure it is a bug (I'm still working with version 1.3 and so I didn't try it) but it seems to me that the new (1.4.1 release) compressible kOmegaSSTomega has wrong production terms for both omega and k equations (also dimensionally):

/* this is the relevant part of the code

volScalarField GbyMu = 2*mut_*(tgradU() && dev(symm(tgradU())));

volScalarField G = mut_*GbyMu;

tmp<fvscalarmatrix> omegaEqn
(
fvm::ddt(rho_, omega_)
+ fvm::div(phi_, omega_)
- fvm::laplacian(DomegaEff(F1), omega_)
==
rhoGammaF1*GbyMu
- fvm::SuSp((2.0/3.0)*rhoGammaF1*divU, omega_)
- fvm::Sp(rho_*beta(F1)*omega_, omega_)
- fvm::SuSp
(
rho_*(F1 - scalar(1))*CDkOmega/omega_,
omega_
)

tmp<fvscalarmatrix> kEqn
(
fvm::ddt(rho_, k_)
+ fvm::div(phi_, k_)
- fvm::laplacian(DkEff(F1), k_)
==
min(G, c1*betaStar*k_*omega_)
- fvm::SuSp(2.0/3.0*rho_*divU, k_)
- fvm::Sp(rho_*betaStar*omega_, k_)
);

I guess that it should instead be something like:
volScalarField G_DividedbyMu = 2*(tgradU() && dev(symm(tgradU())));

volScalarField G = mut_*G_DividedbyMu;

tmp<fvscalarmatrix> omegaEqn
(
fvm::ddt(rho_, omega_)
+ fvm::div(phi_, omega_)
- fvm::laplacian(DomegaEff(F1), omega_)
==
rhoGammaF1*G_DividedbyMu
- fvm::SuSp((2.0/3.0)*rhoGammaF1*divU, omega_)
- fvm::Sp(rho_*beta(F1)*omega_, omega_)
- fvm::SuSp
(
rho_*(F1 - scalar(1))*CDkOmega/omega_,
omega_
)

tmp<fvscalarmatrix> kEqn
(
fvm::ddt(rho_, k_)
+ fvm::div(phi_, k_)
- fvm::laplacian(DkEff(F1), k_)
==
min(G, c1*betaStar*k_*omega_)
- fvm::SuSp(2.0/3.0*rho_*divU, k_)
- fvm::Sp(rho_*betaStar*omega_, k_)
);

Can you please tell me if someone agrees with me?
Regards
Cosimo

Yes your are correct, I implem
 

Yes your are correct, I implemented the model just before release and didn't have time to test it. I will check it through again, test it and post a corrected version next week sometime.

Here is a corrected version of
 

Here is a corrected version of kOmegaSST.C
http://www.cfd-online.com/OpenFOAM_D...hment_icon.gif kOmegaSST.C
to replace the file in OpenFOAM-1.4.1/src/turbulenceModels/compressible/kOmegaSST

I have tested the model runs and give sensible results but I have not performed a rigorous validation.

Hi Henry, just another small
 

Hi Henry,
just another small doubt about the limiter for mut.

I could not download the paper you suggest as reference for this model but the reference paper I used for implementing the kOmegaSST (Heat Transfer Predictions using Advanced Two-Equation Turbulence Models; Wolfgang Vieser, Thomas Esch and Florian Menter; CFX Technical Memorandum: CFX-VAL10/0602, 2002) have a different limiter for mut:

mut = rho* a1*k/max(a1*omega,sqrt(2)*mag(symm(gradU)*F2));

The standard release instead is using:
mut = rho* a1*k/max(a1*omega,mag(symm(gradU)*F2));

Is it a bug or it is just a correction to make it suitable for heat transfer applications?
Please tell me what is your paper saying about that.
Thanks a lot
Cosimo

All the k-Omega papers I have
 

All the k-Omega papers I have give this term without the sqrt(2) but then it could easily be contained in a1. What value is proposed for a1 in CFX-VAL10/0602 and does it differ from the value proposed in the papers on the model?

I defintely agree with you.
 

I defintely agree with you.
My value for a1 is 0.31 so if the two equations are consistent your should be 0.31/sqrt(2) = 0.2192.
Thanks for confirming that.
Cosimo

Hi, I am testing the kOmega
 

Hi,

I am testing the kOmegaSST model using the above kOmegaSST.C file.
I am getting this error messages:

--> FOAM FATAL ERROR : incompatible dimensions for operation
[omega[1 -3 -2 0 0 0 0] ] - [((rho*((tanh(pow4(min(min(max((((1|betaStar)*sqrt( k))|(omega*y)),((500*(mu|rho) )|(sqr(y)*omega))),(((4*alphaOmega2)*k)|(max((((2* alphaOmega2)*(grad(k)&grad(ome ga)))|omega),1.0e-10)*sqr(y)))),10)))*(gamma1-gamma2))+gamma2))*((2*mut)*(grad(U )&&dev(symm(grad(U))))))[2 -4 -3 0 0 0 0] ]#0 Foam::error::printStack(Foam:http://www.cfd-online.com/OpenFOAM_D...part/proud.gifstream&) in "/home/ci/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/libOpenFOAM.so"
#1 Foam::error::abort() in "/home/ci/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/libOpenFOAM.so"
#2 void Foam::checkMethod<double>(Foam::fvMatrix<double> const&, Foam::GeometricField<double,> const&, char const*) in "/home/ci/OpenFOAM/OpenFOAM-1.4.1/applications/bin/linuxGccDPOpt/rhoSimpleFoam"
#3 Foam::tmp<foam::fvmatrix<double> > Foam::operator-<double>(Foam::tmp<foam::geometricfield<double,> > const&, Foam::tmp<foam::fvmatrix<double> > const&) in "/home/ci/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/libcompressibleTurbulenceMod els.so"
#4 Foam::compressible::turbulenceModels::kOmegaSST::c orrect() in "/home/ci/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/libcompressibleTurbulenceMod els.so"
#5 main in "/home/ci/OpenFOAM/OpenFOAM-1.4.1/applications/bin/linuxGccDPOpt/rhoSimpleFoam"
#6 __libc_start_main in "/lib/libc.so.6"
#7 Foam::regIOobject::readIfModified() in "/home/ci/OpenFOAM/OpenFOAM-1.4.1/applications/bin/linuxGccDPOpt/rhoSimpleFoam"


From function checkMethod(const fvMatrix<type>&, const GeometricField<type,>&)
in file /home/dm2/henry/OpenFOAM/OpenFOAM-1.4.1/src/finiteVolume/lnInclude/fvMatrix.C at line 1232.

FOAM aborting

Is that an error in my setup of the case, or is the error in the kOmegaSST.C file?

Thanks,
Claus.

The value of a1 in the papers
 

The value of a1 in the papers I have is also 0.31. I don't know at what point Menter added the sqrt(2) prefactor I haven't seen it in any of the published papers on the k-Omega model I have but I don't have a full set.

Hi Claus! I would guess tha
 

Hi Claus!

I would guess that the problem is with the setup. One common problem is that people take a k-eps-case, rename the epsilon-file to omega but don't change the dimensions (although that would not explain the difference in dimensions in your case). Check the dimensions

Bernhard

Hi Weller, I also have got a
 

Hi Weller,
I also have got an article without the sqrt(2):
Menter, Two Equation Eddy-Viscosity Turbulence Models for Engineering Applications, AIAA Journal Vol.32 , N 8, 1994.
In that case however:

mut = rho* a1*k/max(a1*omega,mag(OMEGA)*F2));

with OMEGA = absolute value of vorticity = mag(curl(U)) != strain rate magnitude = 0.5*(grad(U) + grad(U).T).

Could this be the mistake? Am I misunderstanding anything?
Regards
Cosimo

It is not a mistake, the model
 

It is not a mistake, the model has evolved over the years particularly in this term. I assure your that what I have implemented is what is in the paper I refer to in the header. I cannot say if the form you are referring to is preferable to the form I have implemented as I do not have all the relevant literature on the subject.

You are right: there are sever
 

You are right: there are several different versions of such model. I do not have all the papers as well but, as far as I can see, your version is actually the same model implemented in CFX 10.
Thanks for this clarification,
Cosimo

I forgot to wmake... everythin
 

I forgot to wmake... everything is working nice now.
Sorry for the inconvenience.

Claus.

Could somebody please supply m
 

Could somebody please supply me with an electronic copy of: Heat Transfer Predictions using Advanced Two-Equation Turbulence Models; Wolfgang Vieser, Thomas Esch and Florian Menter; CFX Technical Memorandum: CFX-VAL10/0602, 2002

I understand this explains the automatic wall function treatment for the SST model, I would appreciate any papers which discuss this, not just the above. The only reference I can find is in Menter's Ten years of industrial experiance with the SST model, ref [8], but I can't seem to find the paper anywhere??

Any help would be appreciated.

Cheers,
Andy

I have the same problem .I want to know how SSt handels low Re number flows

The k-omega-SST model I implemented is the high-Re form to be used with the standard, continuous/adaptive or rough wall-functions supplied. However it would be quite easy to implement the low-Re form of the model as this simply requires the application of damping functions on a few terms.

H

As I understood it, the current implemented SST model is suitable for low-re flows as well. Though one needs different wall treatment (especially for omega). And maybe the use of some damping functions is better. Do you have any experience in it?

Fabian

The k-omega-SST model we currently release is based on a blend of the high-Re k-epsilon and k-omega models, not the low Re k-omega model. With an adaptive/continuous wall-function you can use this model to resolve the near-wall low-Re flow with some degree of accuracy but if you want to resolve these details accurately you will need to include the low-Re damping-functions into the k-omega part of the model and use a mesh with adequate resolution in the near-wall region.

H

Thanks for the explanation!

Fabian

Thanks a lot .
But by solving right to the wall will be espensive right that's why we avoid that .Rather than using wall functions will be a cheap alternative. I don't know what CFX using as a standard SST model .

here is an important paper about SST
http://cfd.mace.manchester.ac.uk/flo...-SST-paper.pdf

Dear Henry,

which one of the implemented wall functions do you exactly mean with an adaptive/continuous wall-function? I need to resolve a low-Re flow, using your implemented SST-Model, as accurate as possible.

Thanks,

Björn

I am referring to nutSpalartAllmarasWallFunction for incompressible flow and mutSpalartAllmarasWallFunction for compressible flow. Even though these were created for use with the Spalart-Allmaras model they are not dependent on this particular model in any way being generic implementations of the Spalding continuous wall-function using U rather than k as the controlling variable and can be used with other turbulence models.

We tested the kOmegaSST model with the nutSpalartAllmarasWallFunction wall-function and obtained good results, as good as others have obtained with adaptive/continuous wall-functions.

H

Hi to everybody!
Which kind of wall treatment do you use for omega? I've implemented the Menter's omega wall b.c. (Menter, AIAA Journal Vol 32 No 8, 1994), and I used it with kWall = 0 and nutWall = nutWallFunction (maybe nutSpalartAllmarasWallFunction is better) on a low Re mesh of an airfoil, with good results on attached flows, but still not ok results in separated zones...

Ivan,

Out of curiosity, how are you evaluating results? Using lift-drag data (lift-curve slope, zero-lift angles, stall angles) or against flowfield data (surface pressue, boundary layer rakes, etc)? How do they compare against using omegaWallFunction for omega at the wall? What's your yplus?

We used omegaWallFunction for omega.

H

We use to compare some flow data (wall cp, boundary layer profiles, wake profiles) against some experimental data that we have. We have also comparison with other codes on the same problems. My y+ is less than 2 everywhere, as required from the omega b.c. of Menter.
Now, thanks to Henry's hint, I'm trying Menter's omega b.c. and the Spalart Allmaras wall function for nut, next some results!

We have just pushed an enhancement to the omegaWallFunction which now includes both the laminar and log-law components blended as Menter et. al. specify:

Description
Provides a wall function boundary condition/constraint on omega

Computed value is:

omega = sqrt(omega_vis^2 + omega_log^2)

where
omega_vis = omega in viscous region
omega_log = omega in logarithmic region

Model described by Eq.(15) of:
@verbatim
Menter, F., Esch, T.
"Elements of Industrial Heat Transfer Prediction"
16th Brazilian Congress of Mechanical Engineering (COBEM),
Nov. 2001
@endverbatim

H

Wonderful!
This could be really a big jump for near wall modelling in OpenFOAM!
Do you have pushed in the 1.6.x version?
And, do you suggest to use it in conjunction with the nutSpalartAllmarasWallFunction in order to model y+ ranges O(1)?
Thank you Henry!

> Do you have pushed in the 1.6.x version?

Yes, Andy pushed it into OpenFOAM-1.6.x yesterday.

> And, do you suggest to use it in conjunction with the nutSpalartAllmarasWallFunction in order to model y+ ranges O(1)?

Yes it is probably the best way if you cannot afford the resolution required to run a low-Re model. In the next release we will rename nutSpalartAllmarasWallFunction to nutUSpaldingWallFunction to make it clear that it is a general purpose continuous wall-function using U as the defining variable.

H

Hi Henry,

good work! What is your experience with the missing averaging for cells with more than one boundary? Probably, this could produce some trouble!?

Fabian

It's not normally a big issue because such cells are usually in corners in which case simple boundary-layer modeling is not strictly applicable and the flow may be complex or stagnant and often unimportant. Nevertheless we have put this on our TODO list so at least the behavior will be the same as the previous implementation of wall-functions.

H

Henry,

thanks for the great work and this clarification. This was not really clear to me how 1.6.x handles turbulence modeling. Youre right renaming nutSpalartAllmarasWallFunction to nutUSpaldingWallFunction will make it clearer.
Final question about low-Re models (e.g. LaunderSharmaKE). Tutorials use "calculated" for both k and epsilon at walls, but some in the forum used "calculated". What is the correct one?

Regards BastiL

Which tutorials use "calculated" for the wall BC of k and epsilon? This would neither be correct nor would the code run.

H

None. However, some of the users reported tha tin other threads and it seem to run. I was just wondering how it was supposed to be uses.
For the "nutSpalartAllmarasWallFunction"-wall function I learned this can be uses with kOmegaSST quite sucessful. Is it also intended to use it with other of the Hi-Re-Models like Standard K-epsilon or realisable? Thanks.

BastiL

Actually the "nutSpalartAllmarasWallFunction"-wall function is generic and obtains the details of the boundary layer from the velocity field rather than k and hence can be used with any of the high-Re turbulence models.

H

Thanks, Henry. Now this is clear to me.

Regards.

Dear Henry and RANS-experts,

first of all, thank you for the improved near wall treatement (NWT) of kOmegaSST. I really appreciate it. :)
However, to have a reliable NWT, 2 questions may arise:

1) Production term:

• From my point of view, the production term of k (called G) looks correct for small y+ and within the log-law region, but the if-condition may cause problems, if y+ is in the buffer layer.
• Some paper propose a smooth blending of this term, which is perhaps less problematic than the implemented if-condition.
• As far as I know, Menter never said (mentioned) a single word about this term. "Just one of this annoying secrets of CFX ;)"
• Fluent proposes that one can use the following formula everywhere, as long as tau_w is consistent with the velocity gradient based on the "automatic wall function". G=[(tau_w)^2]/(kappa*rho*(C_mu)^0.25*sqrt(k)*y)
• What do you think about that? Is the implemented G unproblematic with respect to the buffer-layer?

2) Turbulent thermal diffusivity:

• If we use wall functions for alphat, the following formula is used: alphat=mu_t/Pr_t
• A lot of papers use the temperature profile proposed by Kader. Do you think such an adaptation leads to significant better results in cases with adiabatic walls?

Any comments are welcome. Thanks


Andi

Ps.: As english is not my mother tongue, some statements may sound a bit rude. If this is so, don't take it amiss. It was never my intention.

Sorry
 

Sorry wrong thread

Hello FOAMers,

i take my chance to ask some questions about NWT in case of setting boundary conditions on walls. When using wall functions (kOmegaSST in my simulation) i looked in the associated code kqRWallFunctionFvPatchField.H(C), nutWallFunctionFvPatchScalarField.C(H), omegaWallFunctionFvPatchScalarField.C(H) hoping to see what is expected.
The Header description of kqRWallFunction sais: "Simply acts as a zero gradient condition". But when i set the k file like
i get an error message, because OF is missing a value! Why that when treating as zeroGradient. Same problem with omega and nut. In case of a high-Re model i thought, that 'von Neumann'-condition is feasible at all (the need of values when using wallFunctions disagree with that)!???
In my knowledge (i.e. from low-Re Turbulence Modeling) k on walls is 0, because U=0, omega should be high, nut is nearly 0. Are these values expected also in high-Re models when trying to keep y+ within log-law region.
Maybe someone can give advice on NWT boundary conditions in case of high-Re turbulence model.

Thanks in advance!

~stefan