Support other DES models

[panda-z]

Hello Bruno,

The current function object only support DES based on SpalartAllmaras model. To support kOmegaSST DES (and DDES) models, the DES model framework should be redesigned.

Here is my proposal:

1. Adding a new class template named DESModel which derived from LESeddyViscosity.

   template<class BasicTurbulenceModel>
   class DESModel
   :
   public LESeddyViscosity<BasicTurbulenceModel>
   // ...

2. DESModel contains a pure virtual function LESRegion() which is an LES/RANS region indicator.

   virtual tmp<volScalarField> LESRegion() const = 0;

3. All DES models will be derived from DESModel.

P.S.: In OpenFOAM plus, they've added two classes: DESModelBase and DESModel. The pure virtual function LESRegion() is in DESModelBase. And DESModel is derived from DESModelBase and LESeddyViscosity. (I don't know the purpose of inheriting from DESModelBase here)

After refactoring, the function object can be more general and consistent, and can support more DES models. What do you think?

[wyldckat]

Hi @panda-z,

The only reason why that hasn't been done on OpenFOAM.org is because there is no method for calculating LESRegion in the k-omega DES implementation that they have.

Does OpenFOAM+ have that calculation?

Here is the base example method that calculates it: https://github.com/OpenFOAM/OpenFOAM-6/blob/master/src/TurbulenceModels/turbulenceModels/LES/SpalartAllmarasDES/SpalartAllmarasDES.C#L378

[panda-z]

Yes. In OpenFOAM+ there is an implementation of LESRegion() in kOmegaSSTDES.

It is done by comparing $Lt=\frac{\sqrt{k}}{\beta^\ast \omega}$ and $C{DES} \Delta$. See the source code. It is also mentioned in Menter's paper[1].

[1] Menter, F. R., Kuntz, M., & Langtry, R. (2003). Ten years of industrial experience with the SST turbulence model. Turbulence, Heat and Mass Transfer, 4(1), 625–632.

[wyldckat]

!!! And it's also implemented in the OpenFOAM-history repository, which means that it should be possible to integrate it directly into OpenFOAM.org: https://github.com/OpenCFD/OpenFOAM-history/blob/master/src/TurbulenceModels/turbulenceModels/LES/kOmegaSSTDES/kOmegaSSTDES.C

The issue is that either the code has to be re-coded or copyright assigned, but this method in kOmegaSSTDES that is in the OpenFOAM-history repository already had its copyright transferred to the OpenFOAM Foundation, therefore we can still integrate it almost as-is.

So now the question is this: Do you want to adapt this yourself and is so, are you able to sign the contribution agreement that the OpenFOAM Foundation requires in order to accept source code? I ask this because even though this is just mostly a hacking job and not so much creating new copyrighted material, it may still require signing the contribution agreement.

In either way, yes, the consolidation of the DES models would very much be accepted by the OpenFOAM Foundation, the main issue would just be who would maintain it afterwards... but it's currently sort-of unmaintained just the same, so we might as well bring it up to a point closer to needing only minimal maintenance work.

[panda-z]

That would be great! I'd like to sign contribution agreement. I'm also willing to maintain the DES models.

I'll write the code in the next couple of days. After finishing the work, I'll consider transfer the code to OpenFOAM Foundation.

[wyldckat]

Please keep in mind that you cannot use code from OpenFOAM+ directly. At most, you can only use the code from the OpenFOAM-history repository.

Of course you can also use the code in this repository as well, given that I can also contribute to the Foundation.

[panda-z]

Dear Bruno, thank you for the reminder. I know that copy code from OpenFOAM+ is copyright infringement and will not do that. Actually, the code from OpenFOAM-history is very helpful.

However, I have an issue during writing the LESRegion() method.

Due to this commit https://github.com/OpenFOAM/OpenFOAM-dev/commit/02dd85167e1ebb56fdc435e169c3d0a5645b641e , several methods in kOmegaSSTDES return volScalarField::Internal instead of volScalarField. But LESRegion() requires the returns of a volScalarField type variable.

Do you know any methods to create volScalarField variable from volScalarField::Internal, or to covert volScalarField::Internal to volScalarField?

[wyldckat]

Hi @panda-z,

LESRegion() itself being of type volScalarField::Internal shouldn't be much of a problem, given that a patch can't be of either RAS or LES by itself. But when writing to a file, then yes, definitely it would be useful to have boundaries.

From what I can see, there is currently only one constructor that allows creating a new field based on Internal: https://cpp.openfoam.org/dev/classFoam_1_1GeometricField.html#aa706bc2a05982be4fa158477751f8bd2 - and in the code: https://github.com/OpenFOAM/OpenFOAM-dev/blob/9a22110c14368e438e5ab05aaeadf9873b28dd1d/src/OpenFOAM/fields/GeometricFields/GeometricField/GeometricField.C#L292

To use it, I haven't tried this yet, but it should be something like this:

tmp <volScalarField> newField
(
    IOobject
    (
        "newFieldName",
        this->runTime_.timeName(),
        this->mesh_,
        IOobject::NO_READ,
        IOobject::NO_WRITE
    ),
    theInternalFieldOrCalculation,
    aDonorVolScalarField.boundaryField()
);

where:

• theInternalFieldOrCalculation is the field variable or calculation that is of type volScalarField::Internal.
• aDonorVolScalarField is some field that donates its boundary conditions for copying to the new field variable newField.

The alternative would require constructing a new PtrList<PatchField<...>>... I have to look into the code, because if this constructor exists, is because it's being used somewhere...

---

edit: I haven't searched yet, but I then saw that GeometricField< Type, PatchField, GeoMesh >::Boundary that boundaryField() returns, also inherits from PtrList<PatchField<...>>, therefore it should work just fine. The donor field could be the k_ field variable, given that it's the most common one.

[panda-z]

Dear Bruno, thanks for the hint. Actually I was seeking for the new style construction GemetricField<Type>::New and didn't realize the old-style constructor for GeometricField ;)

Anyway, it now compiles without problem. The working code snippet is a bit different from your given example:

tmp<volScalarField> newField
(
    new volScalarField
    (
        IOobject
        (
            "newFieldName",
            this->runTime_.timeName(),
            this->mesh_,
            IOobject::NO_READ,
            IOobject::NO_WRITE
        ),
        theInternalFieldOrCalculation,
        aDonorVolScalarField.boundaryField()
    )
);

I'll test the code in several days. Thank you again for your efforts.

[panda-z]

I've write to OpenFOAM Foundation and got their reply.

They said the current framework of DESModelRegions is not easy to maintain so it can not be pulled back into OpenFOAM-dev. They are planning a more general way to output turbulence related fields via functionObjects.

So I'm closing this issue.

[wyldckat]

Many thanks for feedback!

And my apologies, I could have checked with them first as well, but the notion I had was that this could have been intermediate work, to also help them gain traction with the DES implementations.

As with everything related to OpenFOAM: assume nothing, test/check everything first...

[panda-z]

Hi Bruno,

You're welcome.

Yes, they replied to me that the new approach is not a high-priority work. Let's wait and see.

[wyldckat]

Hi @panda-z,

So they essentially didn't accept it, because it would be an intermediate patch that would then go to waste and would simply be added maintenance overhead... but in the meantime, either people use OpenFOAM+ or don't have kOmegaDES with this function object...

Given that it's not a priority on their side and if you've already done these changes, could you take a bit more time to make a push request here on this repository with either just the new code and/or push the changes to a forked repo from OpenFOAM-dev into your https://github.com/panda-z account. I ask this so that we can then at least provide this as an intermediate solution to those who have been asking for this on the forum.

[panda-z]

Hi Bruno,

I've forked OpenFOAM-dev repo and pushed the related changes on the desmodel branch .

Alternatively, one can obtain a patch from here and apply it to local OpenFOAM-dev repository using git apply.

Theoretically, it works with OpenFOAM 5/6, but may need trivial modification (I haven't tested yet).

[wyldckat]

Hi @panda-z,

Many thanks! I'll look into this during the next weekend.

I'll mention that you did the modifications, but I don't know if you prefer that I only mention your Github account or also mention your real name?

[panda-z]

Hi Bruno, you can mention my name which is Weiwen Zhao . Thank you

[wyldckat]

I'm reopening this issue, so that I don't forget as easily...