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

chtMultiRegionFoam, Radiation, surrounding-Temperature specification Issue

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

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   January 10, 2019, 17:12
Default chtMultiRegionFoam, Radiation, surrounding-Temperature specification Issue
  #1
New Member
 
Join Date: Sep 2011
Posts: 11
Rep Power: 14
Abishek is on a distinguished road
Hi All,

This is with reference the the chtMultiRegionFoam solver (or even the single region solvers) with the inclusion of surface-to-surface radiation. The fluid is radiatively non-participating.

The issue is with respect to the j'th surface temperatures used for the radiation calculations on the i'th surface. I am using the view factor radiation model (although I have tried the other alternatives, but with no success).

The description of the sample case considered is as follows.

A 2D box with a thin plate at the bottom at T_hot = 310 K. The top surface is at T_cold = 300 K. The sides are zeroGradient.

The initial fluid velocities are (0,0,0). The simulation is solved with the frozenFlow = true; in the system/fluid/fvSolution, as the focus is on radiation, for the purposes of this discussion. The simulation is solved using the steady state solver.

In the absence of radiation, this should reduce to a simple conduction problem with a linear temperature distribution from bottom to top, all the way across, with the gradient defined according to:
(T_hot - T_cold)/H; where H is the height of the box.

The heat flux would simply be:
q_wall = q_cond = -k_fluid*dT/dy

In the presence of radiation (irrespective of the emissivities), and assuming that the fluid properties are constant, the temperature distribution in the fluid should still be according to pure conduction, as described above. However, the total heat flux now would be

q_wall = q_cond + q_rad.

It all works upto q_cond. The issue with q_rad is as follows:

Irrespective of the emissivities, the surface temperatures of the left and right walls (j'th cells) used in the radiositiy calculations for the bottom wall (i'th cells), would be the actual temperatures (obtained from the conduction solution, i.e. some value between 310 and 300 K). In many applications, such as a hot body in a large domain (or in the open), the temperature of the j'th surface (the open-boundaries) must be the surrounding temperature, such as T_inf (or T_cold), and not the local temperature obtained from the convection solver.

This inconsistency results in the q_rad in the bottom plate to be calculated incorrectly. To fix this, if the same problem is repeated with an extended domain beyond the plate in both sides, and by fixing the extended-boundary temperature to T_inf = T_cold = 300K, the q_rad is calculated correctly as:
q_rad = sigma*emm*(T_hot^4 - T_cold^4) => as the total view factor from the bottom plate to all the other surfaces = 1.

However, it is not always possible to do this due to mesh limitations; convection calculations may not require such a large domain. It must hence be possible to specify two different temperature fields in OpenFOAM, one for convection calculations, and the other for radiation calculations; technically this should be applicable only for external flow/ heat transfer problems, where the T_inf needs to be specified for radiosity calculations.

Ideally, the external boundaries (such as the left and right boundaries) must be included as black body at T_inf for radiation calculations, while the actual temperatures and boundary conditions must be used for the convection calculations. In the present framework, however, the emissivity for the left and right walls must be set to zero so that it does not contribute to the surface energy balance on the left and rigt walls.

The issue with the specification of the j'th surface temperature was identified in the following way. Two images are enclosed below (case-1 and case-2).

Case 1 assumes zeroGradient boundary condition for fluid/T on the left and right walls.
Case 2 assumes fixedValue = T_cold for fluid/T on the left and right walls.

In case 1, the fluid temperatures and q_cond at the bottom wall are correct. q_rad is not as required.
In case 2, q_rad at the bottom wall is correct; of course q_cond will be wrong.

The case files are also enclosed. simply run < bash ./Allrun >. A paraview stateV1.psvm file is also enclosed.
You can modify the boundary condition in the zOrg/org0/fluidIn/T file from one to another as required.


PS: (i) The case files correspond to openfoam-6.0, but the question should apply to any previous versions. (ii) The parameter qro under greyDiffusiveRadiationViewFactor BC also does not help; it is intended for the energy balance on the i'th surface.


Any suggestions would be helpful!

Thanks.
Attached Images
File Type: jpg case1.jpg (111.2 KB, 71 views)
File Type: jpg case2.jpg (110.1 KB, 45 views)
Attached Files
File Type: gz case.tar.gz (62.0 KB, 19 views)

Last edited by Abishek; January 10, 2019 at 17:27. Reason: correction
Abishek is offline   Reply With Quote

Old   January 10, 2019, 17:23
Unhappy Possible solutions, and trials
  #2
New Member
 
Join Date: Sep 2011
Posts: 11
Rep Power: 14
Abishek is on a distinguished road
To fix this, I tried to modify the view-factor library. As this is an enthalpy based solver, the surface temperatures are not explicitly defined, but appear to be obtained from thermo.T() ?
The modified view-factor library simple tries to read a newly defined T_rad field, which is defined by the user in 0/fluid/ directory. The external boundaries should be fixedValue and the other boundaries, such as solid-fluid interfaces or walls should be zeroGradient.
Not sure if this is the right approach; but the the solver seems to ignore this new temperature field.
The other alternative that I could think of was to modify the 'he' in the chtMultiRegionFoam/fluid/EEqn.H according to this newly defined T_rad just for the radiation calculations.

Last edited by Abishek; January 10, 2019 at 17:55. Reason: correction
Abishek is offline   Reply With Quote

Old   January 30, 2019, 20:11
Default
  #3
Member
 
Robert Ong
Join Date: Aug 2010
Posts: 86
Rep Power: 15
rob3rt 0ng is on a distinguished road
I also encounter a similar problem to the above, and would be interested to know the workaround.


Help will be appreciated.


Regards
Robert
rob3rt 0ng is offline   Reply With Quote

Reply

Tags
chtmultiregionfoam, conjugate, openfoam, radiation, radiosity

Thread Tools Search this Thread
Search this Thread:

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


Similar Threads
Thread Thread Starter Forum Replies Last Post
whats the cause of error? immortality OpenFOAM Running, Solving & CFD 13 March 24, 2021 08:15
chtMultiRegionSimpleFoam: Thermal Conduction + Surface-To-Surface Radiation Zeppo OpenFOAM Running, Solving & CFD 16 May 18, 2017 19:04
Temperature dependent propertys and finalIteration in chtMultiRegionFoam waiter120 OpenFOAM 0 February 20, 2013 06:22
chtMultiRegionFoam - exchange data between flow field and temperature phsieh2005 OpenFOAM Running, Solving & CFD 0 February 7, 2012 10:16
An issue with temperature change in unsteady prob Ashok kumar FLUENT 1 January 13, 2009 05:34


All times are GMT -4. The time now is 00:27.