BC externalWallHeatFluxTemperature understanding problem

stockzahn · October 30, 2018, 09:17

I'm currently trying to create a custom boundary condition based on "externalWallHeatFluxTemperature". In course of the changing I found some lines I don't understand and I hope that somebody can clarify them to me.

As I understood it, with the original BC one can choose between three modes ("Q" = total heat transferred in W, "q" = heat flux in W/m^2, "h" = convection by defining a HTC and an "ambient" temperature). To be able to create a consistent output which can be processed in each mode three values are generated:

1) refGrad in K/m ... the temperature gradient for the calculations in the modes "Q" and "q" (taking into account the radiative heat)
2) refValue in K ... a calculated temperature to take into account radiation for the mode "h"
3) valueFraction (dimensionless) ... the ratio of an overall HTC for convection & radiation and an overall HTC for convection, radiation & conduction

These three values are necessary for the calculation (via mixedFvPatchScalarField).

However, in "externalWallHeatFluxTemperature.C" (https://www.openfoam.com/documentati...8C_source.html) the lines 426 - 429 show the following calculation:

Code:

             const scalarField kappaDeltaCoeffs

             (

                 this->kappa(Tp)*patch().deltaCoeffs()

             );

I'm interpreting that as a scalarField is generated, whose values are the product of the thermal conductivity (as function of the temperature) multiplied by the distance of the patch face and the cell centre for each patch face). Therefore its dimension must be W/(m $\cdot$ K) $\cdot$ m = W/K.

When calculating the valueFraction in the lines 440 and 445 respectively, the code reads

Code:

valueFraction()[i] = hpmqr/(hpmqr + kappaDeltaCoeffs[i]);
valueFraction()[i] = hp[i]/(hp[i] + kappaDeltaCoeffs[i]);

where hpmqr and hp have the dimension W/(m $^2\cdot$ K), but kappaDeltaCoeffs has W/K.

In the valueFraction the ratio of the "combined" HTCs is calculated

$valueFraction = \frac{h_p}{\Delta x\kappa+ h_p}$

which doesn't seem to be consistent wrt to their units. It would make much more sense to me calculate them like this:

$valueFraction = \frac{\frac{1}{h_p}}{\frac{1}{h_p}+\frac{\Delta x}{\kappa}}$

In "mixedFvPatchField.C" (https://www.openfoam.com/documentati...8C_source.html) the lines 174 -178 show the function used in "externalWallHeatFluxTemperature.C" (snGrad):

Code:

     return

         valueFraction_

        *(refValue_ - this->patchInternalField())

        *this->patch().deltaCoeffs()

       + (1.0 - valueFraction_)*refGrad_;

For the modes "q"and "Q" valueFraction=0 and the heat Q is calculated as

$Q=\kappa A \frac{\Delta T}{\Delta x}$

For the mode "h":

$Q=\kappa A \frac{h_p}{\Delta x\kappa+ h_p} \left( T_a -T_p \right)\Delta x$

Although it think it should be something like

$Q=A \frac{1}{\frac{1}{h_p}+\frac{\Delta x}{\kappa}} \left( T_a -T_p \right)$

which in the end differs by a factor $\Delta x^2$ (if I didn't make a mistake).

I don't know if I don't read the codes correctly or if I make a conceptual mistake in my considerations/thoughts. Does anybody have an idea why the calculations and definitions (especially of valueFraction) are made like that?

stockzahn

stockzahn · October 31, 2018, 05:52

One more question: Until now I couldn't find how the updated coefficients

- refGrad
- refValue
- valueFraction

are processed to "realize" the boundary condition. Does anybody know where this values are used to calculate the values at the boundaries?

stockzahn

mAlletto · November 1, 2018, 12:49

Quote:

Originally Posted by stockzahn

I'm currently trying to create a custom boundary condition based on "externalWallHeatFluxTemperature". In course of the changing I found some lines I don't understand and I hope that somebody can clarify them to me.

As I understood it, with the original BC one can choose between three modes ("Q" = total heat transferred in W, "q" = heat flux in W/m^2, "h" = convection by defining a HTC and an "ambient" temperature). To be able to create a consistent output which can be processed in each mode three values are generated:

1) refGrad in K/m ... the temperature gradient for the calculations in the modes "Q" and "q" (taking into account the radiative heat)
2) refValue in K ... a calculated temperature to take into account radiation for the mode "h"
3) valueFraction (dimensionless) ... the ratio of an overall HTC for convection & radiation and an overall HTC for convection, radiation & conduction

These three values are necessary for the calculation (via mixedFvPatchScalarField).

However, in "externalWallHeatFluxTemperature.C" (https://www.openfoam.com/documentati...8C_source.html) the lines 426 - 429 show the following calculation:

Code:

             const scalarField kappaDeltaCoeffs

             (

                 this->kappa(Tp)*patch().deltaCoeffs()

             );

I'm interpreting that as a scalarField is generated, whose values are the product of the thermal conductivity (as function of the temperature) multiplied by the distance of the patch face and the cell centre for each patch face). Therefore its dimension must be W/(m $\cdot$ K) $\cdot$ m = W/K.

When calculating the valueFraction in the lines 440 and 445 respectively, the code reads

Code:

valueFraction()[i] = hpmqr/(hpmqr + kappaDeltaCoeffs[i]);
valueFraction()[i] = hp[i]/(hp[i] + kappaDeltaCoeffs[i]);

where hpmqr and hp have the dimension W/(m $^2\cdot$ K), but kappaDeltaCoeffs has W/K.

In the valueFraction the ratio of the "combined" HTCs is calculated

$valueFraction = \frac{h_p}{\Delta x\kappa+ h_p}$

which doesn't seem to be consistent wrt to their units. It would make much more sense to me calculate them like this:

$valueFraction = \frac{\frac{1}{h_p}}{\frac{1}{h_p}+\frac{\Delta x}{\kappa}}$

In "mixedFvPatchField.C" (https://www.openfoam.com/documentati...8C_source.html) the lines 174 -178 show the function used in "externalWallHeatFluxTemperature.C" (snGrad):

Code:

     return

         valueFraction_

        *(refValue_ - this->patchInternalField())

        *this->patch().deltaCoeffs()

       + (1.0 - valueFraction_)*refGrad_;

For the modes "q"and "Q" valueFraction=0 and the heat Q is calculated as

$Q=\kappa A \frac{\Delta T}{\Delta x}$

For the mode "h":

$Q=\kappa A \frac{h_p}{\Delta x\kappa+ h_p} \left( T_a -T_p \right)\Delta x$

Although it think it should be something like

$Q=A \frac{1}{\frac{1}{h_p}+\frac{\Delta x}{\kappa}} \left( T_a -T_p \right)$

which in the end differs by a factor $\Delta x^2$ (if I didn't make a mistake).

I don't know if I don't read the codes correctly or if I make a conceptual mistake in my considerations/thoughts. Does anybody have an idea why the calculations and definitions (especially of valueFraction) are made like that?

stockzahn

Maybe you missinterpreted the Definition oft the deltacoeffs. It is the reciprocal oft the distance between face center and Fell center

mesh.surfaceInterpolation::deltaCoeffs()

stockzahn · November 2, 2018, 03:38

Thanks, that works then and the factor $\Delta x^2$ should vanish. Do you by accident also know where the three coefficients are used/calculated (as asked in my 2nd post)?

mAlletto · November 2, 2018, 08:02

Quote:

Originally Posted by stockzahn

One more question: Until now I couldn't find how the updated coefficients

- refGrad
- refValue
- valueFraction

are processed to "realize" the boundary condition. Does anybody know where this values are used to calculate the values at the boundaries?

stockzahn

above fields are used in void Foam::mixedFvPatchField<Type>::evaluate(const Pstream::commsTypes)

there is also a thread here updateCoeffs() and evaluate() where it is discussed.

The explanation where in the solution process it is used is provided here:

https://www.openfoam.com/documentati...onditions.html

stockzahn · November 2, 2018, 12:32

Thank you very much again for the hints, have a nice weekend,

stockzahn

Bloerb · November 2, 2018, 15:30

To summarize the main idea behind this. We begin in the .H file which starts like this:

Code:

 class externalWallHeatFluxTemperatureFvPatchScalarField

 :

     public mixedFvPatchScalarField,

     public temperatureCoupledBase

 {

This means that this boundary condition is derived from temperatureCoupledBase and mixedFvPatchScalarField. The boundary conditions works in the following fashion: Set the three values defined by a mixed boundary condition inside the updateCoeffs function of this boundary condtion:

refValue() =...
refGrad() =...
valueFraction() =...

And afterwards call the updateCoeffs function of the mixed boundary itself:

mixedFvPatchScalarField::updateCoeffs();

Which now sets the patch value. As shown here:
https://www.openfoam.com/documentati...bcs-mixed.html
This means all we need to do is set those three values to something meaningful. E.g:

Code:

.....
         case fixedPower:
         {
             refGrad() = (Q_/gSum(patch().magSf()) + qr)/kappa(Tp);
             refValue() = 0;
             valueFraction() = 0;
 
             break;
  }
....
 mixedFvPatchScalarField::updateCoeffs();

deltaCoeffs is the distance from the wall to the center of the next cell. But inverted, so 1/distance. This is used to calculate a gradient for example. Like (Tf-Tc)/distance

October 30, 2018, 09:17	BC externalWallHeatFluxTemperature understanding problem	#1
stockzahn Member Join Date: Oct 2018 Location: France Posts: 34 Rep Power: 8	I'm currently trying to create a custom boundary condition based on "externalWallHeatFluxTemperature". In course of the changing I found some lines I don't understand and I hope that somebody can clarify them to me. As I understood it, with the original BC one can choose between three modes ("Q" = total heat transferred in W, "q" = heat flux in W/m^2, "h" = convection by defining a HTC and an "ambient" temperature). To be able to create a consistent output which can be processed in each mode three values are generated: 1) refGrad in K/m ... the temperature gradient for the calculations in the modes "Q" and "q" (taking into account the radiative heat) 2) refValue in K ... a calculated temperature to take into account radiation for the mode "h" 3) valueFraction (dimensionless) ... the ratio of an overall HTC for convection & radiation and an overall HTC for convection, radiation & conduction These three values are necessary for the calculation (via mixedFvPatchScalarField). However, in "externalWallHeatFluxTemperature.C" (https://www.openfoam.com/documentati...8C_source.html) the lines 426 - 429 show the following calculation: Code: const scalarField kappaDeltaCoeffs ( this->kappa(Tp)patch().deltaCoeffs() ); I'm interpreting that as a scalarField is generated, whose values are the product of the thermal conductivity (as function of the temperature) multiplied by the distance of the patch face and the cell centre for each patch face). Therefore its dimension must be W/(m $\cdot$ K) $\cdot$ m = W/K. When calculating the valueFraction in the lines 440 and 445 respectively, the code reads Code: valueFraction()[i] = hpmqr/(hpmqr + kappaDeltaCoeffs[i]); valueFraction()[i] = hp[i]/(hp[i] + kappaDeltaCoeffs[i]); where hpmqr and hp have the dimension W/(m $^2\cdot$ K), but kappaDeltaCoeffs has W/K. In the valueFraction the ratio of the "combined" HTCs is calculated $valueFraction = \frac{h_p}{\Delta x\kappa+ h_p}$ which doesn't seem to be consistent wrt to their units. It would make much more sense to me calculate them like this: $valueFraction = \frac{\frac{1}{h_p}}{\frac{1}{h_p}+\frac{\Delta x}{\kappa}}$ In "mixedFvPatchField.C" (https://www.openfoam.com/documentati...8C_source.html) the lines 174 -178 show the function used in "externalWallHeatFluxTemperature.C" (snGrad): Code: return valueFraction_ (refValue_ - this->patchInternalField()) this->patch().deltaCoeffs() + (1.0 - valueFraction_)refGrad_; For the modes "q"and "Q" valueFraction=0 and the heat Q is calculated as $Q=\kappa A \frac{\Delta T}{\Delta x}$ For the mode "h": $Q=\kappa A \frac{h_p}{\Delta x\kappa+ h_p} \left( T_a -T_p \right)\Delta x$ Although it think it should be something like $Q=A \frac{1}{\frac{1}{h_p}+\frac{\Delta x}{\kappa}} \left( T_a -T_p \right)$ which in the end differs by a factor $\Delta x^2$ (if I didn't make a mistake). I don't know if I don't read the codes correctly or if I make a conceptual mistake in my considerations/thoughts. Does anybody have an idea why the calculations and definitions (especially of valueFraction) are made like that? stockzahn

November 2, 2018, 15:30		#7
Bloerb Senior Member Join Date: Sep 2013 Posts: 353 Rep Power: 21	To summarize the main idea behind this. We begin in the .H file which starts like this: Code: class externalWallHeatFluxTemperatureFvPatchScalarField : public mixedFvPatchScalarField, public temperatureCoupledBase { This means that this boundary condition is derived from temperatureCoupledBase and mixedFvPatchScalarField. The boundary conditions works in the following fashion: Set the three values defined by a mixed boundary condition inside the updateCoeffs function of this boundary condtion: refValue() =... refGrad() =... valueFraction() =... And afterwards call the updateCoeffs function of the mixed boundary itself: mixedFvPatchScalarField::updateCoeffs(); Which now sets the patch value. As shown here: https://www.openfoam.com/documentati...bcs-mixed.html This means all we need to do is set those three values to something meaningful. E.g: Code: ..... case fixedPower: { refGrad() = (Q_/gSum(patch().magSf()) + qr)/kappa(Tp); refValue() = 0; valueFraction() = 0; break; } .... mixedFvPatchScalarField::updateCoeffs(); deltaCoeffs is the distance from the wall to the center of the next cell. But inverted, so 1/distance. This is used to calculate a gradient for example. Like (Tf-Tc)/distance jherb, dats, stockzahn and 1 others like this.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Problem with interFoam; Wave/wiggle alpha1 behavior	JonW	OpenFOAM	10	February 4, 2023 08:27
UDF compiling problem	Wouter	Fluent UDF and Scheme Programming	6	June 6, 2012 05:43
Gambit - meshing over airfoil wrapping (?) problem	JFDC	FLUENT	1	July 11, 2011 06:59
Problem in implementing cht	tilek	CFX	3	May 8, 2011 09:39
Adiabatic and Rotating wall (Convection problem)	ParodDav	CFX	5	April 29, 2007 20:13

October 31, 2018, 05:52		#2
stockzahn Member Join Date: Oct 2018 Location: France Posts: 34 Rep Power: 8	One more question: Until now I couldn't find how the updated coefficients - refGrad - refValue - valueFraction are processed to "realize" the boundary condition. Does anybody know where this values are used to calculate the values at the boundaries? stockzahn

November 2, 2018, 03:38		#4
stockzahn Member Join Date: Oct 2018 Location: France Posts: 34 Rep Power: 8	Thanks, that works then and the factor $\Delta x^2$ should vanish. Do you by accident also know where the three coefficients are used/calculated (as asked in my 2nd post)?

November 2, 2018, 12:32		#6
stockzahn Member Join Date: Oct 2018 Location: France Posts: 34 Rep Power: 8	Thank you very much again for the hints, have a nice weekend, stockzahn