[petros]

Hi all,

I am writing a custom boundary condition (BC) that needs to have access to a user-defined volVectorField named Uomega.

The BC compiles without any error and the solver runs fine with a single processor. I should say that the BC is applied to a wall patch and the volVectorField is created properly in createFields.H.

However, when I try to decompose the case for a parallel run I get the following error:

--> FOAM FATAL ERROR:
    request for volVectorField Uomega from objectRegisrty region0 failed
    available objects of type volVectorField are
0()

   From const Type& Foam::objectRegistry::lookupObject(const Foam::word&, bool) const [with Type = Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh>]
   in file /home/pawan/OpenFOAM/OpenFOAM-v2006/src/OpenFOAM/lnInclude/objectRegistryTemplates.C at line 463.

FOAM aborting

The dictionary constructor of the fvPatchField is looking like this:

Foam::EvCoHFNoHNewLookUpFvPatchScalarField::
EvCoHFNoHNewLookUpFvPatchScalarField
(
    const fvPatch& p,
    const DimensionedField<scalar, volMesh>& iF,
    const dictionary& dict
)
:
    fixedValueFvPatchScalarField(p, iF),
    Lrho_(dict.get<scalar>("Lrho")),
    UomegaName_(dict.getOrDefault<word>("Uomega", "Uomega"))
{
     if (dict.found("value"))
    {
        fvPatchField<scalar>::operator=
        (
            Field<scalar>("value", dict, p.size())
        );
    }
    else
    {
       updateCoeffs();
    }
}

The actual code where the error comes from is in updateCoeffs() and reading like this:

const vectorField& Uomega = 
    patch().lookupPatchField<volVectorField, vector>(UomegaName_);

Given my limited in-depth knowledge of programming in OpenFOAM, any help would be very much appreciated.

Petros

[olesen]

The obvious question(s) : where is the variable created? And you certain it has been created before your boundary condition uses it?
If it works in serial, that is usually an indication of some branching in your code where it is only created for Pstream :: master.

[ybapat]

It is looking for UmegaName vector field which is not available. Check if you can avoid calling updateCoeffs in constructor and force user to provide value to start with.

-Yogesh

[petros]

Originally Posted by olesen

The obvious question(s) : where is the variable created? And you certain it has been created before your boundary condition uses it?
If it works in serial, that is usually an indication of some branching in your code where it is only created for Pstream :: master.

Thanks for taking time to look at this Mark.

The variable Uomega is created in createFields.H before the field which the said boundary condition applies to.

By using some output on the screen, it turns out that when running in serial, the variable Uomega is updated before the boundary condition but when I decompose the case the Uomega is updated after the boundary condition and hence not available. Why is this the case?

Regarding your second note, how can I locate this branching in the code? What should I be looking for?

Petros

[petros]

Originally Posted by ybapat

It is looking for UmegaName vector field which is not available. Check if you can avoid calling updateCoeffs in constructor and force user to provide value to start with.

-Yogesh

Hi Yogesh,

As you can see in the code there is an if statement where the user can provide an initial value. The problem here is that when I include an initial value my boundary condition doesn't write the calculated values but instead holds that initial value till the end. I am not sure why this happens either. However, when I use updateCoeffs() in the constructor everything seems to work fine.

Additionally, I've seen other boundary conditions using updateCoeffs() (or evaluate(), which I have also tried with same results) in the constructor, e.g. rotatingWallVelocity.

But the main question is why it works in serial but fails in the decomposition. Please also refer to my previous post for the order of update of the two fields.

Petros

[petros]

Sorry for bringing this up again but I still can't find the answer.

The only work-around that seems to work is to decompose the case using default boundary conditions and then manually set the custom boundary condition in the processor folders.

[petros]

Problem solved with the valuable help of a fellow foamer.

For future reference:

1. I removed updateCoeffs() from the constructor.

2. Added <myField>.correctBoundaryConditions() at the end of the solver iteration as my fields where not used in any fvm:: operations and thus weren't updated automatically at every time step.

Petros