2.5-phase method and gendaymtx

(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

I did not go through all the lines, but don't you want to use the -I swith
in rcontrib!?
(I hope I didn't miss anything in the lines I did not properly work
through...)

Cheers,
David

···

2014-02-06 Axel Jacobs <[email protected]>:

(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&quot; SUNOCT=&quot;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 \\ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\-o &#39;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 &#39;\\t&#39; &#39;\\n&#39; |sed \-e &#39;/^\\s\*/d' \
        >rcalc -e '$1=$1' > $dimx

echo " Calculating annual diffuse irradiance $fimx..."
dctimestep -n 8760 $skdc fsmx |tr &#39;\\t&#39; &#39;\\n&#39; |sed \-e &#39;/^\\s\*/d' \
        >rcalc -e '$1=$1' > $fimx

echo " Calculating annual combined irradiance $cimx..."
dctimestep -n 8760 $skdc csmx |tr &#39;\\t&#39; &#39;\\n&#39; |sed \-e &#39;/^\\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
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general

--
Dipl.-Ing. Dr. David Geisler-Moroder
Hofwaldweg 14/20
6020 Innsbruck
Austria

Arrrg!!! School boy mistake. Thank you for spotting this, David.

here is a snippet from the new results file:

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 0.2066706 18.90211 19.1087806 18.90211
1 1 9.500 7 51 1.282733 50.74105 52.023783 51.63825
1 1 10.500 17 88 6.208754 87.54448 93.753234 91.38906
1 1 11.500 22 109 7.98244 108.4224 116.40484 114.1101
1 1 12.500 22 110 8.004499 109.4393 117.443799 114.9813
1 1 13.500 17 91 6.269868 90.53477 96.804638 94.47253
1 1 14.500 4 56 1.028895 55.71151 56.740405 56.35708
1 1 15.500 0 6 0.07238894 5.968799 6.04118794 5.968799
1 1 16.500 0 0 0 0 0 0

There still is a small residual direct irrdiance from the suns when
dir in the wea file is zero, but I guess I can live with that.
Also, diff+dir is always slightly higher than comb, but overall a
fairly good match.

Thanks again

Axel

···

On 6 February 2014 17:19, David Geisler-Moroder <[email protected]> wrote:

I did not go through all the lines, but don't you want to use the -I swith
in rcontrib!?
(I hope I didn't miss anything in the lines I did not properly work
through...)

Cheers,
David

2014-02-06 Axel Jacobs <[email protected]>:

(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&quot; SUNOCT=&quot;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 \\ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\-o &#39;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 &#39;\\t&#39; &#39;\\n&#39; |sed \-e &#39;/^\\s\*/d' \
        >rcalc -e '$1=$1' > $dimx

echo " Calculating annual diffuse irradiance $fimx..."
dctimestep -n 8760 $skdc fsmx |tr &#39;\\t&#39; &#39;\\n&#39; |sed \-e &#39;/^\\s\*/d' \
        >rcalc -e '$1=$1' > $fimx

echo " Calculating annual combined irradiance $cimx..."
dctimestep -n 8760 $skdc csmx |tr &#39;\\t&#39; &#39;\\n&#39; |sed \-e &#39;/^\\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
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general

--
Dipl.-Ing. Dr. David Geisler-Moroder
Hofwaldweg 14/20
6020 Innsbruck
Austria

_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general

No problem!
The errors in the direct component seem a bit high (at least relatively),
but I guess that is due to the quite low direct values and what the model
behind the calculation makes out of it. I would expect the relative error
to be way lower for higher direct values...

Cheers,
David

···

2014-02-06 Axel Jacobs <[email protected]>:

Arrrg!!! School boy mistake. Thank you for spotting this, David.

here is a snippet from the new results file:

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 0.2066706 18.90211 19.1087806 18.90211
1 1 9.500 7 51 1.282733 50.74105 52.023783 51.63825
1 1 10.500 17 88 6.208754 87.54448 93.753234 91.38906
1 1 11.500 22 109 7.98244 108.4224 116.40484 114.1101
1 1 12.500 22 110 8.004499 109.4393 117.443799 114.9813
1 1 13.500 17 91 6.269868 90.53477 96.804638 94.47253
1 1 14.500 4 56 1.028895 55.71151 56.740405 56.35708
1 1 15.500 0 6 0.07238894 5.968799 6.04118794 5.968799
1 1 16.500 0 0 0 0 0 0

There still is a small residual direct irrdiance from the suns when
dir in the wea file is zero, but I guess I can live with that.
Also, diff+dir is always slightly higher than comb, but overall a
fairly good match.

Thanks again

Axel

On 6 February 2014 17:19, David Geisler-Moroder <[email protected]> > wrote:
> I did not go through all the lines, but don't you want to use the -I
swith
> in rcontrib!?
> (I hope I didn't miss anything in the lines I did not properly work
> through...)
>
> Cheers,
> David
>
>
> 2014-02-06 Axel Jacobs <[email protected]>:
>>
>> (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&quot; &gt;&gt; SUNOCT=&quot;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/\* &gt;&gt; fi &gt;&gt; &gt;&gt; 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 &gt;&gt; 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 \\ &gt;&gt; \-o &#39;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 &gt;&gt; &gt;&gt; echo &quot;Grid: roof\.pts&quot; &gt;&gt; grid=roof\.pts &gt;&gt; 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 &#39;\\t&#39; &#39;\\n&#39; |sed \-e &#39;/^\\s\*/d' \
>> >rcalc -e '$1=$1' > $dimx
>>
>> echo " Calculating annual diffuse irradiance $fimx..."
>> dctimestep -n 8760 $skdc fsmx |tr &#39;\\t&#39; &#39;\\n&#39; |sed \-e &#39;/^\\s\*/d' \
>> >rcalc -e '$1=$1' > $fimx
>>
>> echo " Calculating annual combined irradiance $cimx..."
>> dctimestep -n 8760 $skdc csmx |tr &#39;\\t&#39; &#39;\\n&#39; |sed \-e &#39;/^\\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
>> [email protected]
>> http://www.radiance-online.org/mailman/listinfo/radiance-general
>
>
>
>
> --
> Dipl.-Ing. Dr. David Geisler-Moroder
> Hofwaldweg 14/20
> 6020 Innsbruck
> Austria
>
> _______________________________________________
> Radiance-general mailing list
> [email protected]
> http://www.radiance-online.org/mailman/listinfo/radiance-general
>

_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general

--
Dipl.-Ing. Dr. David Geisler-Moroder
Hofwaldweg 14/20
6020 Innsbruck
Austria

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 :wink:

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 <[email protected]> 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&quot; SUNOCT=&quot;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 \\ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\-o &#39;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 &#39;\\t&#39; &#39;\\n&#39; |sed \-e &#39;/^\\s\*/d' \
        >rcalc -e '$1=$1' > $dimx

echo " Calculating annual diffuse irradiance $fimx..."
dctimestep -n 8760 $skdc fsmx |tr &#39;\\t&#39; &#39;\\n&#39; |sed \-e &#39;/^\\s\*/d' \
        >rcalc -e '$1=$1' > $fimx

echo " Calculating annual combined irradiance $cimx..."
dctimestep -n 8760 $skdc csmx |tr &#39;\\t&#39; &#39;\\n&#39; |sed \-e &#39;/^\\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
[email protected]
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

···

Axel - why do you have:

      npatch=$( echo 1 |rcalc -e MF:2 -f reinhart.cal -e '$1=Nrbins'

)

  instead of

      npatch=$( echo 1 |rcalc -e MF:$REINHART -f reinhart.cal -e

‘$1=Nrbins’ )

  Without deeply understanding the details of your script, this

looks more regular to me.

  The direct contributions are also reduced if 2 is replaced by

$REINHART (being 1 in your script).

  Results file now looks like:

  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  0.03021047      18.90174        18.9319505     

18.90174

  1 1 9.500 7 51  0.8372025       50.73978        51.5769825     

51.65368

  1 1 10.500 17 88        5.439868        87.54065       

92.980518 91.41759

  1 1 11.500 22 109       6.997981        108.4165       

115.414481 114.0331

  Cheers,

  Wouter

  On 02/06/2014 06:55 PM, David Geisler-Moroder wrote:

No problem!

      The errors in the direct component seem a bit high (at

least relatively), but I guess that is due to the quite low
direct values and what the model behind the calculation makes
out of it. I would expect the relative error to be way lower
for higher direct values…

Cheers,

      David

2014-02-06 Axel Jacobs [email protected]:

          Arrrg!!!

School boy mistake. Thank you for spotting this, David.

          here is a snippet from the new results file:


            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    0.2066706    18.90211    19.1087806  

18.90211

          1 1 9.500 7 51    1.282733    50.74105    52.023783  

51.63825

          1 1 10.500 17 88    6.208754    87.54448    93.753234  

91.38906

          1 1 11.500 22 109    7.98244    108.4224    116.40484  

114.1101

          1 1 12.500 22 110    8.004499    109.4393    117.443799  

114.9813

          1 1 13.500 17 91    6.269868    90.53477    96.804638  

94.47253

          1 1 14.500 4 56    1.028895    55.71151    56.740405  

56.35708

          1 1 15.500 0 6    0.07238894    5.968799    6.04118794  

5.968799
1 1 16.500 0 0 0 0 0 0

          There still is a small residual direct irrdiance from the

suns when

          dir in the wea file is zero, but I guess I can live with

that.

          Also, diff+dir is always slightly higher than comb, but

overall a

          fairly good match.



          Thanks again



              Axel




              On 6 February 2014 17:19, David Geisler-Moroder <[email protected]                  >

wrote:

              > I did  not go through all the lines, but don't

you want to use the -I swith

              > in rcontrib!?

              > (I hope I didn't miss anything in the lines I did

not properly work

              > through...)

              >

              > Cheers,

              > David

              >

              >

              > 2014-02-06 Axel Jacobs <[email protected]>:

              >>

              >> (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](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

              >> [email protected]

              >> [http://www.radiance-online.org/mailman/listinfo/radiance-general](http://www.radiance-online.org/mailman/listinfo/radiance-general)

              >

              >

              >

              >

              > --

              > Dipl.-Ing. Dr. David Geisler-Moroder

              > Hofwaldweg 14/20

              > 6020 Innsbruck

              > Austria

              >

              > _______________________________________________

              > Radiance-general mailing list

              > [email protected]

              > [http://www.radiance-online.org/mailman/listinfo/radiance-general](http://www.radiance-online.org/mailman/listinfo/radiance-general)

              >



              _______________________________________________

              Radiance-general mailing list

              [email protected]

              [http://www.radiance-online.org/mailman/listinfo/radiance-general](http://www.radiance-online.org/mailman/listinfo/radiance-general)
      --

                    Dipl.-Ing.

Dr. David Geisler-Moroder

          Hofwaldweg 14/20

          6020 Innsbruck

          Austria
_______________________________________________
Radiance-general mailing list

[email protected]http://www.radiance-online.org/mailman/listinfo/radiance-general

Hi Wouter,

thank you for spotting this. Yep, this is yet another mistake I made. I was trying to boil down my actual, much longer script to the bare minimum. However, but this detail seems to have escaped me.

I'm a little amazed now that the my version worked at all.

Thanks for your help with this.

Best

Axel

···

On 06/02/14 20:44, ascendilex | Wouter Beck wrote:

Axel - why do you have:

     npatch=$( echo 1 |rcalc -e MF:2 -f reinhart.cal -e '1=Nrbins&#39; \) instead of &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;npatch=( echo 1 |rcalc -e MF:$REINHART -f reinhart.cal -e
'$1=Nrbins' )

Without deeply understanding the details of your script, this looks more
regular to me.
The direct contributions are also reduced if 2 is replaced by $REINHART
(being 1 in your script).

Results file now looks like:

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 0.03021047 18.90174 18.9319505 18.90174
1 1 9.500 7 51 0.8372025 50.73978 51.5769825 51.65368
1 1 10.500 17 88 5.439868 87.54065 92.980518 91.41759
1 1 11.500 22 109 6.997981 108.4165 115.414481 114.0331

Cheers,

Wouter

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 :wink:

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 <[email protected] > <mailto:[email protected]>> 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&quot; &nbsp;&nbsp;&nbsp;&nbsp;SUNOCT=&quot;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 &nbsp;&nbsp;&nbsp;&nbsp;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 \\ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\-o &#39;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 &#39;\\t&#39; &#39;\\n&#39; |sed \-e &#39;/^\\s\*/d' \
             >rcalc -e '$1=$1' > $dimx

    echo " Calculating annual diffuse irradiance $fimx..."
    dctimestep -n 8760 $skdc fsmx |tr &#39;\\t&#39; &#39;\\n&#39; |sed \-e &#39;/^\\s\*/d' \
             >rcalc -e '$1=$1' > $fimx

    echo " Calculating annual combined irradiance $cimx..."
    dctimestep -n 8760 $skdc csmx |tr &#39;\\t&#39; &#39;\\n&#39; |sed \-e &#39;/^\\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
    [email protected]
    <mailto:[email protected]>
    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/&gt;

_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general

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 <[email protected]> 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 :wink:

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 <[email protected] >> <mailto:[email protected]>> 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&quot; &nbsp;&nbsp;&nbsp;&nbsp;SUNOCT=&quot;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 &nbsp;&nbsp;&nbsp;&nbsp;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 \\ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\-o &#39;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 &#39;\\t&#39; &#39;\\n&#39; |sed \-e &#39;/^\\s\*/d' \
             >rcalc -e '$1=$1' > $dimx

    echo " Calculating annual diffuse irradiance $fimx..."
    dctimestep -n 8760 $skdc fsmx |tr &#39;\\t&#39; &#39;\\n&#39; |sed \-e &#39;/^\\s\*/d' \
             >rcalc -e '$1=$1' > $fimx

    echo " Calculating annual combined irradiance $cimx..."
    dctimestep -n 8760 $skdc csmx |tr &#39;\\t&#39; &#39;\\n&#39; |sed \-e &#39;/^\\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
    [email protected]
    <mailto:[email protected]>

    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/&gt;

_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general

_______________________________________________
Radiance-general mailing list
[email protected]
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

I can't pretend to understand the inner workings of DaySim, either, but I know there are some differences with rcontrib. These differences will lead one to prefer one or the other depending on simulation needs:

o rcontrib uses a form of pure Monte Carlo to break illumination contributions into any desired number of components. This flexibility allows it to be applied in a wide variety of circumstances, such as the 3-phase and 5-phase method.

o DaySim computes 145 components throughout a more standard application of the Radiance rendering & calculation tools, allowing it to take full advantage of irradiance caching at the expense of some generality.

o rcontrib is a "dumb" but highly programmable tool, and by itself doesn't do anything useful. It currently needs conjoined with a script, cal file or program to make it useful, and a number of these have been written such as genBSDF, genklemsamp, klems_int.cal, etc.

o DaySim includes a complete simulation of daylight control in a single interior space and is much easier to apply in typical situations, but may be harder to adapt to unusual conditions.

I hope this helps. Maybe Christophe can chime in with his thoughts.

-Greg

···

From: Zack Rogers <[email protected]>
Date: February 6, 2014 2:30:48 PM PST

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 <[email protected]> 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

Axel,

This line of your script may be the cause of your problem:

gendaymtx -5 -d -m $REINHART -c 1 1 1 -O1 $WEA > $dsmx

-d works by changing the sky color to 0 0 0. Then the -c option later in
your command negates the -d option by changing the sky color to 1 1 1.

I only know this because I made this mistake in a script I sent to Rick.
Rick discovered that it wasn't working and Greg told us how gendaymtx
actually works.

Andy

···

On Thu, Feb 6, 2014 at 3:08 PM, Greg Ward <[email protected]> wrote:

I can't pretend to understand the inner workings of DaySim, either, but I
know there are some differences with rcontrib. These differences will lead
one to prefer one or the other depending on simulation needs:

o rcontrib uses a form of pure Monte Carlo to break illumination
contributions into any desired number of components. This flexibility
allows it to be applied in a wide variety of circumstances, such as the
3-phase and 5-phase method.

o DaySim computes 145 components throughout a more standard application
of the Radiance rendering & calculation tools, allowing it to take full
advantage of irradiance caching at the expense of some generality.

o rcontrib is a "dumb" but highly programmable tool, and by itself
doesn't do anything useful. It currently needs conjoined with a script,
cal file or program to make it useful, and a number of these have been
written such as genBSDF, genklemsamp, klems_int.cal, etc.

o DaySim includes a complete simulation of daylight control in a single
interior space and is much easier to apply in typical situations, but may
be harder to adapt to unusual conditions.

I hope this helps. Maybe Christophe can chime in with his thoughts.

-Greg

*From: *Zack Rogers <[email protected]>

*Date: *February 6, 2014 2:30:48 PM PST

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 <[email protected]> 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

_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general

Hi Andy,

thanks for sharing this. I did realise that -c affected the sky, but left it in there just in case. Would you happen to know whether genskyvec works exactly the same way as gendaymtx with regards to -d, -5, -s, -c?

Regards

Axel

···

On 07/02/14 00:18, Andrew McNeil wrote:

Axel,

This line of your script may be the cause of your problem:

    gendaymtx -5 -d -m $REINHART -c 1 1 1 -O1 $WEA > $dsmx

-d works by changing the sky color to 0 0 0. Then the -c option later in
your command negates the -d option by changing the sky color to 1 1 1.

I only know this because I made this mistake in a script I sent to Rick.
Rick discovered that it wasn't working and Greg told us how gendaymtx
actually works.

Andy

There's no -5 or -s option for genskyvec. And from what I can tell the -d
and -c options operate differently in genskyvec, so that -c doesn't negate
-d.

Greg, am I right?

Andy

···

On Thu, Feb 6, 2014 at 4:35 PM, Axel Jacobs <[email protected]> wrote:

Hi Andy,

thanks for sharing this. I did realise that -c affected the sky, but left
it in there just in case. Would you happen to know whether genskyvec works
exactly the same way as gendaymtx with regards to -d, -5, -s, -c?

Regards

Axel

On 07/02/14 00:18, Andrew McNeil wrote:

Axel,

This line of your script may be the cause of your problem:

    gendaymtx -5 -d -m $REINHART -c 1 1 1 -O1 $WEA > $dsmx

-d works by changing the sky color to 0 0 0. Then the -c option later in
your command negates the -d option by changing the sky color to 1 1 1.

I only know this because I made this mistake in a script I sent to Rick.
Rick discovered that it wasn't working and Greg told us how gendaymtx
actually works.

Andy

_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general

That's right. With genskyvec, you would give the -s option to gensky, instead. And although there's no reason to specify the sky color with -d, since there is no sky, setting it after -d in genskyvec doesn't turn the sky back on like it does in gendaymtx.

-Greg

···

From: Andrew McNeil <[email protected]>
Date: February 6, 2014 5:21:05 PM PST

There's no -5 or -s option for genskyvec. And from what I can tell the -d and -c options operate differently in genskyvec, so that -c doesn't negate -d.

Greg, am I right?

Andy

On Thu, Feb 6, 2014 at 4:35 PM, Axel Jacobs <[email protected]> wrote:
Hi Andy,

thanks for sharing this. I did realise that -c affected the sky, but left it in there just in case. Would you happen to know whether genskyvec works exactly the same way as gendaymtx with regards to -d, -5, -s, -c?

Regards

Axel

On 07/02/14 00:18, Andrew McNeil wrote:
Axel,

This line of your script may be the cause of your problem:

    gendaymtx -5 -d -m $REINHART -c 1 1 1 -O1 $WEA > $dsmx

-d works by changing the sky color to 0 0 0. Then the -c option later in
your command negates the -d option by changing the sky color to 1 1 1.

I only know this because I made this mistake in a script I sent to Rick.
Rick discovered that it wasn't working and Greg told us how gendaymtx
actually works.

Andy

_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general

_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general

Andy, Greg,

thanks for clarifying this. I've learned a lot tonight. It's time for me to go to bed. Thank you all for your help and feedback. Talk tomorrow.

Best

Axel

···

On 07/02/14 01:28, Greg Ward wrote:

That's right. With genskyvec, you would give the -s option to gensky,
instead. And although there's no reason to specify the sky color with
-d, since there is no sky, setting it after -d in genskyvec doesn't turn
the sky back on like it does in gendaymtx.

-Greg

*From: *Andrew McNeil <[email protected] <mailto:[email protected]>>

*Date: *February 6, 2014 5:21:05 PM PST

*

There's no -5 or -s option for genskyvec. And from what I can tell the
-d and -c options operate differently in genskyvec, so that -c doesn't
negate -d.

Greg, am I right?

Andy

On Thu, Feb 6, 2014 at 4:35 PM, Axel Jacobs <[email protected] >> <mailto:[email protected]>> wrote:

    Hi Andy,

    thanks for sharing this. I did realise that -c affected the sky,
    but left it in there just in case. Would you happen to know
    whether genskyvec works exactly the same way as gendaymtx with
    regards to -d, -5, -s, -c?

    Regards

    Axel

    On 07/02/14 00:18, Andrew McNeil wrote:

        Axel,

        This line of your script may be the cause of your problem:

            gendaymtx -5 -d -m $REINHART -c 1 1 1 -O1 $WEA > $dsmx

        -d works by changing the sky color to 0 0 0. Then the -c
        option later in
        your command negates the -d option by changing the sky color
        to 1 1 1.

        I only know this because I made this mistake in a script I
        sent to Rick.
        Rick discovered that it wasn't working and Greg told us how
        gendaymtx
        actually works.

        Andy

    _________________________________________________
    Radiance-general mailing list
    Radiance-general@radiance-__online.org
    <mailto:[email protected]>
    http://www.radiance-online.__org/mailman/listinfo/radiance-__general
    <http://www.radiance-online.org/mailman/listinfo/radiance-general&gt;

_______________________________________________
Radiance-general mailing list
[email protected]
<mailto:[email protected]>
http://www.radiance-online.org/mailman/listinfo/radiance-general

_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general