View Issue Details

IDProjectCategoryView StatusLast Update
0001827OpenFOAMBugpublic2015-09-02 14:38
Reporteruser1080Assigned Tohenry  
PriorityhighSeveritycrashReproducibilityalways
Status resolvedResolutionfixed 
PlatformGNU/LinuxOSUbuntuOS Version14.04
Summary0001827: Simulation crashed when uniformFixedGradient is used in combination with tableFile while using scalarTransportFoam
DescriptionHello,

I'm using ScalarTransportFoam to simulate transient thermal loads. So I tried to use uniformFixedGradient along with tablefile and the simulation crashes.

The same works with uniformFixedValue.

So I think this is an error. The stack trace is not at all helpful

#1 Foam::error::printStack(Foam::Ostream&) at ??:?
#2 Foam::sigFpe::sigHandler(int) at ??:?
#3 ? in "/lib/x86_64-linux-gnu/libc.so.6"
#4 double Foam::sumProd<double>(Foam::UList<double> const&, Foam::UList<double> const&) at ??:?
#5 Foam::PBiCG::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const at ??:?
#6 Foam::fvMatrix<double>::solveSegregated(Foam::dictionary const&) at ??:?
#7 Foam::fvMatrix<double>::solve(Foam::dictionary const&) at ??:?
#8 ? at ??:?
#9 ? at ??:?
#10 __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#11 ? at ??:?
./run.sh: line 4: 22378 Floating point exception(core dumped) scalarTransportFoam
Steps To ReproduceDownload the case from github -------> https://github.com/pruthvi1991/OpenFOAM-bug-reporting/tree/master/pitzDaily_noflow

Change the destination of the file in 0/T to match your local directory.

Clean the case by executing cleanCase.sh. Then run the case by run.sh
Additional InformationI have tried using the inline table and that doesn't work either.

type uniformFixedGradient;
        uniformGradient table
        (
            (0.0 500.0)
            (1.0 500.0)
             ....
        );
TagsNo tags attached.

Activities

wyldckat

2015-08-13 14:54

updater   ~0005228

I'm currently looking into this. The problem seems to be larger than the use of "table". If we use this:

    inlet
    {
        type uniformFixedGradient;
        uniformGradient constant 500.0;
    }

it also crashes.


If we use:

    inlet
    {
        type fixedGradient;
        gradient 500;
    }

there is absolutely no problem.

wyldckat

2015-08-13 16:48

updater   ~0005231

Diagnosis complete and solution found. The bug fix is this:

    diff --git a/src/finiteVolume/fields/fvPatchFields/derived/uniformFixedGradient/uniformFixedGradientFvPatchField.C b/src/finiteVolume/fields/fvPatchFields/der
    index 877e413..e102f79 100644
    --- a/src/finiteVolume/fields/fvPatchFields/derived/uniformFixedGradient/uniformFixedGradientFvPatchField.C
    +++ b/src/finiteVolume/fields/fvPatchFields/derived/uniformFixedGradient/uniformFixedGradientFvPatchField.C
    @@ -95,6 +95,8 @@ uniformFixedGradientFvPatchField<Type>::uniformFixedGradientFvPatchField
            const scalar t = this->db().time().timeOutputValue();
            this->gradient() = uniformGradient_->value(t);
        }
    +
    + fixedGradientFvPatchField<Type>::evaluate();
    }

    

This fix isn't needed in "fixedFluxPressureFvPatchScalarField", simply because the "value" (i.e. the call to "operator=") for this class is done directly in the constructor.

I've got a feeling that this class isn't the only one that needs this call.


Note: The file "uniformFixedGradientFvPatchFieldsFwd.H" needs to be either fixed or removed, because it's using "makePatchTypeFieldTypedefs" incorrectly.

wyldckat

2015-08-13 17:05

updater   ~0005232

After a bit of grep+edit, I did not find any other classes that derive directly from "fixedGradientFvPatchField" that needed a similar fix.

henry

2015-08-13 19:12

manager   ~0005235

Thanks for analysing this Bruno, your proposal is quite correct. I have also fixed uniformFixedGradientFvPatchFieldsFwd.H

Resolved by commit e7e54e156ce92b90e79acafe735db5ec13e97772 in OpenFOAM-2.4.x

Issue History

Date Modified Username Field Change
2015-08-12 23:45 user1080 New Issue
2015-08-13 14:54 wyldckat Note Added: 0005228
2015-08-13 16:48 wyldckat Note Added: 0005231
2015-08-13 17:05 wyldckat Note Added: 0005232
2015-08-13 17:06 wyldckat Assigned To => henry
2015-08-13 17:06 wyldckat Status new => assigned
2015-08-13 19:12 henry Note Added: 0005235
2015-08-13 19:12 henry Status assigned => resolved
2015-08-13 19:12 henry Resolution open => fixed