[vkrastev]

Hi all,

I'm doing some work with the SAS model and one of the first checks I've done of the OF (2.2.x) implementation follows the original sources. In the .H source file, it is stated that the implementation follows:

DESider A European Effort on Hybrid RANS-LES Modelling:
Results of the European-Union Funded Project, 2004 - 2007
(Notes on Numerical Fluid Mechanics and Multidisciplinary Design).
Chapter 2, section 8 Formulation of the Scale-Adaptive Simulation (SAS)
Model during the DESIDER Project. Published in Springer-Verlag Berlin
Heidelberg 2009.
F. R. Menter and Y. Egorov.

Well, I don't have the above mentioned reference but I have the following two:

"Development and Application of SST-SAS Turbulence
Model in the DESIDER Project"
Y. Egorov and F. Menter,
S.-H. Peng and W. Haase (Eds.): Adv. in Hybrid RANS-LES Modelling, NNFM 97, pp. 261–270, 2008.

"The Scale-Adaptive Simulation Method for Unsteady
Turbulent Flow Predictions. Part 1: Theory
and Model Description"
Flow Turbulence Combust (2010) 85:113–138

Both of them define the QSAS term (additional term in the omega-equation which distinguishes the RANS and SAS SST formulations) in the same way, the only differences being in the formal rearrangement of some constants. The OpenFOAM implementation (either 2.2.x or 2.3.x) is different, as:

1) the whole QSAS term is multiplied by FSAS=1.25;
2) apart from multiplying constants, the QSAS term is formulated as QSAS=max(C,0), where C=A-B. In the references above, the B term contains a CSAS=2 constant, which is not there in the OF version.

Aside from the fact that I really don't like when people writes "I have implemented this like that" when, in fact, this is not true, can someone comment on why these discrepancies are there? I haven't find any tread about this in the forum, so I guess it will be useful to start a new one.

Thank you in advance

V.

[cnsidero]

Originally Posted by vkrastev

Aside from the fact that I really don't like when people writes "I have implemented this like that" when, in fact, this is not true...

It's not the only one. The forums are littered with such discussions. I encourage you to review all of the turbulence models to the published definitions.

[vkrastev]

Originally Posted by cnsidero

It's not the only one. The forums are littered with such discussions. I encourage you to review all of the turbulence models to the published definitions.

Thanks for the reply. Well, I'm already doing it whenever I have to use a new model (for instance, in the past I found a sign discrepancy in the Launder Sharma k-epsilon model, I also mentioned it in the bug report system and the developers did fix the inconsistency). What I cannot really accept is the total lack of justification of whichever proposed modification to the original reference: a sign can be, of course, merely a coding mistake; different constants or differently calculated terms are, instead, intentional so some justification should be added (even something like "we did it just because works better" will be acceptable). Formally, since the OF sources are open and released with no warranty, the developers are not responsible for these "departures" from the original scientific sources. Morally, I simply don't like this attitude. And, after all is said and done, I would still like to know why the SAS implementation is different.

Regards

V.

[cnsidero]

Originally Posted by vkrastev

Formally, since the OF sources are open and released with no warranty, the developers are not responsible for these "departures" from the original scientific sources.

My thinking in this regard is that its misleading to call the models by their published names but the implementations, as you point out, do not necessarily correspond. I feel it would be more appropriate to rename them, e.g. OpenFOAM SAS: Based on but not necessarily implemented exactly as the SST-SAS Turbulence model of the DESIDER Project.

But ultimately it's up to end user to properly verify and validate any model they use and never assume it's correct by default. Caveat emptor.

That's my $0.02.

[vkrastev]

Originally Posted by cnsidero

My thinking in this regard is that its misleading to call the models by their published names but the implementations, as you point out, do not necessarily correspond. I feel it would be more appropriate to rename them, e.g. OpenFOAM SAS: Based on but not necessarily implemented exactly as the SST-SAS Turbulence model of the DESIDER Project.

But ultimately it's up to end user to properly verify and validate any model they use and never assume it's correct by default. Caveat emptor.

That's my $0.02.

You hit the target. If it wasn't stated "this is the SAS model based on blablabla..." I will be ok with any implementation discrepancy, just because I'm not paying anyone to be sure of the product quality. BUT, if the statement is there, though it still remains formally correct to claim "I'm not responsible for the code correctness" it is not very serious to release a large and mature CFD project like OF this way, without explaining what these modifications will actually produce (e. g. "This is here for numerical stability issues") and, which is worse, without even mentioning that the reported reference(s) is(are) actually not followed!

Anyway, thank you for the interesting discussion (and if someone knows the practical reasons for the differences in the OF SAS implementation, it is still welcome here)

V.

[cnsidero]

Originally Posted by vkrastev

You hit the target. If it wasn't stated "this is the SAS model based on blablabla..." I will be ok with any implementation discrepancy, just because I'm not paying anyone to be sure of the product quality. BUT, if the statement is there, though it still remains formally correct to claim "I'm not responsible for the code correctness" it is not very serious to release a large and mature CFD project like OF this way, without explaining what these modifications will actually produce (e. g. "This is here for numerical stability issues") and, which is worse, without even mentioning that the reported reference(s) is(are) actually not followed!

Anyway, thank you for the interesting discussion (and if someone knows the practical reasons for the differences in the OF SAS implementation, it is still welcome here)

My involvement with the turbulence models in OpenFOAM is more technical than I'm letting on. I've verified a quite a few RANS, DES and LES models and of the ones I've looked at most if not all deviate from published (or accepted) versions of the respective model. Sorry but I haven't yet investigated the SAS model so I can't comment on it directly.

What I will say is that I've given up to trying to figure "why" they were modified and simply implement my own version following a published/accepted implementation. A good example is the OpenFOAM SA RAS model. For some reason, they choose the version with the fv3 term. However, the original authors even recommend against using it. See here: http://turbmodels.larc.nasa.gov/spalart.html and search for fv3. Rather than understand their reason for choosing that model, I simply implemented the "standard" SA with curvature correction.

[vkrastev]

Originally Posted by cnsidero

My involvement with the turbulence models in OpenFOAM is more technical than I'm letting on. I've verified a quite a few RANS, DES and LES models and of the ones I've looked at most if not all deviate from published (or accepted) versions of the respective model. Sorry but I haven't yet investigated the SAS model so I can't comment on it directly.

What I will say is that I've given up to trying to figure "why" they were modified and simply implement my own version following a published/accepted implementation. A good example is the OpenFOAM SA RAS model. For some reason, they choose the version with the fv3 term. However, the original authors even recommend against using it. See here: http://turbmodels.larc.nasa.gov/spalart.html and search for fv3. Rather than understand their reason for choosing that model, I simply implemented the "standard" SA with curvature correction.

I too have struggled with the SA fv3-nofv3 term question, but if I remember correctly in that case there was some "official" comment from the developers, at least here in the forum, which stated that in more complex geometries-->bad quality meshes (e. g. complete F1 cars) the OF implementation helped numerical stability. Your "check-and-implement" practice is of course the best one, I usually try to follow the same but still I found annoying to discover misleading references around the code sources. Currently I am checking the effects in reverting the SAS implementation to the original one, there will be also some questions to clarify about how to set properly wall boundary conditions so I think I will post some of my conclusions here (or in a dedicated tread), in order to help other potential SAS+OF users.

Best

V.

[Flo_Ha]

Hi all,

I´m using OpenFOAM 4.x and trying to do a simulation with the kOmegaSSTSAS model. I would like to compare those results with Fluent SAS results.

I have been reading almost everything i could find in this forum about the SAS model, but i´m still not able to solve my problem.

The problem is: It seems, that the simulation remains in RAS mode.

I would be interested, if anyone was able to get good result with the kOmegaSSTSAS..... At the moment, i´m not very happy with what i get.

Best regards Flo

[AndreasPe]

Hi Flo and all others,

I am also investigating on using the SAS turbulence model with OpenFOAM. Nevertheless, i am using Foam-Extend-4.0, where the SAS model is implemented as a LES type and not RAS as it is in OpenFOAM-4.x. In my opinion it would be more consistent to have it as a RAS model, as it is based on the kOmegaSST model, right? Does anyone know, why it is implemented as a LES type in foam-extend-4.0?

I managed to get some resolved turbulence with the infamous cylinder flow at Re=30000 as you can see in the image attached (Q-Criterion with isosurfaces of Q=5000). Also I get a strange error message when omega is computed. I searched for this error in the forum and also googled it but all i found was the specific line in the OpenFOAM code of the omegaWallFunction. It seems that in LES there is no G-field accessable when using wall functions? Im not very familiar with LES:

From function void omegaWallFunctionFvPatchScalarField::updateCoeffs( )
in file derivedFvPatchFields/wallFunctions/omegaWallFunctions/omegaWallFunction/omegaWallFunctionFvPatchScalarField.C at line 179
Cannot access RASModel::G field for patch CYLINDER. Evaluating as zeroGradient

Also in the single timesteps the nonlinear residuals are not converging to my desired tolerance (1e-5 for all variables) either, I am working on that though. I use the pimpleFoam solver and my yPlus values are between 0.26 and 16, averaging around 6.36 as the mesh was originally inteded for Re=3000 as a lowReynolds mesh. As divScheme for U I use the blended scheme with a coefficient of 0.95. I think one has to use a rather high quality discretisation of the divergence Schemes as too diffusive schemes may dampen the turbulent fluctuations too much.


What is the case you are looking at, and what is your setup? Especially discretisation schemes would be interesting.

Best

Andreas

[albet]

Originally Posted by AndreasPe

Hi Flo and all others,

I am also investigating on using the SAS turbulence model with OpenFOAM. Nevertheless, i am using Foam-Extend-4.0, where the SAS model is implemented as a LES type and not RAS as it is in OpenFOAM-4.x. In my opinion it would be more consistent to have it as a RAS model, as it is based on the kOmegaSST model, right? Does anyone know, why it is implemented as a LES type in foam-extend-4.0?

I managed to get some resolved turbulence with the infamous cylinder flow at Re=30000 as you can see in the image attached (Q-Criterion with isosurfaces of Q=5000). Also I get a strange error message when omega is computed. I searched for this error in the forum and also googled it but all i found was the specific line in the OpenFOAM code of the omegaWallFunction. It seems that in LES there is no G-field accessable when using wall functions? Im not very familiar with LES:

From function void omegaWallFunctionFvPatchScalarField::updateCoeffs( )
in file derivedFvPatchFields/wallFunctions/omegaWallFunctions/omegaWallFunction/omegaWallFunctionFvPatchScalarField.C at line 179
Cannot access RASModel::G field for patch CYLINDER. Evaluating as zeroGradient

Also in the single timesteps the nonlinear residuals are not converging to my desired tolerance (1e-5 for all variables) either, I am working on that though. I use the pimpleFoam solver and my yPlus values are between 0.26 and 16, averaging around 6.36 as the mesh was originally inteded for Re=3000 as a lowReynolds mesh. As divScheme for U I use the blended scheme with a coefficient of 0.95. I think one has to use a rather high quality discretisation of the divergence Schemes as too diffusive schemes may dampen the turbulent fluctuations too much.


What is the case you are looking at, and what is your setup? Especially discretisation schemes would be interesting.

Best

Andreas

Hello Andreas,

I found that this problem comes out when you insert the zero value for the initial condition in omega Field! However it is only happening in foam-extend 4.0 as long as I find!
Maybe it is result of division by zero somewhere!

Regards,
Amir