CFD Online Discussion Forums

CFD Online Discussion Forums (http://www.cfd-online.com/Forums/)
-   OpenFOAM Programming & Development (http://www.cfd-online.com/Forums/openfoam-programming-development/)
-   -   updateCoeffs() and evaluate() (http://www.cfd-online.com/Forums/openfoam-programming-development/123913-updatecoeffs-evaluate.html)

lixx September 24, 2013 04:46

updateCoeffs() and evaluate()
 
Hi Foamers,

I am confused with the two functions in boundary condition classes: updateCoeffs() and evaluate(). Sometimes updateCoeffs() is called, but in some BCs evaluate() is called (e.g., src/finiteVolume/fields/fvPatchFields/basic/fixedGradient/fixedGradientFvPatchField.C ). And in the body of evaluate(), there is a call to updateCoeffs() first.

Code:

template<class Type>
void fixedGradientFvPatchField<Type>::evaluate(const Pstream::commsTypes)
{
    if (!this->updated())
    {
        this->updateCoeffs();
    }

    Field<Type>::operator=
    (
        this->patchInternalField() + gradient_/this->patch().deltaCoeffs()
    );

    fvPatchField<Type>::evaluate();
}

So in practice, if I want to implement a new BC, which method should I implement? Or can I implement both? In what sequence they will be called when correctBoundaryCondition() is called?

Another problem is why sometimes a BC have to deal specially with the parallel mode (say, in src/finiteVolume/fields/fvPatchFields/derived/mappedFixedValue/mappedFixedValueFvPatchField.C, updateCoeffs()) while others don't have to do so? Is there guideline for this?

Many thanks,

Xianxiang

lixx October 3, 2013 04:00

Hi anybody can help here? Or this is a really stupid question to ask?

wyldckat October 5, 2013 08:25

Greetings Xianxiang,

When in doubt, check the code documentation: http://foam.sourceforge.net/docs/cpp/index.html

I did a quick search regarding each method and it should be somewhat self-explanatory from their documentation (namely the comments from the header files):
  • updateCoeffs:
    Quote:

    Update the coefficients associated with the patch field.
    In other words, it should update anything referent to the patch itself, such as porosity coefficients or something like that.
  • evaluate:
    Code:

    Evaluate the patch field.
    In other words, this method should take care of properly processing the flow on the patch.
In addition, I suggest that you have a broader look into how the other BCs work, to get a better idea on how to use this.

Best regards,
Bruno

tiam April 29, 2015 04:43

Hello!

Bruno, I think the matter is actually more involved, or, maybe I misunderstand something.

Both evaluate() and updateCoeffs() seem to do more or less the same thing. Calculate some stuff relevant to the boundary condition and then enforce the changes. The latter can take the form of an assignment via == or =, or through the change of some relevant parameters, like weights in the mixed b.c.

As indicated in this thread
here the evaluate() method seems to be implemented only in the highest levels of hierarchy and commonly deals with more "complicated" stuff like the case of coupled patches.

The updateCoeffs() seems to do all the complicated work in the classes that are further downstream in the hierarchy. I am personally looking at wall-functions for LES and the one that exists in OF implements everything in updateCoeffs(), including an iterative procedure to calculate u_tau at each face. In my view this definitely qualifies as "processing the flow", but maybe you meant something else.

The main relationship between the methods is that evaluate() always calls updateCoeffs(). In fvPatchField.C/H we have

Code:

template<class Type>
void Foam::fvPatchField<Type>::evaluate(const Pstream::commsTypes)
{
    if (!updated_)
    {
        updateCoeffs();
    }

    updated_ = false;
}

virtual void updateCoeffs()
{
    updated_ = true;
}

My understanding is that this means that calling updateCoeffs() explicitly (not via evaluate()) will prevent it for being called again. But I am not sure why that is needed, I would appreciate some insight! I also didn't find where the updated_ flag gets reset.

wyldckat May 3, 2015 13:11

Greetings Timofey,

I wrote that post about a year ago and today I still don't know everything about OpenFOAM ;)

The thread you mentioned does give some clearer insight:
Quote:

Originally Posted by deepsterblue (Post 337424)
initEvaluate / evaluate functions are used for boundary field evaluations that are interleaved with inter-processor communication. Take a look at GeometricBoundaryField.C to see how this works..

updateCoeffs basically ensures that boundaryField arrays are up-to-date when the next BC update during the matrix multiply takes place.

As for when the resetting of the "updated_" flag... I'll have to look into the code... OK:
  • In this file:
    Code:

    $FOAM_SRC/finiteVolume/fields/fvPatchFields/fvPatchField/fvPatchField.H
    it this description:
    Code:

            //- Update index used so that updateCoeffs is called only once during
            //  the construction of the matrix
            bool updated_;

  • The flag is set to true when "updateCoeffs()" is called and reset to false at the end of "evaluate()".
  • "evaluate()" is called by "GeometricField<Type, PatchField, GeoMesh>::GeometricBoundaryField::
    evaluate()"...
  • ... which in turn is called by "GeometricField<Type, PatchField, GeoMesh>::
    correctBoundaryConditions()".
  • The last one seems to be called whenever needed, although the likely suspects are the classes at "$FOAM_SRC/finiteVolume/fvMatrices", given the comment above for "updateCoeffs" regarding "construction of the matrix".
I suspect that the variable is only reset when "evaluate()" is done, because this means that it's usually the last operation that is meant to be performed when solving the fields, since it's expected that in the next solving step, everything should have changed values.

Best regards,
Bruno


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