[cosimobianchini]

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

[henry]

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.

[henry]

Here is a corrected version of kOmegaSST.C
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.

[cosimobianchini]

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

[henry]

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?

[cosimobianchini]

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

[chibsen]

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:stream&) 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.

[henry]

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.

[gschaider]

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

[cosimobianchini]

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

[henry]

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.

[cosimobianchini]

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

[chibsen]

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

Claus.

[a-jp]

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

[msohail]

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

[henry]

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

[braennstroem]

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

[henry]

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

[braennstroem]

Thanks for the explanation!

Fabian

[msohail]

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 .