View Issue Details

IDProjectCategoryView StatusLast Update
0001972OpenFOAMBugpublic2016-01-18 18:33
Reporterprojectionist Assigned Tohenry  
Status resolvedResolutionfixed 
PlatformGNU/LinuxOSUbuntuOS Version15.04
Product Versiondev 
Summary0001972: scalarTransport function object not usable with Eulerian multi-phase solvers
DescriptionUsing the scalarTransport function object causes a fatal error, since OpenFOAM tries to look up the field U, which doesn't exist.
Steps To ReproduceHere we see the constructor of scalarTransport:

    const word& name,
    const objectRegistry& obr,
    const dictionary& dict,
    const bool loadFromFiles
    mesh_(refCast<const fvMesh>(obr)),
        dimensionedScalar("zero", dimless, 0.0),

    if (resetOnStartUp_)
        T_ == dimensionedScalar("zero", dimless, 0.0);

We see from the initializer, that fields like UName_ are initialized with a default value ("U"). Only in the body of the constructor, the read() method is called, which looks up the proper names.

However, the method boundaryTypes() is called in the initializer list, when constructing the T_ field. Thus, at the time of the call to boundaryType(), UName_ still has its initial value "U".

Foam::wordList Foam::scalarTransport::boundaryTypes() const
    const volVectorField& U = mesh_.lookupObject<volVectorField>(UName_);

    /* code omitted */

This leads to problems, when trying to use this function object with say twoPhaseEulerFoam, since in this case there is no field named U.
Additional InformationI propose to pass the proper name to the method boundaryTypes:


// method signature
wordList boundaryTypes(word) const;


// the call in the constructor of the T_ field
boundaryTypes(dict.lookupOrDefault<word>("UName", "U"))

// the method itself
Foam::wordList Foam::scalarTransport::boundaryTypes(word UName) const
    const volVectorField& U = mesh_.lookupObject<volVectorField>(UName);

    /* the rest is unchanged*/
TagsNo tags attached.



2016-01-15 14:50

manager   ~0005835

Thanks for the bug-report and proposed fix. I think a simpler approach is to construct UName_ with dict.lookupOrDefault<word>("UName", "U") rather than pass it as an argument to boundaryTypes. I have just pushed this fix to OpenFOAM-dev, let me know if it resolves the problem you are having.


2016-01-18 16:07

reporter   ~0005852

You resolved the issue. Thanks.

I chose to pass the UName as an argument as I was not sure, whether I could access UName_ further down the initializer list.
Today I searched the web and it told me, that members are initialized in the order as they appear in the class' definition. So I was over cautious in passing UName as argument.


2016-01-18 18:33

manager   ~0005853

Resolved in OpenFOAM-dev by commit 465452b7b9e28fa1672b9e41d01c940d8ad262a6
Resolved in OpenFOAM-3.0.x by commit 5b548639bc6e08e3025dbfdfeb4549928b3485c5

Issue History

Date Modified Username Field Change
2016-01-14 17:50 projectionist New Issue
2016-01-15 14:50 henry Note Added: 0005835
2016-01-18 16:07 projectionist Note Added: 0005852
2016-01-18 18:33 henry Note Added: 0005853
2016-01-18 18:33 henry Status new => resolved
2016-01-18 18:33 henry Resolution open => fixed
2016-01-18 18:33 henry Assigned To => henry