[Radiance-general] 2.5-phase method and gendaymtx
Zack Rogers
zrogers at daylightinginnovations.com
Thu Feb 6 14:30:48 PST 2014
Hi Axel,
I can't say I fully understand the innerworkings of the DS algorithms but I
believe they are really just an implementation of rcontrib probably similar
to what you are working on. There is a little diddy it uses called
"gen_dc" that automatically generates the skypatch and solar array DC
files. This calls out to an "rtrace_dc" program which I think was the
precursor to rcontrib. It then has a couple programs that use those DC
files to perform annual simulations. One called "ds_illum" which uses the
DC files and a weather file, creates perez sky models and assigns flux to
patches and solardisc locations, and ultimately creates an annual
illuminance file. I would like to see this annual illuminance file format
become a standard as well. All the new dynamic daylight metrics we are
developing can be calculated from this one annual illuminance file and SPOT
creates an identically formatted annual illuminance file.
Regards,
Zack
On Thu, Feb 6, 2014 at 2:11 PM, Axel Jacobs <jacobs.axel at gmail.com> wrote:
> Hi Zack,
>
> I have to admit that calling it 2.5-phase was a bit tounge-in-cheek of me.
> All those different phases keep confusing the living daylight out of me,
> and by reading the posts on this list, others see to share similar
> sentiment.
>
> Anyhow, and I'm glad you pointed this out. My intention with the little
> 2.5p exercise was exactly this--to compare Radiance to DaySim. I have to
> admit that to me, DS is a bit of a black box, but this is probably only
> because I don't use it much.
>
> Also, nailing down a nomenclature of dds terminology is a great idea. I
> think there is much confusion as to what the different methods and software
> packages can and cannot do, so having some overview of capabilities, fields
> of application, accuracy, limitations etc would be great.
>
> And: How about test cases? Has anybody ever compared, say, DaySim
> against Radiance for DDS. There are quite a few clever algorithms that
> only seems to exist in DS, not anywhere else, making a verification of DS
> results against Rad rather challenging. What can DS do that Radiance
> can't, and vice versa?
>
> Best
>
> Axel
>
>
>
>
> On 06/02/14 20:01, Zack Rogers wrote:
>
>> 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
>> <mailto: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
>> <mailto: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 <http://www.daylightinginnovations.com/>
>>
>>
>>
>> _______________________________________________
>> Radiance-general mailing list
>> Radiance-general at radiance-online.org
>> http://www.radiance-online.org/mailman/listinfo/radiance-general
>>
>>
>
> _______________________________________________
> 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/b0a9d944/attachment-0001.html>
More information about the Radiance-general
mailing list