CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > OpenFOAM Programming & Development

updateCoeffs() and evaluate()

Register Blogs Members List Search Today's Posts Mark Forums Read

Like Tree2Likes
  • 1 Post By wyldckat
  • 1 Post By tiam

Reply
 
LinkBack Thread Tools Display Modes
Old   September 24, 2013, 04:46
Default updateCoeffs() and evaluate()
  #1
New Member
 
Join Date: Nov 2012
Posts: 13
Rep Power: 4
lixx is on a distinguished road
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 is offline   Reply With Quote

Old   October 3, 2013, 04:00
Default
  #2
New Member
 
Join Date: Nov 2012
Posts: 13
Rep Power: 4
lixx is on a distinguished road
Hi anybody can help here? Or this is a really stupid question to ask?
lixx is offline   Reply With Quote

Old   October 5, 2013, 08:25
Default
  #3
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 8,258
Blog Entries: 34
Rep Power: 84
wyldckat is just really nicewyldckat is just really nicewyldckat is just really nicewyldckat is just really nice
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
hua1015 likes this.
wyldckat is offline   Reply With Quote

Old   April 29, 2015, 04:43
Default
  #4
New Member
 
Timofey Mukha
Join Date: Mar 2012
Location: Göteborg, Sweden
Posts: 27
Rep Power: 5
tiam is on a distinguished road
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 likes this.
tiam is offline   Reply With Quote

Old   May 3, 2015, 13:11
Default
  #5
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 8,258
Blog Entries: 34
Rep Power: 84
wyldckat is just really nicewyldckat is just really nicewyldckat is just really nicewyldckat is just really nice
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 View Post
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
wyldckat is offline   Reply With Quote

Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Purposes of updateCoeffs, initEvaluate and evaluate....? philippose OpenFOAM Programming & Development 6 November 9, 2012 06:58
implementation of wallHeatTransfer BC Tobi OpenFOAM Programming & Development 1 August 8, 2012 08:21


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