View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001953||OpenFOAM||[All Projects] Bug||public||2015-12-16 04:18||2016-01-02 18:54|
|Fixed in Version|
|Summary||0001953: patchInternalField() shows wrong value|
|Description||patchInternalField() shows wrong values|
|Steps To Reproduce||I have attached a test code and test case. |
In this case, it shows right values which are given by internalField()[celli] and wrong ones which are returned by patchInternalField()[facei].
It is unknown why this is happening.
|Tags||No tags attached.|
BugReport.tar.gz (9,305 bytes)
it seems only couple of values are not consistent.
If you check the description for the method "patchInternalField()": https://github.com/OpenFOAM/OpenFOAM-3.0.x/blob/version-3.0.0/src/finiteVolume/fields/fvPatchFields/fvPatchField/fvPatchField.H#L405
//- Return internal field next to patch as patch field
virtual tmp<Field<Type> > patchInternalField() const;
It returns a "tmp" object, which means that you need to use the conventional "holding and unpacking" strategy that is used throughout OpenFOAM's internal code. For example, have a look at the wall treatment classes.
Anyway, the problem is that you have this:
const scalarField & pstateIntField = pstateField.patchInternalField();
which is an illegal storage operation, because it's pointing into an object that is soon destroyed.
The correct use is this: (if I'm not mistaken, since I didn't double-check one of OpenFOAM's examples)
const tmp<scalarField> tpstateIntField = pstateField.patchInternalField();
const scalarField &pstateIntField = tpstateIntField();
@Henry: I haven't checked yet how the class "tmp" handles the "operator=" method in these situations.
||@Bruno: your assessment of the problem in alundilong's code is correct.|
|2015-12-16 04:18||alundilong||New Issue|
|2015-12-16 04:18||alundilong||File Added: BugReport.tar.gz|
|2015-12-21 16:25||alundilong||Note Added: 0005786|
|2016-01-02 18:30||wyldckat||Note Added: 0005791|
|2016-01-02 18:54||henry||Note Added: 0005792|
|2016-01-02 18:54||henry||Status||new => resolved|
|2016-01-02 18:54||henry||Resolution||open => fixed|
|2016-01-02 18:54||henry||Assigned To||=> henry|