CFD Online Discussion Forums

CFD Online Discussion Forums (
-   OpenFOAM (
-   -   Simple hardcoding boundary conditions (

Noggin October 26, 2010 06:51

Simple hardcoding boundary conditions
Hi Foamers,

I'm trying to get to grips with the basics of OpenFOAM, and have just been trying to play with the most basic of boundary conditions. I am using 1.7.0.

I read in a basic rectangular mesh, and then make a volScalarField, with a uniformFixedValueFvPatchField specification as follows:

wordList volBoundaryTypes(3) ;
volBoundaryTypes[0]="uniformFixedValue" ;
volBoundaryTypes[1]="zeroGradient" ;
volBoundaryTypes[2]="uniformFixedValue" ;

volScalarField VSF1
f, // this is a dimensioned scalar

So far the value of the boundary condition has not been read in, so I want to specify it.

I thought this should be possible with:

VSF1.boundaryField()[0].uniformValue() = 1.

If I type:

Info << "typeid :" << typeid(VSF1.boundaryField()[0]).name() << "\n" ;

typeid: N4Foam29uniformFixedValueFvPatchFieldIdEE44

which is what I want.

However, when I incorporate the boundary specification the compiler says:

error: ‘struct Foam::fvPatchField<double>’ has no member named ‘uniformValue’

If I create a boundary condition from

uniformFixedValueFvPatchField<scalar> bc1(VSF1.boundaryField([0].patch(),VSF1.dimensionedInternalField()) ;
bc1.uniformValue()=1 ;
Info << "bc1: " << bc1.uniformValue() << "\n";
bc1.evaluate() ;
Info << "Typeid bc1: " << typeid(bc1).name() << "\n" ;

then there is no problem, and the typeid is identical to that given earlier.

Can anyone see what the problem is?

Many thanks.

marupio October 26, 2010 11:49

When you build it as a GeometricField, you only have access to the generic fvPatchField object because the derived class is loaded using runTimeSelection. What you could do is create the boundary condition first, then hand it to the GeometricField constructor. Look through the constructors avaliable in GeometricField - one should be suitable.

Noggin October 27, 2010 06:52

Thanks for the reply. There is one constructor which takes the components directly, including PtrList to the boundary conditions.
I was hoping for access to these boundary conditions after they have been constructed, and arbitrarily changing them at run time. From your earlier reply, I take it the runTimeSelection prohibits this is general.

schmittp54 October 28, 2010 07:55

Marupio's explanation makes clear that we cannot change the uniformValue of a uniformFixedValueFvPatchField at runtime.

But is it possible to create a new uniformFixedValueFvPatchField with the desired uniformValue and replace the existing patchfield with this new one?
I had the problem that all patchfield references returned from a GeometricField are const references and cannot be changed, so that I use the very inefficient method to create a new GeometricField with new patchfields whenever some uniformValue has to change at runtime.

Let's say we have a volScalarField VSF1 and want to apply some new uniformFixedValueFvPatchField<scalar> bc1 on one patch. Can you show a few lines of code which do not cause an access violation and have the expected effect on the solution?


marupio October 28, 2010 14:59

Why do you want to change a uniform fixed value boundary condition midway through the run. Can't you just use one of the time dependent boundary conditions?

schmittp54 October 29, 2010 05:33

I don't know which time dependent boundary conditions allows changes of the uniform value at runtime. All are based on dictionary entries which are fixed for the entire simulation. The closest match is groovyBC, but I need to change the value based on complex procedural calculations that cannot be expressed in groovyBC. Therefore I calculate the new value in a modified solver, based on icoFoam, interFoam or others, and I only have to update or replace the existing boundary condition to use this new value. Impossible?


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