[cristina]

Hi all,

I would like to know if it is possible to include a solar radiation boundary condition in the radiation solver (DO model). As far as I have understood the Marshak boundary conditions only allows to set the radiant temperature, and surfaces act as grey bodies so the emit in all directions (difuse radiation)..... Instead, a solar radiation boundary condition should imply a radiation flux and the direction for the rays..... ¿am I right? ¿Any clue if this is possible?

Thanks!

[hanness]

Hi Cristina,

what I usually did was to use the MarshakRadiationFixedTemperature boundary condition for G and greyDiffusiveRadiation for IDefault in the first step. After the first iteration when the individual ILambda_i_0 have been created I identified the rays that should "carry" the solar radiation and changed them to a fixedValue boundary condition on the radiation inlet.

I know that is only a workaround - I was also given a modified greyDiffusiveRadiation called greyDirectedRadiation once which identifies the ray closest to the wanted direction itself but I prefer to do it by hand.

hope that helps...

Hannes

[cristina]

Hi Hannes,

Thanks very much for your response. I am a little mixed up,
so what you did was,
1) you create a zone surface that should be the sun. i.e. sky.
2) And the set the boundary conditions MarshakRadiationFixedTemperature boundary condition for G and greyDiffusiveRadiation for IDefault
3) What about the T file? you put the temperature of the sun in this patch? ? ¿Any temperature?

And after, how do you identify the rays that carry the solar radiation? I made a small try with the hotroom tutorial and I get up to 60 ILambda_i_0 files... and they all seem to carry the same information... I think I didnt undestand this part.

Finally, when you change them to fixed value, ¿what value do you ice ¿the solar radiation, 600w/m2 for example?

Sorry for all this questions!!!!

and thanks again!

cristina

[hanness]

Hi Cristina,

1) on one of your boundary conditions the solar radiation shoul enter, that may be a window in a closed room or one (or more) sides in an external simulation (not the sun, just the side facing the sun)
2) yes
3) T = ambient temperature (eg 300K) - this temperature is primarily important for the convective part - it is the fluid temperature. However, for the directions (ILambda_i_0) which remain greyDiffusive this temperature is also used for the calculation of the blackbody radiation.

In your constant/radiationProperties file you define the discretisation of the DO model (that is the number of rays which equals the number of directions). When you look in to the source code (fvDOM.C) in line 59 to 84 the angles are calculated.

59 for (label n = 1; n <= nTheta_; n++)
60 {
61 for (label m = 1; m <= 4*nPhi_; m++)
62 {
63 scalar thetai = (2.0*n - 1.0)*deltaTheta/2.0;
64 scalar phii = (2.0*m - 1.0)*deltaPhi/2.0;
65 IRay_.set
66 (
67 i,
68 new radiativeIntensityRay
69 (
70 *this,
71 mesh_,
72 phii,
73 thetai,
74 deltaPhi,
75 deltaTheta,
76 nLambda_,
77 absorptionEmission_,
78 blackBody_,
79 i
80 )
81 );
82 i++;
83 }
84 }

(In previous versions of OF the directions were printed on startup but unfortunately they changed it to print only the solid angle of the rays.)
So now you have to identify the correct one and change that one to fixedValue. The value should be whatever you want it to (for example the solar constant =1367 W/m^2 or any lower value due to the absorbtion in the atmosphere).

Hannes

[ankur_garg]

Hi Hannes/Cristina,

Do you have any idea on why they are using (4*nPhi_) for the loops running in fvDOM. And What is the difference between d_ and dAve_ in RadiativeIntensityRay Class, What do they represent? d_ is the direction, I hope and dAve_ is the Directional Weight for each direction?

If you have any idea, how can I better understand the whole source code for Radiation libraries?

Thank you very much.

Regards,
Ankur