#304 bugs of buoyantBoussinesqPisoFoam or fixedFluxPressure in foam-extend 3.1 and 3.2

[samech]

Dear foamers,
I have found some bugs in foam-extend3.1 and foam-extend3.2
My test case is /heatTransfer/buoyantBoussinesqPisoFoam/hotRoom

[1]bugs in foam-extend 3.1
I changed the pressure boundary from buoyantPressure to fixedFluxPressure,

floor
{
type fixedFluxPressure;
rho rhok;
value uniform 0;
adjoint false;
}
ceiling
{
type fixedFluxPressure;
rho rhok;
value uniform 0;
adjoint false;
}
fixedWalls
{
type fixedFluxPressure;
rho rhok;
value uniform 0;
adjoint false;
}
then foam-extend3.1 occurs some errors:
Time = 1

Courant Number mean: 0 max: 0 velocity magnitude: 0
DILUPBiCG: Solving for Ux, Initial residual = 0, Final residual = 0, No Iterations 0
DILUPBiCG: Solving for Uy, Initial residual = 1, Final residual = 8.12238e-06, No Iterations 4
DILUPBiCG: Solving for Uz, Initial residual = 0, Final residual = 0, No Iterations 0
DILUPBiCG: Solving for T, Initial residual = 1, Final residual = 2.56071e-06, No Iterations 6

--> FOAM FATAL ERROR:

lookup of (1|A(U)) from objectRegistry region0 successful
but it is not a volScalarField, it is a surfaceScalarField

From function objectRegistry::lookupObject<Type>(const word&) const
in file /home/Aaron/foam/foam-extend-3.1/src/foam/lnInclude/objectRegistryTemplates.C at line 120.

FOAM aborting

[2]bugs in foam-extend3.2
then, I run the above case in foam-extend3.2 use one cpu thread, I found it can run!!! and with out "lookup of (1|A(U)) from objectRegistry region0 successful, but it is not a volScalarField, it is a surfaceScalarField" bugs.

However, when I use mpirun, it occurs bugs:

Running setHotRoom on /media/Aaron/disk/tutorials_fe31/heatTransfer/buoyantBoussinesqPisoFoam/hotRoom_test
[0] [1]
[1]
[1] --> FOAM FATAL IO ERROR:
[1] wrong token type - expected word found on line 28 the punctuation token '('
[1]
[1] file: /media/Aaron/disk/tutorials_fe31/heatTransfer/buoyantBoussinesqPisoFoam/hotRoom_test/processor1/0/p::boundaryField::floor::rAU at line 28.
[1]
[1] From function operator>>(Istream&, word&)
[1] in file primitives/strings/word/wordIO.C at line 76.
[1]
FOAM parallel run exiting

[0]
[0] --> FOAM FATAL IO ERROR:
[0] wrong token type - expected word found on line 28 the punctuation token '('
[0]
[0] file: /media/Aaron/disk/tutorials_fe31/heatTransfer/buoyantBoussinesqPisoFoam/hotRoom_test/processor0/0/p::boundaryField::floor::rAU at line 28.
[0]
[0] From function operator>>(Istream&, word&)
[0] in file primitives/strings/word/wordIO.C at line 76.
[0] [1]

FOAM parallel run exiting
[0]

---

MPI_ABORT was invoked on rank 1 in communicator MPI_COMM_WORLD
with errorcode 1.

Can someone help me solve this bug?

Best Regrads,
Aaron

[Pascal Beckstein]

Hi Aaron,

this is not really a bug. It think it is rather a problem of inconsistency. The fixedFluxPressure boundary condition needs the field 1.0/UEqn.A() in order to derive a pressure gradient value based on the the flux represented by the UEqn.

The field 1.0/UEqn.A() is however defined in an extremely inconsistent way in OpenFOAM and foam-extend. Often it is simply referred to as rAU, sometimes as rUA, 1|A(U) or (1|A(U)). Authors have their own preferences which may lead to some confusion if you compare different solvers. Things get even worse, as the surface interpolated pendant is being used for the pEqn, too. Here you will find rAUf, rUAf but also 1|A(U) or (1|A(U)).

Furthermore the implementation of the fixedFluxPressure boundary condition is completely different in vanilla OpenFOAM 2.2.x, 2.3.x, 3.0.x and foam-extend.

To solve your problem, you have to look into the definition of the fixedFluxPressure patch field of foam-extend 3.2. Focus on the dictionary constructor of the fixedFluxPressureFvPatchScalarField starting from line 49:

fixedFluxPressureFvPatchScalarField.C.

It reads all the necessary field names from the boundaryField section given in your p field:

    UName_(dict.lookupOrDefault<word>("U", "U")),
    phiName_(dict.lookupOrDefault<word>("phi", "phi")),
    rhoName_(dict.lookupOrDefault<word>("rho", "rho")),
    rAUName_(dict.lookupOrDefault<word>("rAU", "(1|A(" + UName_ + "))")),
    adjoint_(dict.lookupOrDefault<Switch>("adjoint", false))

Per default it uses the rAUName "1|A(U)" if you do not specify anything else.

Now have a look at the pEqn.H of your desired solver:

pEqn.H.

As you might recognize, the buoyantBoussinesqPisoFoam uses the name "rUA" for the cell based 1.0/UEqn.A() and "(1|A(U))" for the interpolated one:

    volScalarField rUA("rUA", 1.0/UEqn.A());
    surfaceScalarField rUAf("(1|A(U))", fvc::interpolate(rUA));

The problem here is that during the coefficient update of the fixedFluxPressureFvPatchScalarField:

fixedFluxPressureFvPatchScalarField.C,

the database is first queried for "(1|A(U))" as volScalarField:

    if (this->db().objectRegistry::foundObject<volScalarField>(rAUName_))
    {
        rAp = lookupPatchField<volScalarField, scalar>(rAUName_);
    }
    else if
    (
        this->db().objectRegistry::foundObject<surfaceScalarField>(rAUName_)
    )
    {
        rAp = lookupPatchField<surfaceScalarField, scalar>(rAUName_);
    }
    else
    {
        FatalErrorIn
        (
            "void fixedFluxPressureFvPatchScalarField::updateCoeffs()"
        )   << " Field " << rAUName_ << " not found for patch "
            << patch().name() << " and field "
            << dimensionedInternalField().name()
            << abort(FatalError);
    }

Unfortunately, the default name "(1|A(U))" is already registered as the interpolated field and this is probably what the error massage is about.

This could for sure be improved in the implementation of the fixedFluxPressureFvPatchScalarField, the objectRegistry or/and by means of a more consistent naming of 1.0/UEqn.A() throughout the whole foam-extend code, if I'm not completely wrong. But in order to get your case running it might be enough to simply specify the "correct" name of 1.0/UEqn.A() for the buoyantBoussinesqPisoFoam solver.

Please change your boundary conditions of p to something like

floor
{
    type    fixedFluxPressure;
    rho     rhok;
    rAU     rUA;
}
ceiling
{
    type    fixedFluxPressure;
    rho     rhok;
    rAU     rUA;
}
fixedWalls
{
    type    fixedFluxPressure;
    rho     rhok;
    rAU     rUA;
}

and make sure you decompose your case afterwards or change each processor folder separately. The adjoint switch is turned off by default. Just drop it.

Hopefully, this will solve it. Please let me know if this does not work!

Best,
Pascal

[samech]

Dear Pascal,
Thanks for your detailed explanation, it really helps me a lot
After add "rAU rUA; " the solver works fine.

Best Regrads,
Aaron

[Thomas N.]

Dear Pascal,
thanks for your detailed explanation. I am using foam-extend 4.0 and this inconsistency is still there. However, after reading your post, one should add something like

walls
{
    type    fixedFluxPressure;
    rho     rho;
    rAU     rAU;
}

because it is defined as rAU in the solver and (1|A(U)) in the fixedFluxPressure.

The problem comes later. So, I am decomposing the case into a number of processors and the solver (for example interFoam) runs fine. When it is the time to reconstruct the case, openfoam still searches for inconsistent variables. So, here is the error

--> FOAM FATAL IO ERROR: 
wrong token type - expected word found on line 68314 the punctuation token '('

file: /home/thomas/Desktop/test3/processor0/0.0002/pd::boundaryField::main_inlet::rAU at line 68314.

    From function operator>>(Istream&, word&)
    in file primitives/strings/word/wordIO.C at line 76.

FOAM exiting

Any ideas of how to solve this problem?

Thanks in advance!

Thomas N.

[Thomas N.]

Hi,
I has some progress with this problem. Thus, in parallel computing the field rAU is saved as

    walls
    {
        type            fixedFluxPressure;
        rAU             (1|A(U));
        gradient        nonuniform List<scalar> 

and the reason that it cannot reconstruct it is this. When I am changing the (1|A(U)) to rAU is reconstructing normal. So i believe if I change the way that is being saved, problem is solved. Any ideas how can I do this by changing the boundary conditions?

Thanks in advance!

Thomas N.

[Thomas N.]

Hi,
so like I said the (1|A(U)) should be replaced with rAU and I couldn't fix this from the fixedFluxPressure. However, I fixed it by creating a python script that will search all the (1|A(U)) and replace them with rAU. Here is how it looks like:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33

#!/usr/bin/env python3 import fileinput import fnmatch import os import re root = os.getcwd() RE = re.compile(r"\s+rAU\s+.*;$") def getfiles(root): for path, subdirs, files in os.walk(root): for file in files: yield path, file for path, file in getfiles(root): if "processor" in path and file == "pd": filename = path + "/" + file print("Working on file", filename) with open(filename) as f: output = f.read() output.replace("(1|A(U))", "rAU") with open(filename, "w") as f: f.write(output) # for line in file: # if re.match(RE, line): # print(line) # print(line.replace(text_to_search, replacement_text), end='')

I hope it helps.

Thomas N.