[mwild]

Hi all

I'm struggling with the implementation of a new boundary condition for dynamic meshes. I picked oscillatingDisplacementPointPatchVectorField to start with and now want to change the law for the displacement in my own class. For this I need to adapt updateCoeffs(), and in there I want to access the pressure on the boundary patch.

I suspect I have to do something like this->db().lookupObject<...>("p"), however I can't seem to find the right type for the template parameter (and thus the return value). If I have a look at this->db().names() I see that the pressure is there, so it must be possible in some way, grepping the source code didn't turn up something which worked however.

Thanks for you help in advance

Michael

[ngj]

Hi Michael

Go to the src directory and type the following in the command line:

find ./ -name "*FvPatch*.C" | xargs grep "lookupObject.*p"

I believe any of the matched files will tell you exactly what it is you need to do to achieve what you want.

Have fun,

Niels

[olesen]

I've needed something like this recently too. Of course I cannot find the code right, but here's how it goes. Beware that since the forum software mangles code, I've used the html coding for less-than, greater-than.

Since objectRegistry inherits from a HashTable of regIOobject*, you can try something like this.

forAllConstIter(HashTable&lt;regIOobject*&gt;, obr, iter)
{
Info &lt;&lt; "name=" &lt;&lt; iter()-&gt;name()
&lt;&lt; " type=" &lt;&lt; iter()-gt;type() &lt;&lt; endl;
}

in which 'obr' is your objectRegistry to interogate.

Please check if this code is actually correct, but you get the idea anyhow.

[mwild]

Thanks both of you. I already tried the grepping on my own, and already then came up with volScalarField. When I tried it, it still didn't work. However what I hadn't noticed before is that the BC gets invoked before there even is a pressure field, which is the actual cause for the failure... Stupid me.

And that solution of Mark is much more elegant than what I came up with (my naive implementation was to modify the IOregistry class, adding a method classes() which used RTTI to determine the type of each object).

Thanks again!


Michael

[Marta]

Hi Foamers!
I saw that this is a old post, but i think this can be useful for other people who need to implement a new boundary condition.
I am modifying the original cyclic boundary condition for velocity and I had the same problem with RTTI. I finally modified the code as follows:

const DimensionedField<Type,volMesh>& iField = this->dimensionedInternalField();

for iField instead of :

const Field<Type>& iField = this->internalField();

at this point I started an if loop for velocity this way:

if (!iField.name().compare("U"))

Hope this might help!

Marta

[nishant_hull]

Originally Posted by Marta

Hi Foamers!
I saw that this is a old post, but i think this can be useful for other people who need to implement a new boundary condition.
I am modifying the original cyclic boundary condition for velocity and I had the same problem with RTTI. I finally modified the code as follows:

const DimensionedField<Type,volMesh>& iField = this->dimensionedInternalField();

for iField instead of :

const Field<Type>& iField = this->internalField();

at this point I started an if loop for velocity this way:

if (!iField.name().compare("U"))

Hope this might help!

Marta

Hi Marta,

Thank you for sharing it. I am currently working on changing the boundary condition. However my algortihm require me to call a function, which return a vector quantity. I want to put that vector quantity equal to patchField, so that patchField get modified!

Field<Type>& patchField = *this;
Field<Type> myField(this->size());

forall(patchField, i)
{
patchField[i]= myfunction(myField[i]);
}

Now the trouble is, when i create a vector in the myfunction and return it through this function, there is a mismatch! because the patchField is a <TYPE> which is not only vector but other things as well.
Can you suggest me some way out???

regards,
Nishant

[Marta]

Hi Nishant!

I had that error too once! I can suggest you to use the fvPatchFields file to implement your functions with the types you need specified.

The idea is to maintain the basic function, working with the generic <Type> (which can be tensor, vector or scalar) in the <boundaryname>fvPatchField.C and .H files and to reimplement it specifically for your desired type into the <boundaryname>fvPatchFields.C file after having it declared into the corresponding .H .

I can copy an example here:

template<>
void spongeCyclicFvPatchField<vector>::evaluate
(
const Pstream::commsTypes commsType
)
{
if (!this->updated())
{
this->updateCoeffs();
}


fvPatchField<vector>::evaluate();

}

i wrote this function into the file of my new boundary condition which i called : spongeCyclicFvPatchFields.C

Hope this helps!

Marta

[nishant_hull]

Originally Posted by Marta

Hi Nishant!

I had that error too once! I can suggest you to use the fvPatchFields file to implement your functions with the types you need specified.

The idea is to maintain the basic function, working with the generic <Type> (which can be tensor, vector or scalar) in the <boundaryname>fvPatchField.C and .H files and to reimplement it specifically for your desired type into the <boundaryname>fvPatchFields.C file after having it declared into the corresponding .H .

I can copy an example here:

template<>
void spongeCyclicFvPatchField<vector>::evaluate
(
const Pstream::commsTypes commsType
)
{
if (!this->updated())
{
this->updateCoeffs();
}


fvPatchField<vector>::evaluate();

}

i wrote this function into the file of my new boundary condition which i called : spongeCyclicFvPatchFields.C

Hope this helps!

Marta

Hi Marta.
Thanks for the reply. Although I have get rid of my problem. I got some help from the turbulentInlet boundary condition implementation.
The implementation you are talking bout is something new to me. but it make a complete sense, as the evaluate function is declared virtual in the fvPatchField class.
However what i do not understand is that, why you kept the braces empty like this <> in the definition of
template<>
void spongeCyclicFvPatchField<vector>::evaluate

Also, where would you place the code of the boundary condition changes in evaluate() function? I assume **** code of BC changes ****** will be placed like this:

{
if (!this->updated())
{
this->updateCoeffs();
}

**** code of BC changes ******

fvPatchField<vector>::evaluate();

}

As updateCoeffs() function changes the boundary implementation as well, which part of implementation is done in which function? In short, what kind of changes in boundary condition can be brought in this evaluate() function?

Thanks & regards,

Nishant

[nishant_hull]

Hi Marta,

I have implemented a new boundary condition now but there are some problem I am having while running. After few hundred iterations in a channel test case, I am having these errors:

Maximum number of iterations exceeded#0 Foam::error:rintStack(Foam::Ostream&) in "/home/nishant/OpenFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libOpenFOAM.so"
#1 Foam::error::abort() in "/home/nishant/OpenFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libOpenFOAM.so"
#2 Foam::hPsiThermo<Foam:ureMixture<Foam::constTran sport<Foam::specieThermo<Foam::hConstThermo<Foam:: perfectGas> > > > >::calculate() in "/home/nishant/OpenFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libbasicThermophysicalModels.so"
#3 Foam::hPsiThermo<Foam:ureMixture<Foam::constTran sport<Foam::specieThermo<Foam::hConstThermo<Foam:: perfectGas> > > > >::correct() in "/home/nishant/OpenFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libbasicThermophysicalModels.so"
#4
in "/home/nishant/OpenFOAM/nishant-1.6/applications/bin/linux64GccDPOpt/rhoPisoFoam-klein"
#5 __libc_start_main in "/lib/libc.so.6"
#6
in "/home/nishant/OpenFOAM/nishant-1.6/applications/bin/linux64GccDPOpt/rhoPisoFoam-klein"


From function specieThermo<thermo>::T(scalar f, scalar T0, scalar (specieThermo<thermo>::*F)(const scalar) const, scalar (specieThermo<thermo>::*dFdT)(const scalar) const) const
in file /home/dm2/henry/OpenFOAM/OpenFOAM-1.6/src/thermophysicalModels/specie/lnInclude/specieThermoI.H at line 68.

FOAM aborting

Can you please tell me how to get rid of such problems? I assume you might have come across such problems at some stage. Any help in this regard will be deeply appreciated.

Thanks & regards,

Nishant