CFD Online Discussion Forums

CFD Online Discussion Forums (http://www.cfd-online.com/Forums/)
-   OpenFOAM (http://www.cfd-online.com/Forums/openfoam/)
-   -   Varying U BC not working for settlingFoam (http://www.cfd-online.com/Forums/openfoam/75266-varying-u-bc-not-working-settlingfoam.html)

lfbarcelo April 20, 2010 15:36

Varying U BC not working for settlingFoam
 
Hi;

timeVaryingUniformFixedValue does not seem to work for settlingFoam! I'm triyng to use it in order to get a variable inlet velocity in the dahl case, following alberto's instructions (http://albertopassalacqua.com/?p=69), and I get the next error message:

Starting time loop

Time = 0.1

Courant Number mean: 0.0163852 max: 0.0883237
diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0
#0 Foam::error::printStack(Foam::Ostream&) in "/opt/OpenFOAM/OpenFOAM-1.6.x/lib/linux64GccDPOpt/libOpenFOAM.so"
#1 Foam::sigSegv::sigSegvHandler(int) in "/opt/OpenFOAM/OpenFOAM-1.6.x/lib/linux64GccDPOpt/libOpenFOAM.so"
#2 ?? in "/lib/libc.so.6"
#3 Foam::interpolationTable<Foam::Vector<double> >::operator()(double) const in "/opt/OpenFOAM/OpenFOAM-1.6.x/lib/linux64GccDPOpt/libfiniteVolume.so"
#4 Foam::timeVaryingUniformFixedValueFvPatchField<Foa m::Vector<double> >::updateCoeffs() in "/opt/OpenFOAM/OpenFOAM-1.6.x/lib/linux64GccDPOpt/libfiniteVolume.so"
#5 Foam::fvPatchField<Foam::Vector<double> >::evaluate(Foam::Pstream::commsTypes) in "/opt/OpenFOAM/OpenFOAM-1.6.x/applications/bin/linux64GccDPOpt/settlingFoam"
#6 Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh>::GeometricBoundaryField::evaluate() in "/opt/OpenFOAM/OpenFOAM-1.6.x/applications/bin/linux64GccDPOpt/settlingFoam"
#7 main in "/opt/OpenFOAM/OpenFOAM-1.6.x/applications/bin/linux64GccDPOpt/settlingFoam"
#8 __libc_start_main in "/lib/libc.so.6"
#9 _start at /build/buildd/eglibc-2.10.1/csu/../sysdeps/x86_64/elf/start.S:116
Fallo de segmentación

I tried the same procedure for the simpleFoam case, pitzDaily, and it worked perfectly, I use OF-1.6.x

Any Ideas?

alberto April 20, 2010 17:52

Are you using the same file to define the BC in both the cases?

P.S. An unsteady BC in a steady solver (simpleFoam) does not seem correct :-)

Best,

lfbarcelo April 20, 2010 18:28

Hi, thanks for the reply!

I am using the same file. Iīve tried also other settlingFoam cases and they didnīt work either.
The cavity case (icoFoam) worked fine as well with the same file.

There really seems to be some kind of bug in settlingFoam.

pitzDaily never getīs to the steady solution. Velocity values show what I expected in the patch where the variable BC was setled, this means that te timeVaryingUniformFixedValue works!. But the case itself gives out crappy preassure results. I was just testing the variable velocity condition.

alberto April 20, 2010 21:26

Quote:

Originally Posted by lfbarcelo (Post 255529)
Hi, thanks for the reply!

I am using the same file. Iīve tried also other settlingFoam cases and they didnīt work either.
The cavity case (icoFoam) worked fine as well with the same file.

There really seems to be some kind of bug in settlingFoam.

pitzDaily never getīs to the steady solution. Velocity values show what I expected in the patch where the variable BC was setled, this means that te timeVaryingUniformFixedValue works!. But the case itself gives out crappy preassure results. I was just testing the variable velocity condition.

You are right. There is a problem in the code. If you check createFields.H, you can see Vdj inherits the boundaryField from U, but clearly no interpolation table is available for Vdj, so the code fails when you call

Vdj.correctBoundaryConditions();

in calcVdj.H.

As a temporary fix, waiting for a reply from the developers (I'll open a bug report), considering Vdj is calculated explicitly, you can replace the declaration of Vdj with

Code:

    volVectorField Vdj
    (
        IOobject
        (
            "Vdj",
            runTime.timeName(),
            mesh,
            IOobject::NO_READ,
            IOobject::AUTO_WRITE
        ),
        mesh,
        dimensionedVector("0.0", U.dimensions(), vector::zero)
        //,U.boundaryField().types()
    );

The only difference is that the comma and the last line were commented, so to avoid the inheritance of the boundaryField from U.

I hope this helps.

Best,

alberto April 20, 2010 21:33

Bug reported here: http://www.cfd-online.com/Forums/ope...tml#post255539

lfbarcelo April 21, 2010 13:26

Excellent!! the fix you suggested worked perfectly. Thank you!

The bug also exists for alpha BC, since Alpha inherits the boundaryField from alpha.
I tried a similar fix for this BC.

Code:

volScalarField Alpha
    (
        IOobject
        (
            "Alpha",
            runTime.timeName(),
            mesh,
            IOobject::NO_READ,
            IOobject::AUTO_WRITE
        ),
        alpha*rhod/rho
        //,alpha.boundaryField().types()
    );

Where I commented the comma and the last line.

But I get the next error message when trying to run the case:

Quote:

Starting time loop

Time = 0.1

Courant Number mean: 0.00597056 max: 0.0488136
diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0
DILUPBiCG: Solving for Ux, Initial residual = 1, Final residual = 3.67271e-10, No Iterations 3
DILUPBiCG: Solving for Uy, Initial residual = 1, Final residual = 9.12603e-10, No Iterations 3


--> FOAM FATAL ERROR:

gradientInternalCoeffs cannot be called for a calculatedFvPatchField
on patch lowerWall of field Alpha in file "/home/pablo/OpenFOAM/pablo-1.6.x/run/V_1/0/Alpha"
You are probably trying to solve for a field with a default boundary condition.

From function calculatedFvPatchField<Type>::gradientInternalCoef fs() const
in file fields/fvPatchFields/basic/calculated/calculatedFvPatchField.C at line 187.

FOAM exiting
How can i get varying alpha to work?

I've tried creating the Alpha BC in the 0 folder of the case, and reading that boundaryField instead of inheriting it from alpha:

Code:

volScalarField Alpha
    (
        IOobject
        (
            "Alpha",
            runTime.timeName(),
            mesh,
            IOobject::AUTO_READ,
            IOobject::AUTO_WRITE
        ),
        alpha*rhod/rho
        //,alpha.boundaryField().types()
    );

I changed NO_READ for AUTO_READ, but i keep getting the same error message.

Any ideas?

alberto April 21, 2010 14:02

Please add this to the bug report, so that developers can see it.

Best,

lfbarcelo April 21, 2010 14:29

Ok, I added it to the bug report. Thank you for your answer. :-)

Best,

lfbarcelo April 21, 2010 16:45

I found a "messy" solution for the alpha problem.

I've tried creating the Alpha BC in the 0 folder of the case, and reading that boundaryField instead of inheriting it from alpha:

Code:
volScalarField Alpha
(
IOobject
(
"Alpha",
runTime.timeName(),
mesh,
IOobject::MUST_READ,
IOobject::AUTO_WRITE
),
mesh
// alpha*rhod/rho
//,alpha.boundaryField().types()
);
I changed NO_READ for MUST_READ, and commented the line where it calculates Alpha for the first step. I also added the word mesh.

It seems to work fine, but I had to manually calculate and create the Alpha bondaryField File in the 0 folder, and apply the timeVaryingUniformFixedValue to this BC instead of applying it to alpha.

P.S.: Note the difference between alpha and Alpha. Alpha= alpha*rhod/rho

alberto April 21, 2010 17:02

That's OK. But indeed it's messy :-)

The boundaryField inheritance makes the fields automatically consistent but introduces the problem with the interpolationTable.

To be safe, compare the results of the tutorial with and without the changes.

Best,


All times are GMT -4. The time now is 13:24.