[ErenC]

Hi everyone!

I need to sum the production-destruction terms and form a new field in the SpalartAllmaras model, but I always get different errors. So, there are few things I can't understand.
Such as:

tmp<fvScalarMatrix> nuTildaEqn 
        (
            fvm::ddt(alpha, rho, nuTilda_)                                          // transient
          + fvm::div(alphaRhoPhi, nuTilda_)                                         // u*div(nuTilda)
          - fvm::laplacian(alpha*rho*DnuTildaEff(), nuTilda_)                       // (nu+nuTilda) term, DnuTilda=(nutilda+nu)/sigmanu
          - Cb2_/sigmaNut_*alpha*rho*magSqr(fvc::grad(nuTilda_))                    // cb2 term
         ==
            Cb1_*alpha()*rho()*Stilda*nuTilda_()                                    // (1-ft2) abd cb1*ft2/k^2 term is not present
          - fvm::Sp(Cw1_*alpha()*rho()*fw(Stilda)*nuTilda_()/sqr(y_), nuTilda_)     // cw1*fw*nuTilda^2/d^2
          + fvOptions(alpha, rho, nuTilda_)
        );

what is "nuTilda_()"? I checked the Turbulence subfolder and there is no function called "nuTilda_()" we just define the nuTilda_ in the protected functions.
Here rho and the nuTilda_ are volScalarFields, y_, Stilda, fw are volScalarField::Internal. In OF implementation, they can multiply these as you can see in the code, but when I create a new volScalarField it gives error because of these internalFields due to mismatch. such as:

error: conversion from ‘Foam::tmp<Foam::Field<double> >’ to non-scalar type ‘Foam::volScalarField’ {aka ‘Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>’} requested
  436 |     volScalarField dif = Cw1_*rho*fw(Stilda)*sqr(nuTilda_)/sqr(y_);

Here is y_ and fw is internalField and nuTilda_ is volScalarField. It causes no problem in fvMatrix but it causes error when I multiply them.

I know I'm missing something fundamental here, if anyone can point it I'll be glad.

Best wishes,
Eren.

[Tobermory]

what is "nuTilda_()"? I checked the Turbulence subfolder and there is no function called "nuTilda_()" we just define the nuTilda_ in the protected functions.

nuTilda_ is a volScalarField, as you note, i.e. is a class derived from GeometricField. So, take a look in GeometricField.H (https://cpp.openfoam.org/v12/Geometr...ce.html#l00077) to see what operator() has been defined as and we find:

         //- Return a const-reference to the dimensioned internal field
         //  Useful in the formulation of source-terms for FV equations
         inline const Internal& operator()() const;

in other words, for any volScalarField a, a() returns a const reference to the internal field. As the .H comment says, this is useful for source terms (where the added boundary info in the full volScalarField has no meaning).

That explains the first part of your question, but does not fix your error. Have you tried defining dif1 as volScalarField::Internal? I can see that OF might struggle if the end result of your calculation, an volScalarField::Internal, is then assigned to a full volScalarField (what does it do for the boundary info, for example).

[ErenC]

Originally Posted by Tobermory

nuTilda_ is a volScalarField, as you note, i.e. is a class derived from GeometricField. So, take a look in GeometricField.H (https://cpp.openfoam.org/v12/Geometr...ce.html#l00077) to see what operator() has been defined as and we find:

         //- Return a const-reference to the dimensioned internal field
         //  Useful in the formulation of source-terms for FV equations
         inline const Internal& operator()() const;

in other words, for any volScalarField a, a() returns a const reference to the internal field. As the .H comment says, this is useful for source terms (where the added boundary info in the full volScalarField has no meaning).

That explains the first part of your question, but does not fix your error. Have you tried defining dif1 as volScalarField::Internal? I can see that OF might struggle if the end result of your calculation, an volScalarField::Internal, is then assigned to a full volScalarField (what does it do for the boundary info, for example).

Originally Posted by Tobermory

nuTilda_ is a volScalarField, as you note, i.e. is a class derived from GeometricField. So, take a look in GeometricField.H (https://cpp.openfoam.org/v12/Geometr...ce.html#l00077) to see what operator() has been defined as and we find:

         //- Return a const-reference to the dimensioned internal field
         //  Useful in the formulation of source-terms for FV equations
         inline const Internal& operator()() const;

in other words, for any volScalarField a, a() returns a const reference to the internal field. As the .H comment says, this is useful for source terms (where the added boundary info in the full volScalarField has no meaning).

That explains the first part of your question, but does not fix your error. Have you tried defining dif1 as volScalarField::Internal? I can see that OF might struggle if the end result of your calculation, an volScalarField::Internal, is then assigned to a full volScalarField (what does it do for the boundary info, for example).

Thank you Tobermory! This explains a lot, but more questions are on the way. Such as using Fvm::Sp, one nuTilda is internal, other one is not. I need to use fvc:: anyway,
looking at here:
https://www.openfoam.com/documentati...pi/fvc_8H.html
I can use fvc::Sup("terms").

Defining the terms internal definetely works in the turbulenceModel itself, but when I call them on my solver with turbulence->SourceTerm(), it causes another mismatch, because I need to use these terms like SolverTerm += turbulence->SourceTerm() in my solver. Where SolverTerm is defined in the createFields and it is a volScalarField.
Since these are source terms, they should have no contribution to the boundary anyway. If I can add ::internalField to a volScalarField that would also work.

[Tobermory]

I don't think that the following is possible:

If I can add ::internalField to a volScalarField that would also work.

again - how would OF populate the combined boundary information? I haven't grasped exactly what you're aiming to do, but if it's generating a new source term for the SA model, then my suggestion is towork in terms of volScalarField::Internal and not volScalarField, and this should avoid the problem?

[ErenC]

Originally Posted by Tobermory

I don't think that the following is possible:



again - how would OF populate the combined boundary information? I haven't grasped exactly what you're aiming to do, but if it's generating a new source term for the SA model, then my suggestion is towork in terms of volScalarField::Internal and not volScalarField, and this should avoid the problem?

Hello Tobermory. I know it doesn't look possible. I was thinking maybe if I can zeroGradient everything on the boundary it might work.
Thing is I need to define these in turbulence model and use them in my solver. These terms will go into the B of the Ax=B, and since I need to substract diagonal (of the fields) from the B, it is already volScalarField and not internal. That is causing the main problem in here.

Another question for you, when I define new field (or let's say I want to call DnuTildaEff() in the original solver for convinience) in the turbulence as public (<tmp>volScalarField) what is the best way to call it in the solver? I defined terms() field in TurbulenceModel.H because it is where thermo/transport fields are defined (nu, alpha) and they can be called in the solver. But when I use turbulence->Terms(); I'm getting:

symbol lookup error: /depo/users/home/t33286/OpenFOAM/t33286-v2206/platforms/linux64GccDPInt32Opt/lib/libhisaModule.so: undefined symbol: _ZNK4Foam18ThermalDiffusivityINS_27CompressibleTurbulenceModelINS_11fluidThermoEEEE10SourceSinkEv

The thing is it is already defined in the .H files of the compressibleTurbulenceModel/ThermalDiffusivity, CompressibleTurbulenceModel.H, turbulentFluidThermoModels.H
And compressible library is already in the make file so I'm clueless right now.