|
[Sponsors] |
October 26, 2010, 06:51 |
Simple hardcoding boundary conditions
|
#1 |
New Member
Noggin
Join Date: Sep 2010
Posts: 7
Rep Power: 15 |
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 ( IOobject ( "VSF1", runTime.timeName(), mesh, IOobject::NO_READ, IOobject::AUTO_WRITE ), mesh, f, // this is a dimensioned scalar volBoundaryTypes ); 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. |
|
October 26, 2010, 11:49 |
|
#2 |
Senior Member
David Gaden
Join Date: Apr 2009
Location: Winnipeg, Canada
Posts: 437
Rep Power: 21 |
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.
|
|
October 27, 2010, 06:52 |
|
#3 |
New Member
Noggin
Join Date: Sep 2010
Posts: 7
Rep Power: 15 |
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. |
|
October 28, 2010, 07:55 |
|
#4 |
New Member
Patricia
Join Date: Oct 2010
Posts: 22
Rep Power: 15 |
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? Thanks Patricia |
|
October 28, 2010, 14:59 |
|
#5 |
Senior Member
David Gaden
Join Date: Apr 2009
Location: Winnipeg, Canada
Posts: 437
Rep Power: 21 |
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?
|
|
October 29, 2010, 05:33 |
|
#6 |
New Member
Patricia
Join Date: Oct 2010
Posts: 22
Rep Power: 15 |
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?
Thanks Patricia |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Questions about the inletOutlet and outletInlet boundary conditions | brooksmoses | OpenFOAM Running, Solving & CFD | 24 | March 2, 2021 01:16 |
mass flow in is not equal to mass flow out | saii | CFX | 12 | March 19, 2018 05:21 |
non reflective boundary conditions for incompresible flow | Pascal_doran | OpenFOAM Programming & Development | 16 | August 25, 2015 05:35 |
Pressure boundary conditions | Lionel S. | Main CFD Forum | 1 | August 24, 2007 18:03 |
Help with boundary conditions | Dan | CFX | 0 | April 3, 2006 11:32 |