[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE[2]: [TRNSYS-users] Types 68 and 34 (shading)
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"
>****************************************************************************************
>