[huangxianbei]

Hi,all
I want to implement dynamic Vreman model proposed by You(2006),
A dynamic global-coefficient subgrid-scale eddy-viscosity model for large-eddy simulation in complex geometries, Annual Research Briefs,2006. Most of the code is finished as follows
dynamicVreman.tar.gz

While when compiling it , an error occurs:

dynamicVreman.C:64:32: error： could not convert ‘Foam::average(const Foam::tmp<Foam::GeometricField<Type, PatchField, GeoMesh> >&) [with Type = double, PatchField = Foam::fvPatchField, GeoMesh = Foam::volMesh]()’ from ‘Foam::dimensioned<double>’ to ‘Foam::volScalarField {aka Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>}’

Any help is appreciated.

Xianbei

[huangxianbei]

cD and cI represents numerator and denominator respectively in formula 3.6

[adambarfi]

hi Huang,

AFAIK, average() will return a dimensionedScalar and you used a volScalarField instead. So, I think you should modify your code like below:

//volScalarField dynamicVreman::cD
dimensionedScalar dynamicVreman::cD
(
    const volTensorField& gradU
) const
{

     const volScalarField aafil = filter_(sqr(mag(alpha(gradU))));
     const volScalarField filaa = sqr(mag(filter_(alpha(gradU))));
     return average(aafil-filaa);
}

And the same thing for dynamicVreman::cI.

I just see your code and I didn't compile it. hope it helps.

Regards,
Mostafa

[huangxianbei]

Originally Posted by adambarfi

hi Huang,

AFAIK, average() will return a dimensionedScalar and you used a volScalarField instead. So, I think you should modify your code like below:

//volScalarField dynamicVreman::cD
dimensionedScalar dynamicVreman::cD
(
    const volTensorField& gradU
) const
{

     const volScalarField aafil = filter_(sqr(mag(alpha(gradU))));
     const volScalarField filaa = sqr(mag(filter_(alpha(gradU))));
     return average(aafil-filaa);
}

And the same thing for dynamicVreman::cI.

I just see your code and I didn't compile it. hope it helps.

Regards,
Mostafa

Hi,Mostafa:
Thank you very much for your help. Yes, the type of cD should be dimensionedScalar , while cI should be volScalarField because

return average(filter_(II*sqr(mag(D)))-filII*sqr(mag(filter_(D))))/filII

Which means, dimensionedScalar/ volScalarField should be volScalarField.
Now this error is modified, also, the SGS kinetic energy should be added. Here, I have a question about the order in the constructors(dynamicVreman.C)
if the code is written like this

// * * * * * * * * * * * * * * * * Constructors  * * * * * * * * * * * * * * //

dynamicVreman::dynamicVreman
(
    const volVectorField& U,
    const surfaceScalarField& phi,
    transportModel& transport,
    const word& turbulenceModelName,
    const word& modelName
)
:
    LESModel(typeName, U, phi, transport),
    GenEddyVisc(U, phi, transport),

    filterPtr_(LESfilter::New(U.mesh(), coeffDict())),
    filter_(filterPtr_()),
    ck_
    (
        dimensioned<scalar>::lookupOrAddToDict
        (
            "ck",
            coeffDict_,
            0.094
        )
    ),
    small1_
    (
        dimensioned<scalar>
        (
            "small1_",
             dimensionSet(0,0,-1,0,0,0,0),
             1e-10
        )
    ) 

    
{
    updateSubGridScaleFields(dev(symm(fvc::grad(U))),fvc::grad(U));

    printCoeffs();
}

There is no warning
However, if the code is written like this

// * * * * * * * * * * * * * * * * Constructors  * * * * * * * * * * * * * * //

dynamicVreman::dynamicVreman
(
    const volVectorField& U,
    const surfaceScalarField& phi,
    transportModel& transport,
    const word& turbulenceModelName,
    const word& modelName
)
:
    LESModel(typeName, U, phi, transport),
    GenEddyVisc(U, phi, transport),

    
    ck_
    (
        dimensioned<scalar>::lookupOrAddToDict
        (
            "ck",
            coeffDict_,
            0.094
        )
    ),
    small1_
    (
        dimensioned<scalar>
        (
            "small1_",
             dimensionSet(0,0,-1,0,0,0,0),
             1e-10
        )
    ),
filterPtr_(LESfilter::New(U.mesh(), coeffDict())),
    filter_(filterPtr_()) 

    
{
    updateSubGridScaleFields(dev(symm(fvc::grad(U))),fvc::grad(U));

    printCoeffs();
}

It says

dynamicVreman.H:111:27: warning： ‘Foam::incompressible::LESModels::dynamicVreman::small1_’will [-Wreorder]
dynamicVreman.H:108:28: warning：   ‘Foam::autoPtr<Foam::LESfilter> Foam::incompressible::LESModels::dynamicVreman::filterPtr_’ [-Wreorder]
dynamicVreman.C:83:1: warning：  initialized here after initialization [-Wreorder]

Why?

Here is the non-warning version
dynamicVreman.tar.gz


Xianbei

[adambarfi]

yeah, you're right about cI, my bad!
I haven't seen this warning till now, but I think it's back to the .H file. you defined:

class dynamicVreman
:
    public GenEddyVisc
{
    // Private data



        autoPtr<LESfilter> filterPtr_;
        LESfilter& filter_;
        dimensionedScalar ck_;
        dimensionedScalar small1_;
.
.
.

So I think you should keep the order in .C file, too.
Sorry, what am I saying is just come from the experiences I got from modifying a LES model and there is no conception behind it!! I'm not a really openFOAM expert.

Regards,
Mostafa

[huangxianbei]

Originally Posted by adambarfi

yeah, you're right about cI, my bad!
I haven't seen this warning till now, but I think it's back to the .H file. you defined:

class dynamicVreman
:
    public GenEddyVisc
{
    // Private data



        autoPtr<LESfilter> filterPtr_;
        LESfilter& filter_;
        dimensionedScalar ck_;
        dimensionedScalar small1_;
.
.
.

So I think you should keep the order in .C file, too.
Sorry, what am I saying is just come from the experiences I got from modifying a LES model and there is no conception behind it!! I'm not a really openFOAM expert.

Regards,
Mostafa

Thank you very much, that's the reason!

[huangxianbei]

Originally Posted by adambarfi

Regards,
Mostafa

Hi, Mostafa:
Problem again.Here is the new version
dynamicVreman-modify.tar.gz
, I corrected a few errors in the formulations.

I test it in a case I have already successfully performed using Smagorinsky, however, when I use the newly implemented model, error occurs:

--> FOAM FATAL ERROR: 
[0] temporary deallocated
[0] 
[0]     From function const T& Foam::tmp<T>::operator()() const
[0]     in file /home/huangxianbei/OpenFOAM/OpenFOAM-2.1.1/src/OpenFOAM/lnInclude/tmpI.H at line 187.
[0] 
FOAM parallel run aborting
[0] 
[1] --> FOAM FATAL ERROR: 
[1] temporary deallocated
[1] 
[1]     From function const T& Foam::tmp<T>::operator()() const
[1]     in file /home/huangxianbei/OpenFOAM/OpenFOAM-2.1.1/src/OpenFOAM/lnInclude/tmpI.H at line 187.
[1] 
FOAM parallel run aborting
[1] 
[0] #0  Foam::error::printStack(Foam::Ostream&)[1] #0  Foam::error::printStack(Foam::Ostream&)[2] 
[2] 
[2] --> FOAM FATAL ERROR: 
[2] temporary deallocated
[2] 
[2]     From function const T& Foam::tmp<T>::operator()() const
[2]     in file /home/huangxianbei/OpenFOAM/OpenFOAM-2.1.1/src/OpenFOAM/lnInclude/tmpI.H at line 187.
[2] 
FOAM parallel run aborting
[2] 
[2] #0  Foam::error::printStack(Foam::Ostream&)[3] 
[3] 
[3] --> FOAM FATAL ERROR: 
[3] temporary deallocated
[3] 
[3]     From function const T& Foam::tmp<T>::operator()() const
[3]     in file /home/huangxianbei/OpenFOAM/OpenFOAM-2.1.1/src/OpenFOAM/lnInclude/tmpI.H at line 187.
[3] 
FOAM parallel run aborting
[3]

Do you have any idea about that?

Xianbei

[huangxianbei]

Originally Posted by adambarfi

Regards,
Mostafa

Hi, I searched the forum and find that has something to do with tmp, so when I delete all the tmp used in the code , the solution can run without any error, also, I find the speed of the calculation is not affected, so I think it's no need to use tmp, however, I still want to know if it's better when tmp used or is it necessary? From my code, can you do some explain on how the error occurs? I have no idea about how

Xianbei

[adambarfi]

hi Huang,

I checked your code and I found nothing!
I've been challenged by this error in two cases:

1- when I was modifying the momentum eqn I'd forgot to write UEqn() instead of UEqn.
2- when I was using cyclic bc for inlet and outlet patches, actually my inlet consisted of two patch, and the same for the outlet. When I combined the two patches into one patch the the error was solved.

try to run your case without parallel mode and see if there's this error again.

Regards,
Mostafa

P.S
why did you use T(gradU) in your .H file?

[adambarfi]

Originally Posted by huangxianbei

Hi, I searched the forum and find that has something to do with tmp, so when I delete all the tmp used in the code , the solution can run without any error, also, I find the speed of the calculation is not affected, so I think it's no need to use tmp, however, I still want to know if it's better when tmp used or is it necessary? From my code, can you do some explain on how the error occurs? I have no idea about how

Xianbei

according to wiki:

It isn't needed at all, but it reduces the effort and increases the efficiency of your program.
When C++ returns a local object, it copies the object, returns the copy, and deletes the original. This behaviour is safe memory management; however, if you are dealing with large objects (such as a 10 million element geometric tensor field), it can be a costly process.

[huangxianbei]

Originally Posted by adambarfi

hi Huang,

I checked your code and I found nothing!
I've been challenged by this error in two cases:

1- when I was modifying the momentum eqn I'd forgot to write UEqn() instead of UEqn.
2- when I was using cyclic bc for inlet and outlet patches, actually my inlet consisted of two patch, and the same for the outlet. When I combined the two patches into one patch the the error was solved.

try to run your case without parallel mode and see if there's this error again.

Regards,
Mostafa

P.S
why did you use T(gradU) in your .H file?

Hi, Mostafa:
Actually the above error occurs when using mpirun.
As for T(gradU), the formulation is d(alpha)ij=duj/dxi, so the T is needed.

Xianbei

[huangxianbei]

Originally Posted by adambarfi

according to wiki:

It isn't needed at all, but it reduces the effort and increases the efficiency of your program.
When C++ returns a local object, it copies the object, returns the copy, and deletes the original. This behaviour is safe memory management; however, if you are dealing with large objects (such as a 10 million element geometric tensor field), it can be a costly process.

Thank you very much. So that depends on how much cells in the computation domain. It's hard to handle this kind of usage, because it's hard to figure out what's wrong in the code if this error occurs.

Some more try:
I start to think the property using 'filter_' operation in the .H file when using tmp. So I add tmp in alphaij and Bbetaij , filapha and filBbeta without tmp, the calculation can still run without error. Thus the key point is that the 'filter_' operation may be not proper in the .H file when tmp is used.

Another point is that if a variant contains filter_, it's element can't be tmp either(const tmp<volTensorField>& gradU can't be used)

As you said before, the tmp can improve the efficiency, then I tried to use tmp more. I was thinking putting filalpha and filBbeta in the .C file, however, as cD and cI both contains the two variants, it may take more time to calculate them twice, hence, I give up this idea.

PS: your avatar is so cute

[huangxianbei]

Originally Posted by adambarfi

according to wiki:

It isn't needed at all, but it reduces the effort and increases the efficiency of your program.
When C++ returns a local object, it copies the object, returns the copy, and deletes the original. This behaviour is safe memory management; however, if you are dealing with large objects (such as a 10 million element geometric tensor field), it can be a costly process.

Hi,Mostafa:Sorry to botheryou again. The model works well now, and I want to output the cI to see how it varies as time. But I'm familiar to the output of a variant, could you give me some hints?

Thank you

Xianbei

[PonchO]

Hello Huang,

actually i want to start implementing the Vreman-SGS model by myself. Then i realized, that you have done it already. It would be glad, if you can share your final version.

Best regards,

Christoph