View Issue Details

IDProjectCategoryView StatusLast Update
0001953OpenFOAM[All Projects] Bugpublic2016-01-02 18:54
ReporteralundilongAssigned Tohenry 
PriorityhighSeveritymajorReproducibilityalways
Status resolvedResolutionfixed 
PlatformGNU/LinuxOSUbuntuOS Version14.04
Product Version 
Fixed in Version 
Summary0001953: patchInternalField() shows wrong value
DescriptionpatchInternalField() shows wrong values
Steps To ReproduceI 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.
TagsNo tags attached.

Activities

alundilong

2015-12-16 04:18

reporter  

BugReport.tar.gz (9,305 bytes)

alundilong

2015-12-21 16:25

reporter   ~0005786

hello,

it seems only couple of values are not consistent.

Best.,

wyldckat

2016-01-02 18:30

updater   ~0005791

@alundilong:

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.

henry

2016-01-02 18:54

manager   ~0005792

@Bruno: your assessment of the problem in alundilong's code is correct.

Issue History

Date Modified Username Field Change
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