[maka]

Hi,

I following message (here) an error was reported that is suspected to be a bug. Thanks.
Best regards,
Maka.

[henry]

I do not believe there is a bug in tmp but care and understanding is needed to avoid premature deallocation.

H

[maka]

I do not think the bug is in tmp. The bug seems to be in the declaration of: correct(..) memeber function of LES models for example:

void Smagorinsky::correct(const tmp<voltensorfield>& gradU).

In the above discussion it was mentioned that one should not use a reference to tmp since it is subject to be deallocated.

I'm not an expert of using tmp but adding the following three lines at the start of correct() implementation will cause the code to crash:

Info <<"1" << average(mag(gradU)) << endl;
Info <<"2" << average(mag(gradU)) << endl;
Info <<"3" << average(mag(gradU)) << endl;

You may refer to the above link for details. Thanks for your response.

Best regards,
Maka.

[henry]

void Smagorinsky::correct(const tmp<voltensorfield>& gradU)
is correct.

Info <<"1" << average(mag(gradU)) << endl;
Info <<"2" << average(mag(gradU)) << endl;
Info <<"3" << average(mag(gradU)) << endl;

should be

Info <<"1" << average(mag(gradU())) << endl;
Info <<"2" << average(mag(gradU())) << endl;
Info <<"3" << average(mag(gradU())) << endl;

to avoid premature de-allocation of the tmp-field.
Alternatively you can create a local reference:

const volTensorField& gradU_ = gradU();

Info <<"1" << average(mag(gradU_)) << endl;
Info <<"2" << average(mag(gradU_)) << endl;
Info <<"3" << average(mag(gradU_)) << endl;

or perhaps

void Smagorinsky::correct(const tmp<voltensorfield>& tgradU)
{
.
.
.
const volTensorField& gradU = tgradU();

Info <<"1" << average(mag(gradU)) << endl;
Info <<"2" << average(mag(gradU)) << endl;
Info <<"3" << average(mag(gradU)) << endl;
.
.
.
}

H

[maka]

Thanks Henry for your comments. One small remark is that in the standard release gradU is used without the gradU(). Perhaps any of the above modifications to all SGS models in the future release will help new users to avoid such problem in the future. Many thanks for you help.

Best regards,
Maka.

[henry]

The use of a tmp<voltensorfield>& rather than a volTensorField& is to allow the recipient code to clear or reuse the storage of the gradU field which can give a substantial gain in memory efficiency. The choice of a gradU rather than a gradU() argument in the SGS models is deliberate and facilitates this clear or reuse. If you are making changes to these models and want to stop or delay this storage clear or reuse please use one of the methods I suggested above.

H

[maka]

Many thanks for the explanation.
Best regards,
Maka.