[TRNSYS-users] Type 34 - Wrong calculation of beam fraction ?

[Marko Brandes]

Dear Matt,
thanks für digging into it... Attached to this mail you will find three files (weather, tpf and results). You can find the results in question at hour 2118 to 2133.
I checked again and again but it stays that way.

Greetings

BLS Energieplan GmbH
i. A. Marko Brandes

Elsenstraße 106
D-12435 Berlin
Tel.: +49 30 53 32 81-0
Fax.: +49 30 53 32 81-40
_________________________________________________________________
BLS Energieplan GmbH
Sitz der Gesellschaft: Berlin
Geschäftsführer: Christoph Lange, Wolfgang Sturm
Registergericht: Amtsgericht Berlin-Charlottenburg, HRB-Nr. 32021

-----Ursprüngliche Nachricht-----
Von: Matt Duffy [mailto:duffy at tess-inc.com] 
Gesendet: Montag, 19. Oktober 2009 20:34
An: Marko Brandes; trnsys-users at engr.wisc.edu
Betreff: Re: [TRNSYS-users] Type 34 - Wrong calculation of beam fraction ?

Dear Marko,

I just ran a simulation with Type34 - very similar to your description -
and got very reasonable results.  Perhaps if you could share location and
time information, I could try and recreate the simulation, or simply the
*.tpf.
Thanks,

Matt


----- Original Message -----
From: "Marko Brandes" <marko.brandes at bls-energieplan.de>
Sent: Fri, October 16, 2009 7:25
Subject:[TRNSYS-users] Type 34 - Wrong calculation of beam fraction ?

Hello TRNSYS users,
using Type 34 (overhang and wingwall shading) with long extensions I ran into
strange results.

>>> The scenario: <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
- Receiver: H = 1m / W = 1m / receiver azimuth = 0 (south)
- Overhang: depth s = 1m / gap d = 0 / extension left e1 = 2m / extension
right e2 = 2m
- Wingwalls: none

>>> Expected results for beam fraction: <<<<<<<<<<<<<<<<<<<
The output beam fraction should be only dependent on receiver an overhang
geometry,
so the results should look like:
- sunrise: starting close to 1, continuously falling
- noon: lowest beam fraction (max. beam shading)
- sunset: continuously rising, ending close to 1

>>> Results from Type 34 for some test data <<<<<<<<<<<<<<<<
|row        |hour        |zenith        |azimuth        |beam fraction
1        6        87,5                -93,5                0,000
2        7        85,2                -88,3                0,791
3        8        76,2                -76,2                0,366
4        9        67,6                -63,2                0,086
5        10        60,0                -48,8                0,124
6        11        54,1                -32,4                0,142
7        12        50,5                -13,9                0,149
8        13        49,8                5,6                0,151
9        14        52,2                24,7                0,146
10        15        57,2                42,0                0,134
11        16        64,2                57,2                0,106
12        17        72,4                70,7                0,164
13        18        81,3                83,1                0,615
14        19        87,5                91,1                0,000

>>> Conclusion: <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Have a look at row 4 and row 5: Type 34 calculates a rising (!) beam
fraction even
though the turning points for zenith and azimuth are not reached yet.
Furthermore the beam fraction rises aftwerwards (less shading) until 1
p.m. This is
even more disturbing as shading should increase with falling zenith angles.

Can someone confirm this or knows what is wrong here?

Greetings from Berlin

BLS Energieplan GmbH
i. A. Marko Brandes

Elsenstraße 106
D-12435 Berlin
Tel.: +49 30 53 32 81-0
Fax: +49 30 53 32 81-40
____________________________________________________
BLS Energieplan GmbH
Sitz der Gesellschaft: Berlin
Geschäftsführer: Christoph Lange, Wolfgang Sturm
Registergericht: Amtsgericht Berlin-Charlottenburg, HRB-Nr. 32021


_______________________________________________
TRNSYS-users mailing list
TRNSYS-users at cae.wisc.edu
https://www-old.cae.wisc.edu/mailman/listinfo/trnsys-users

----- End of original message -----

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Potsdam.tm2
Type: application/octet-stream
Size: 1261501 bytes
Desc: Potsdam.tm2
URL: <http://lists.onebuilding.org/pipermail/trnsys-users-onebuilding.org/attachments/20091020/fc345bfd/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.tpf
Type: application/octet-stream
Size: 84927 bytes
Desc: test.tpf
URL: <http://lists.onebuilding.org/pipermail/trnsys-users-onebuilding.org/attachments/20091020/fc345bfd/attachment-0003.obj>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: analysis.txt
URL: <http://lists.onebuilding.org/pipermail/trnsys-users-onebuilding.org/attachments/20091020/fc345bfd/attachment-0001.txt>