[Radiance-general] 2.5-phase method and gendaymtx
Zack Rogers
zrogers at daylightinginnovations.com
Thu Feb 6 12:01:27 PST 2014
Hi Axel, et al.,
I have not poured over your script here, and maybe I'm just confused, but I
think what you describe is similar to what can be done in the current
DAYSIM. DAYSIM creates one set of daylight coefficients for the sky
patches and ground (145+3ground) and one set of daylight coefficients for
the direct sunlight positions which typically ends up being anywhere from
60-65 coefficients. The solar coefficients are for every hour for 5 sample
days thoughout the year: the solstices, equinox, and an apr/aug 21 and
feb/oct 21. For orientation or latitude freedom, these could be run for
the broader set of solar locations described in the DDS documents by Denis
Bourgeois (A Standard Daylight Coefficient Model for Dynamic Daylighting
Simulations) but not sure if DAYSIM has this implemented or not. My
projects never seem to have such freedoms ;-)
I still use this method, even with BSDF files, as I feel it better
addresses the sun and is more accurate than spreading that flux over 3
patches as the '3-phase' method does. I have found that using "proper
real" suns can but not always make a difference on results. Even with
dynamic BSDF or other elements, if there are only two-positions (which is
common for me - up or down), I will just run this method for the two
positions rather than resorting to the 3-phase method and the sun smearing
issues.
Perhaps it would be good to really clarify, and define as a community, what
is meant by all these "phases". Here's my two cents. I had always thought
of it as basically "phases of flux transer", not phases of calculation or
number of matrices. I was surprised to hear at the last conference that
"3-phase" came from phases of calculation I think. Although we never count
the final perez sky iteration step as a phase, I don't think. Anyways, I
have always thought about and referred to the different Daylight
Coefficient (DC) methods this way:
1-phase: Original method (maybe implemented in early versions of DAYSIM?)
that simulataes one phase of flux transfer: a set of skypatch-to-calc point
DC's. The sky and solar flux are then both assigned to the patches in an
annual perez sky iteration step.
2-phase: What is currently in DAYSIM. Two phases of flux transfer: one
set of skypatch-to-calculation point DC's and one set of solardisc-to-calc
point DC's. The annual perez sky iterations step then assigns the sky flux
to the patches and the solar flux to the closest 4 sun locations as
described in DAYSIM docs.
3-phase: Method to allow for dynamic facade elements breaking up the
simulation into 3 phases of flux transfer: a skypatch-to-facade element set
of DC's (the daylight matrix), a BSDF file describing the facade element
(the transfer matrix), and a facade element-to-calcpoint set of
coefficients (the view matrix). Like the 1-phase method, the annual perez
sky iteration step assigns all flux to the sky patches including the solar
disc to the surrounding 3. This method is very useful when orientation
freedom is needed and when there are numerous dynamic facade positions to
analyze but is subject to the errors of smearing solar flux into 3 patches
each ~10deg wide. For non-dynamic or even 2 position dynamic and non-BSDF
windows I have always thought of this as a downgrade from the 2-phase
DAYSIM method.
4-phase: When I first heard about a new "5-phase" method being developed -
I thought it would be something like this: basically the 3-phase but with
2 daylight matrices, one for the sky patches and one for the sun locations
(either using the 60-65 sun method or the DDS method). So there would be
one phase from skypatches-to-facade element, another phase of
solardisc-to-facade element, a transfer phase (BSDF files), and a facade
element-to-calcpoint phase. I still think there is potential here,
especially when a dynamic facade is needed but there is no
orientation,latitude freedom to the project. The perez iteration would
then assign sky flux to the sky coefficients and solar flux to the closest
4 positions like in the 2-phase method.
5-phase: What was presented at the last workshop that I am not totally
clear on. From what I understand it is best for fully dynamic facade
elements and full orientation and latitude freedom - best for large
research efforts. A more complete set of solar locations (like the DDS
method) are used but to avoid problems with calculating these many
locations there is a subtraction process to derive them? Sorry, my
understanding of this effort is not extremely clear and I don't have time
at the moment to read up on it. I am sure someone here can clarify.
Anyways, I think it would be nice for me, and the daylight simulation
community, to have a clear understanding of these different annual daylight
simulation methods, their names, and which method is appropriate for which
design problems. On a side note, SPOT implements another climate-based
annual daylight simulation method, coined a Design-Day Interpolation
method, that matches the 2-phase DAYSIM approach very closely and I have
seen less eratic results deeper in spaces with it ( I think because they
are more reliant on the single sky patch they see out a window). This is
what SPOT uses for dynamic shading analysis which is limited to 2-positions.
Sorry, this ran away from me but has been something on my mind for a while
that your question triggered. I would love to hear others take on this and
please correct anything I have misunderstood or mis-stated here. I have
thought about starting an IESNA Daylighting Simulation Sub-committee to
author an LM that nails down all these issues with climate-based annual
daylight simulation, anyone else interested in participating in such a
group? I could write-up a draft PIF (Project Initiation Form) to get the
ball rolling. Or maybe this is just a new effort for the IESNA Daylight
Comittee since the RP-5 is all wrapped up?
Regards,
Zack
On Thu, Feb 6, 2014 at 9:09 AM, Axel Jacobs <jacobs.axel at gmail.com> wrote:
> (Couldn't come up with a sillier subject line for this)
>
> Dear list,
>
> I am trying to use rcontrib and dctimestep in my only-just-invented
> 2.5-phase method. The idea is simple: Instead of relying on the patch
> brightness to represent both sun and sky, I would like to only use the
> patches for the sky, and rely on 'real' suns for an annual simulation.
> This is somewhat related to Andy's 5-phase method, but but I'm still
> at the stage where I have simple windows and no BSDF or Klems stuff.
> What I am hoping to find out is whether the inclusion of 'proper' suns
> makes a difference compared to the old skool rcontrib approach where
> the sky patches represent the sun + sky.
>
> I've tarred up the script and all the input files. They are available
> here:
> http://www.jaloxa.eu/pickup/cbdm4_diffdir.tgz
>
> The script is a bit lengthy:
>
> ---------------------8<-----------------------
> #!/bin/bash
>
> PROJECT="dds4"
> OPT="ab7rtc"
> SKYOCT="octrees/${PROJECT}_sky.oct"
> SUNOCT="octrees/${PROJECT}_sun.oct"
> REINHART=1
> WEA="weather/gatwick.wea"
> NPROC=5
>
> # Sensor results with header
> stmp="tmp"
> if [ ! -d $stmp ]; then
> mkdir $stmp
> else
> rm -f $stmp/*
> fi
>
> wbase=$(basename $WEA .wea)
> fsmx="$stmp/${wbase}_m$REINHART.fsmx" # annual diffuse sky matrix
> dsmx="$stmp/${wbase}_m$REINHART.dsmx" # annual direct sun matrix
> csmx="$stmp/${wbase}_m$REINHART.csmx" # annual combined matrix
> suns="$stmp/suns_m${REINHART}.rad" # annual suns
>
> # Build the diffuse sky matrix for Tregenza subdivision
> # -O1 (total solar irradiance), so we can compare against WEA file
> echo " Building annual diffuse sky matrix $fsmx..."
> gendaymtx -s -m $REINHART -c 1 1 1 -O1 $WEA > $fsmx
>
> # Build the direct suns
> echo " Building annual suns $suns..."
> echo "void light solar 0 0 3 1e6 1e6 1e6" > $suns
> npatch=$( echo 1 |rcalc -e MF:2 -f reinhart.cal -e '$1=Nrbins' )
> cnt $npatch |rcalc -e MF:$REINHART -f reinsrc.cal -e Rbin=recno \
> -o 'solar source sun 0 0 4 ${ Dx } ${ Dy } ${ Dz } 0.533' >> $suns
> gendaymtx -5 -d -m $REINHART -c 1 1 1 -O1 $WEA > $dsmx
>
> # Build direct+diffuse (old skool)
> echo " Building annual combined sun+sky matrix $csmx..."
> gendaymtx -m $REINHART -c 1 1 1 -O1 $WEA > $csmx
>
> echo " Compiling octrees..."
> oconv skies/sky_white.rad > $SKYOCT
> oconv $suns > $SUNOCT
>
> echo "Grid: roof.pts"
> grid=roof.pts
> base=$(basename roof .pts)
>
> skdc="$stmp/${PROJECT}_${OPT}_$base.skdc" # diffuse sky DC
> sndc="$stmp/${PROJECT}_${OPT}_$base.sndc" # direct sun DC
>
> # Run the DDS calculations: Daylight Matrix with header
> echo " Calculating sky DC $skdc..."
> cat $grid \
> |rcontrib -n $NPROC @$OPT.opt \
> -e MF:$REINHART -f reinhart.cal -bn Nrbins -b rbin \
> -o $skdc -m sky_glow $SKYOCT
>
> echo " Calculating sun DC $sndc..."
> cat $grid \
> |rcontrib -n $NPROC @$OPT.opt \
> -e MF:$REINHART -f reinhart.cal -bn Nrbins -b rbin \
> -o $sndc -m solar $SUNOCT
>
>
> fimx="$stmp/${PROJECT}_${OPT}_$base.fimx" # annual diffuse irradiance
> matrix
> dimx="$stmp/${PROJECT}_${OPT}_$base.dimx" # annual direct irradiance
> matrix
> cimx="$stmp/${PROJECT}_${OPT}_$base.cimx" # annual combined
> irradiance matrix
>
> # Produce annual (grey) sensor irradiance matrix
> echo " Calculating annual direct irradiance $dimx..."
> dctimestep -n 8760 $sndc $dsmx |tr '\t' '\n' |sed -e '/^\s*$/d' \
> |rcalc -e '$1=$1' > $dimx
>
> echo " Calculating annual diffuse irradiance $fimx..."
> dctimestep -n 8760 $skdc $fsmx |tr '\t' '\n' |sed -e '/^\s*$/d' \
> |rcalc -e '$1=$1' > $fimx
>
> echo " Calculating annual combined irradiance $cimx..."
> dctimestep -n 8760 $skdc $csmx |tr '\t' '\n' |sed -e '/^\s*$/d' \
> |rcalc -e '$1=$1' > $cimx
>
> imx2="$stmp/${PROJECT}_${OPT}_$base.imx2" # annual sky+sun irradiance
> matrix
> irr="$stmp/${PROJECT}_${OPT}_$base.irr" # annual grey irradiance
>
> # Add direct and diffuse
> rlam $fimx $dimx |rcalc -e '$1=$1+$2' > $imx2
>
> echo -e "month\tday\ttime\tin_dir\tin_diff\tdir\tdiff\tdir+diff\tcomb" >
> $irr
> tail -n +7 $WEA |rlam - $dimx $fimx $imx2 $cimx >> $irr
>
> #EOF
> ---------------------8<-----------------------
>
> There is absolutely no geometry at all--just the sky/suns. The final
> resuls are stored under ./tmp/ in the file with the *.irr extension
>
> here are the first few lines:
>
> month day time in_dir in_diff dir diff dir+diff
> comb
> 1 1 0.500 0 0 0 0 0 0
> 1 1 1.500 0 0 0 0 0 0
> 1 1 2.500 0 0 0 0 0 0
> 1 1 3.500 0 0 0 0 0 0
> 1 1 4.500 0 0 0 0 0 0
> 1 1 5.500 0 0 0 0 0 0
> 1 1 6.500 0 0 0 0 0 0
> 1 1 7.500 0 0 0 0 0 0
> 1 1 8.500 0 19 6.01 6.01 12.02 6.01
> 1 1 9.500 7 51 16.6 16.6 33.2 16.6
> 1 1 10.500 17 88 28.2 28.2 56.4 28.2
> 1 1 11.500 22 109 34.8 34.8 69.6 34.8
> 1 1 12.500 22 110 35.2 35.2 70.4 35.2
> 1 1 13.500 17 91 29.2 29.2 58.4 29.2
> 1 1 14.500 4 56 18.2 18.2 36.4 18.2
> 1 1 15.500 0 6 2.14 2.14 4.28 2.14
> 1 1 16.500 0 0 0 0 0 0
> ...
>
> What I am measuring is the horizontal unobstructed irradiance.
>
> The first five columns are essentially the wea file:
> month day time in_dir in_diff
> to which the following have been laminated:
> dir: gendaymtx -5 -d; no sky, just 145 suns
> diff: gendaymtx -s; no suns, Tregenza patches, only diffuse contribution
> dir+diff: dir + diff
> comb: gendaymtx; no suns, Tregenza patches, diffuse and direct
> contribution. This is old skool for comparison.
>
> I simply cannot make any sense of the results, so I'm wondering
> whether I am misunderstanding the concept behind the -5 option to
> gendaymtx.
>
> Take, for instance, this row:
> 1 1 8.500 0 19 6.01 6.01 12.02 6.01
> There is no direct irradiance recorded in the wea file. Yet, the
> gendaymtx/rcontrib calculation produces 6.01 W/m2 (very low-angle
> sun).
> Also, I don't get why dir = diff = comb ???
>
> I am probably using gendaymtx and rcontrib improperly, but have been
> staring at this for quite a few hours now, without being able to work
> out where I am making the mistakes.
>
> Would anybody be able to offer assistance with this?
>
> I have also tried doing the same think with genskyvec. It doesn't
> complain when I give it the -5 option, but the results are simularly
> confusing.
>
> Many thanks for your help
>
> Best regards
>
> Axel
>
> _______________________________________________
> Radiance-general mailing list
> Radiance-general at radiance-online.org
> http://www.radiance-online.org/mailman/listinfo/radiance-general
>
--
Zack Rogers, P.E., LEED AP BD+C
Daylighting Innovations, LLC
808 S. Public Road, Suite 200
Lafayette, CO 80026
(303)946-2310
www.daylightinginnovations.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.radiance-online.org/pipermail/radiance-general/attachments/20140206/5775adbf/attachment-0001.html>
More information about the Radiance-general
mailing list