
[Sponsors] 
October 13, 2011, 19:00 
Calculated Boundary Conditions

#1 
New Member
Ivy Long
Join Date: Jul 2011
Location: Chicago, Illinois
Posts: 5
Rep Power: 7 
Hello,
I'm modifying a solver and one of my fields of interest is calculated by dividing one scalar by another, say A/B, with the new field C used in later calculations. However, I found that if, in my case folder, I fix both A and B at the boundaries with nonzero values, the calculated result of C is always zero at that boundary, which is obviously wrong. I'm hoping there's a way to declare the C field differently, or possibly alter the way the b.c. are set in the case folder. Any suggestions? Thanks 

October 14, 2011, 09:22 

#2 
Senior Member
David Boger
Join Date: Mar 2009
Location: Penn State Applied Research Laboratory
Posts: 146
Rep Power: 10 
I don't observe this. I read in two volScalarFields (A and B), each with fixedValue boundary conditions on all boundaries, then created a new volScalarField C as A/B, and wrote out C. The output file for C gives the boundaries as "type calculated" with the "value" field reflecting the correct (nonzero) value.
How do you observe the values are zero? Can you give a short representative code that demonstrates your problem?
__________________
David A. Boger 

October 15, 2011, 23:53 

#3 
New Member
Ivy Long
Join Date: Jul 2011
Location: Chicago, Illinois
Posts: 5
Rep Power: 7 
Thanks David for your reply!
I've done a bit more tinkering around and it looks like when I divide A and B as entire fields, it does calculate the boundaries correctly. However, my denominator can and does go to zero often, so I'm dividing element by element, checking the denominator each time. In this case, the boundaries are calculated as zero (observed by checking the boundary fields in the output files). Also, I've noticed that it happens regardless of the boundary type; in my case, an inlet, inletOutlet, and wall. I hope this sheds a bit more light on the problem, but if you'd still like to see my solver and test case, I'd be happy to share. Thanks for your help! 

October 16, 2011, 12:32 

#4 
Senior Member
David Boger
Join Date: Mar 2009
Location: Penn State Applied Research Laboratory
Posts: 146
Rep Power: 10 
If C is a volScalarField, for example, then it contains both a collection of the cells (cellcentered values) and the values at the boundary faces. Normally, if you calculate C = A / B, OpenFOAM will take care of updating both the cell values and boundary values for you. In this case, it sounds like you are explicitly calculating the cell values yourself and are neglecting to do anything to update the boundary values. There are lots of ways to get around this  you could loop over each of the boundaries of C and each of the faces of each boundary, and perform your division operation (usually not recommended), you could set appropriate boundary conditions on C (e.g. by defining a 0/C file) and make sure they are updated with a call to C.correctBoundaryConditions() after you calculate the cell values, or you could do something like
Code:
dimensionedScalar BMin("BMin", B.dimensions(), SMALL); C = A / (B + BMin) When B is zero, how do you define C?
__________________
David A. Boger 

October 16, 2011, 22:15 

#5 
Senior Member
David Gaden
Join Date: Apr 2009
Location: Winnipeg, Canada
Posts: 436
Rep Power: 14 
Use the stabilise function on your denominator. Then you can calculate the entire field at a time. Field operations are optimised and can be as much as 100 times faster than going element by element. Your boundary field is likely zero when you loop element by element because you neglected to perform the calculations on the boundary field. A.field() only gives the internal field. You must also use A.boundaryField[patchIndex][cellIndex].
__________________
~~~ Follow me on twitter @DavidGaden 

October 17, 2011, 23:36 

#6 
New Member
Ivy Long
Join Date: Jul 2011
Location: Chicago, Illinois
Posts: 5
Rep Power: 7 
Thanks both of you for your help! I did neglect to calculate the boundaries, but it's fixed now.
David Boger, I decided to use an alteration of the last method you suggested, adding in an additional term to prevent dividing by zero while still allowing the full field operation. In the event that B goes to zero, C does as well, so I had to get a bit creative with some of OFs scalar operations. David Gaden, my method isn't nearly as elegant as stabilise, but it gets the job done. Thanks again! 

Thread Tools  
Display Modes  


Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
Impinging Jet Boundary Conditions  Anindya  Main CFD Forum  25  February 27, 2016 13:58 
CFX does not continue  Shafiul  CFX  10  February 17, 2011 08:57 
Update boundary conditions calculated by an external program  CedricVH  OpenFOAM  2  January 15, 2010 12:55 
Concentric tube heat exchanger (AirWater)  Young  CFX  5  October 6, 2008 23:17 
Fluent accuracy and boundary conditions  Paolo Lampitella  FLUENT  0  June 12, 2008 06:25 