[Abishek]

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.

[Abishek]

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.

[rob3rt 0ng]

I also encounter a similar problem to the above, and would be interested to know the workaround.


Help will be appreciated.


Regards
Robert