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

Purposes of updateCoeffs, initEvaluate and evaluate....?

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

Like Tree1Likes
  • 1 Post By deepsterblue

Reply
 
LinkBack Thread Tools Display Modes
Old   December 30, 2011, 16:34
Default Purposes of updateCoeffs, initEvaluate and evaluate....?
  #1
Senior Member
 
Philippose Rajan
Join Date: Mar 2009
Location: Germany
Posts: 530
Rep Power: 16
philippose will become famous soon enough
Hello and a Good Evening to everyone :-)!

The year has mandered through its time and almost reached the end! Must say, it was a fast one this time (have a weird feeling I say that each year :-)!)

I have been trying (still am) too figure out the implementation of the GGI interface in OpenFOAM-1.6-ext (Git version), and have one quick question....

** In the context of Boundary Conditions - Patches and Fields, What are the purposes of the following functions / methods?

1. updateCoeffs
2. initEvaluate
3. evaluate

I see some implementations of the boundary conditions (fields) using only updateCoeffs, some using only a combination of initEvaluate and evaluate, and some with only initEvaluate and the evaluate function calling a "this->updateCoeffs()"



(P.S.... Has anyone tried out Source Navigator NG?? Its quite a cool tool which can be used for browsing through code)

Have a great evening ahead!

Philippose
philippose is offline   Reply With Quote

Old   December 30, 2011, 17:12
Default
  #2
Senior Member
 
Sandeep Menon
Join Date: Mar 2009
Location: Amherst, MA
Posts: 386
Rep Power: 15
deepsterblue will become famous soon enough
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.
hua1015 likes this.
__________________
Sandeep Menon
University of Massachusetts Amherst
https://github.com/smenon
deepsterblue is offline   Reply With Quote

Old   December 30, 2011, 17:31
Default
  #3
Senior Member
 
Philippose Rajan
Join Date: Mar 2009
Location: Germany
Posts: 530
Rep Power: 16
philippose will become famous soon enough
Hi Sandeep :-)!

Thanks for your reply... yes, I had looked at the code in GeomtetricBoundaryField over the last few days.

My specific question is, how come some of the implementations of specific boundary conditions (the derived ones) used "updateCoeffs" and some of them use "evaluate" or a combination of "initEvaluate / evaluate" in order to update the boundary conditions?

How does one decide when to use "updateCoeffs" and when to use "initEvaluate" / "evaluate" ?


** I was looking a little deeper, and now that you mention it, it looks like only the "basic" and "constraint" fvPatchField boundary conditions implement an "evaluate" method

** All the fvPatchFields under the "derived" category implement only an "updateCoeffs" method but no "evaluate" method.


So does this mean, that "evaluate" and "initEvaluate" are only meant of updating boundary conditions at a low level and specifically for parallel communications, and all derived boundary conditions need to use only the "updateCoeffs" function to update the BCs?


One other thing..... is there anywhere I can get something like a flow of events when a solver is executed, as in.... which are all the functions, and which order they are called when a boundary condition is being created and later solved / updated?

I know that these are all very basic questions, but I think in order to figure out how the GGI works, and whether there is any way I can modify it to handle uncovered faces, I do need to understand this basic flow.

Thanks once again!

Philippose
philippose is offline   Reply With Quote

Old   January 4, 2012, 10:21
Default
  #4
Senior Member
 
Sandeep Menon
Join Date: Mar 2009
Location: Amherst, MA
Posts: 386
Rep Power: 15
deepsterblue will become famous soon enough
Yup - the evaluate / initEvaluate members are intended for low-level use, such as inter-processor comms and/or fancy constraints. It is expected that this can be abstracted away for higher-level functionality.

For order-of-operations, you can always set the debug flags in etc/controlDict, and then you will get any info that falls under an "if (debug)" condition. You may have to add your own and recompile, if necessary.
__________________
Sandeep Menon
University of Massachusetts Amherst
https://github.com/smenon
deepsterblue is offline   Reply With Quote

Old   April 4, 2012, 11:21
Default
  #5
Member
 
AleDR's Avatar
 
Alessandro
Join Date: May 2009
Location: Genova
Posts: 43
Rep Power: 8
AleDR is on a distinguished road
Hello FOAMers!

...just to complete the above discussion, I have a questions:

Is evaluate() - and so correctBoundaryConditions() - intended for creating point of synchronization in parallel execution?


Thanks!!
AleDR is offline   Reply With Quote

Old   November 9, 2012, 06:16
Default
  #6
New Member
 
Mohanamuraly
Join Date: May 2009
Posts: 16
Rep Power: 8
mohanamuraly is on a distinguished road
The initEvaluate and evaluate functions are being called in correctBoundaryConditions(). I have successfully used this correctBoundaryConditions in my solver. Attached below is a peudo code

Do iter = 1 to niter

calculate fluxes for internal faces

/// Exchange the field variable "1" across processors
fieldVariable1.correctBoundaryConditions();
applyBC for fieldVariable1

/// Exchange the field variable "2" across processors
fieldVariable2.correctBoundaryConditions();
applyBC for fieldVariable 2

....

End


This works perfectly fine. But when I try to do someting like this below it fails and do know why ? Can someone point out the mistake I am making ??

Do iter = 1 to niter

/// Start the transfer for all field variables
forAll patches in boundaryField {
fieldVariable1.boundaryField()[ipatch].initEvaluate();
fieldVariable2.boundaryField()[ipatch].initEvaluate();
}

calculate fluxes for internal faces


/// Confirm the exchange of variable "1"
forAll patches in boundaryField {
fieldVariable1.boundaryField()[ipatch].evaluate();
}
applyBC for fieldVariable1

/// Confirm the exchange of variable "2"
forAll patches in boundaryField {
fieldVariable2.boundaryField()[ipatch].evaluate();
}
applyBC for fieldVariable2
....

End
mohanamuraly is offline   Reply With Quote

Old   November 9, 2012, 06:58
Default
  #7
New Member
 
Mohanamuraly
Join Date: May 2009
Posts: 16
Rep Power: 8
mohanamuraly is on a distinguished road
Hi

I have figured out the mistake it should have been the following to make it non-blocking communication implementation

Do iter = 1 to niter

/// Start the transfer for all field variables
forAll patches in boundaryField that are of type "processor" {
fieldVariable1.boundaryField()[ipatch].initEvaluate();
fieldVariable2.boundaryField()[ipatch].initEvaluate();
}

calculate fluxes for internal faces


/// Confirm the exchange of variable "1"
forAll patches in boundaryField that are of type "processor" {
fieldVariable1.boundaryField()[ipatch].evaluate();
}
applyBC for fieldVariable1

/// Confirm the exchange of variable "2"
forAll patches in boundaryField that are of type "processor" {
fieldVariable2.boundaryField()[ipatch].evaluate();
}
applyBC for fieldVariable2
....

End

So basically if you use correctBoundaryConditions it will be a blocking implementation since you will wait till the data is send/recv. But if you use the one shown above you will have a non-blocking implementation using which you can hide communication latency.
mohanamuraly 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



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