RE[2]: [TRNSYS-users] Types 68 and 34 (shading)

[fdominguezm@uma.es (Fernando Domínguez Muñoz)]

Dear David,

I do not understand the first part of your answer. If I define a
horizontal mask, I get the diffuse (sky) horizontal radiation shaded by
far-away obstacles. You say that this value has to be connected to the
diffuse input (4) of type 34. If I choose mode 2, this diffuse radiation
is multiplied by (1-Fws). At this point I find two problems:

(1) The view factor between the surface and the sky (0.5 in this case)
has never been applied, and type68 does not do it (it calculates shaded
view / full view )
(2) The overhang is obstructing isotropic radiation coming directly from
the sky; it does not obstruct shaded diffuse radiation

I think that the formula (b*) given in the former message is more exact
for the stated problem. In this case type38 should use three diffuse
radiations: 
(a) horizontal 
(b) shaded on the receiver
(c) shaded on the horizontal (so as to approximate the ground reflected
radiation)

The source code (type 34) should be:

OUT(3) = GD-VFsky2*GSH

where,

GD: shaded diffuse radiation on the reveiver (this is the sky diffuse
radiation that reaches a receiver without overhang)

VFsky2: view factor between the surface and the overhang/wingwall =  
OUT(8)+(F12(1,2)+F12(1,3)) --- in my case I have not wingwalls; the
presence of wingwalls complicates the problem (see last message)!

GSH: horizontal diffuse radiation (unshaded)

The second part of the former e-mail points out an apparent incoherence
that helps to understand the problem.

Best regards

Fernando Domínguez Muñoz
University of Málaga (Spain)


>>Dear TRNSYS users,
>>
>>I have some doubts about TYPES 34 (overhang and wingwall shading) and 68
>>(shading by external object) that I would like to discuss with you.
>>These problems are related to the diffuse radiation calculations.
>>
>>In order to model a vertical window with an overhang and a wall in front
>>(of the window), I tried to use types 16, 68 and 34 connected in
>>cascade. The first parameter of type34 changes the way in which the view
>>factors are calculated, being offered the following two choices:
>>
>>(a) If the upstream component is type16, there is no problem:
>>
>>     Sky diffuse on window = Sky diffuse on horizontal * (0.5 ­ Fws)
>>
>>Where Fws = view factor between window and sky (takes account of the
>>overhang and the windwalls)
>>
>>(b) If the upstream component is type68,
>>
>>   Sky diffuse on window = Shaded sky diffuse on window without overhang
>>* (1-Fws)
>>
>>In both cases (a) and (b) I suppose that the sky diffuse radiation input
>>is always the input number 4 of type34. The label in the proforma is
>>somewhat error prone (it says ?sky diffuse on the horizontal?).
>
>the label in the proforma is correct - Type34 always takes the sky diffuse 
>radiation falling on the horizontal. Moreover it assumes an isotropic sky - 
>so the Type16 mode should be set accordingly. If you are using Type68 
>upstream of Type34 then you have a bit of trouble. What you need to do is 
>to define both a horizontal surface and your vertical opening in Type68 so 
>that you can get the total radiation shaded by far-away objects on the 
>horizontal as well as the beam radiation on the surface, which is what 
>Type34 is expecting. I wrote a new version of Type68 that calculates the 
>diffuse radiation on the horizontal automatically and it will most likely 
>be part of the TRNSYS 16.1 release later this year.
>
>>Q1) The geometrical dimensions of the window can be comparable to those
>>of the obstacle in some cases. In this situation strict view factor
>>algebra should be used, but if we use type68 it is not clear where to
>>place the measurement reference for the obstruction angles, because
>>these angles are different for different points on the window. The best
>>place seems to be the centre of the window.
>
>Type68 does not make any assumptions about the point from which the mask is 
>viewed. For relatively small openings, the centre of the window is used. 
>For larger openings such as glass facades, it is more appropriate to break 
>the opening up into multiple smaller openings and to treat them separately.
>
>>Q2) When type68 is used in conjunction with type1 (flat solar
>>collector), I think that the description given in the proforma is error
>>prone, because the total radiation given by type68 does not include the
>>ground reflected radiation, so it should not be directly connected with
>>the total radiation input of the solar collector type. This term can be
>>difficult to calculate when the obstacle is close to the collector (in
>>this case the radiation reflected by the obstacle can be significant),
>>but shall be included anyway.
>
>You are correct that Type68 does not include a ground reflected radiation 
>component. There is an alternative standard Type (Type30) and a non 
>standard Type (Type551) that are designed to calculate the shading effects 
>of a series of parallel rows of collectors. Both of these components 
>include the ground reflected component of incident radiation.
>
>Kind regards,
>   David
>
>
>****************************************************************************************
>Thermal Energy System Specialists (TESS), LLC
>David BRADLEY                           2916 Marketplace Drive - Suite 104
>Partner                                        Madison, WI 53719
>Phone: (608) 274-2577 USA
>Fax: (608) 278-1475
>E-mail: bradley@tess-inc.com
>Web Pages:  http://www.tess-inc.com     and      http://www.trnsys.com
>
>"Providing software solutions for today's energy engineering projects"
>****************************************************************************************
>