CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM > OpenFOAM Running, Solving & CFD

Using mixedFvPatchField for convection BC

Register Blogs Community New Posts Updated Threads Search

Like Tree2Likes
  • 2 Post By mike_jaworski

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   March 27, 2009, 04:56
Default Using mixedFvPatchField for convection BC
  #1
Senior Member
 
Michael Jaworski
Join Date: Mar 2009
Location: Champaign, IL, USA
Posts: 126
Rep Power: 17
mike_jaworski is on a distinguished road
Ok, so there are a few threads around the forums that make vague inferences to using mixedFvPatchFields for the convective BC. There are various explanations, stating that it mixes a reference value and a reference gradient to form... well, the mix. None of them are kind enough to actually supply a solution to using the boundary condition for this sort of problem. S. Radl went ahead and wrote a separate BC just for this problem, which worked under 1.4.1, though I'm trying to sort out why it's not compiling in 1.5-dev.

Even so, I've been bugged by the seeming insistence that the mixedFvPatchFields can solve the problem. I gave it a go, but I find reading OF code obtuse because I'm not much of a coder (my C++ is pretty weak) and I haven't been able to wade into it. So, if someone can actually check my basics in this, I'd very much appreciate it.

So, the mixedFvPatchFields file has the following line inside the evaluate function:

Code:
Field<Type>::operator=
  (
         valueFraction_*refValue_
       +
         (1.0 - valueFraction_)*
        (
             this->patchInternalField()
        + refGrad_/this->patch().deltaCoeffs()
         )
  );
Here's my first assumption, that the Field<Type>:perator actually refers to the patch value, which I will call pV. valueFraction will be referred to as vf, rV will be reference value and rG will refer to the reference gradient

Second assumption is that this->patchInternalfield() refers then, to the cell Value (cV) and that the final portion of rV / this->patch().deltaCoeffs() is a method for extrapolating from the cV to the patch surface using the refGrad only. I'll call the deltaCoeffs term D.

So, pV = vf * rV + (1-vf)*(cV + rG*D) eq. 1
Now, if those assumptions are correct, algebra shall ensue as follows:

pV = vf * rV + cV + rG*D - vf* cV - vf*rG*D eq. 2
pV = vf * rV + (1-vf)*rV - (1-vf)*rV + cV -vf * cV + (1-vf)*rG*D eq. 3
pV = rV - (1-vf)*rV + (1-vf)*cV + (1-vf)*rG*D eq. 4
pV - rV = (1-vf)*(rG*D + cV - rV) eq. 5

So, using statements by Hrv that setting vf = 1 is equivalent to a fixedValue BC, this is seen that eq. 5 reduces to pV = rV. So far so good. Setting vf = 0 results in the following:
pV - rV + rV = rG*D + cV eq. 6
pV = rG*D + cV eq. 7

So, at least the behavior makes sense to me and is consistent with what the smarter coder types say.

How to turn this into a convective BC for something like laplacianFoam?

if one sets the refGradient term to 0, then eq. 5 becomes:

pV - rV = (1-vf)*(cV - rV) eq. 8

numerically, the patch value gets set to some interpolation between the reference and the cell value. However, the (cV - rV) term was grouped in with the gradient term, which suggests to me that the RHS of eq. 8 is equivalent to a grad( value ) term. If this is the case, then:
1/(1-vf) * (pV - rV) = (cV - rV) can be rewritten in slightly more familiar terms with h = heat transfer coefficient, k = thermal conductivity and "value" being the temperature:

h / k * (T_{surf} - T_{ref} ) = grad ( T )

so 1 / (1-vf) = h / k and refGrad should be set to zero to obtain a convective boundary condition.

Is this correct or have I just wasted 30 minutes of typing??

Regards,
Mike J.
nipinl and nkv1990 like this.
mike_jaworski is offline   Reply With Quote

Old   March 28, 2009, 01:22
Default
  #2
Senior Member
 
Michael Jaworski
Join Date: Mar 2009
Location: Champaign, IL, USA
Posts: 126
Rep Power: 17
mike_jaworski is on a distinguished road
So, that was a waste of time. If one is restricted to values of 0 < valueFraction < 1, the arbitrary heat transfer coefficients and conductivities easily surpass this. At the same time, a solver will still run using values outside 0 < vF < 1.

However, it's not the right result. A simple 1D case wound up with a temperature below the reference value. So much for this attempt.
mike_jaworski is offline   Reply With Quote

Old   September 24, 2009, 22:43
Default
  #3
Member
 
Jitao Liu
Join Date: Mar 2009
Location: Jinan , China
Posts: 64
Rep Power: 17
awacs is on a distinguished road
Dear Mike J.

I am interested in the convection BC too:

h / k * (T_{surf} - T_{ref} ) = grad ( T )

Have you got this convection BC

I am study the heating process of a solid, which has several heating channels for hot gas or hot oil flowing through. So the boundary condition at the channel wall belongs to the third-class, just as you mentioned above.

Please give me some tips. Thanks in advance.

Regards,
Jitao
awacs is offline   Reply With Quote

Reply


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 Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Boundary condition of the third kind or Danckwertz boundary condition plage OpenFOAM Running, Solving & CFD 4 October 3, 2006 13:21


All times are GMT -4. The time now is 06:15.