7 |
|
[ |
8 |
|
.B "\-n nsteps" |
9 |
|
][ |
10 |
+ |
.B "\-h" |
11 |
+ |
][ |
12 |
|
.B "\-o ospec" |
13 |
+ |
][ |
14 |
+ |
.B "\-x xres" |
15 |
+ |
][ |
16 |
+ |
.B "\-y yres" |
17 |
+ |
][ |
18 |
+ |
.B "\-i{a|f|d} |
19 |
+ |
][ |
20 |
+ |
.B "\-o{a|f|d|c} |
21 |
|
] |
22 |
|
.B DCspec |
23 |
|
[ |
28 |
|
[ |
29 |
|
.B "\-n nsteps" |
30 |
|
][ |
31 |
+ |
.B "\-h" |
32 |
+ |
][ |
33 |
|
.B "\-o ospec" |
34 |
+ |
][ |
35 |
+ |
.B "\-i{f|d} |
36 |
+ |
][ |
37 |
+ |
.B "\-o{f|d|c} |
38 |
|
] |
39 |
|
.B Vspec |
40 |
< |
.B Tbsdf.xml |
40 |
> |
.B Tbsdf |
41 |
|
.B Dmat.dat |
42 |
|
[ |
43 |
|
.B skyf |
51 |
|
vector or matrix, which may be read from the standard input if unspecified. |
52 |
|
The daylight coefficients are multiplied against these sky values |
53 |
|
and the results are written to the standard output. |
54 |
< |
This may be a list of color values or a combined Radiance image, |
54 |
> |
This may be a list of color values or a combined Radiance picture, |
55 |
|
as explained below. |
56 |
|
.PP |
57 |
|
In the second form, |
58 |
|
.I dctimestep |
59 |
|
takes four input files, forming a matrix expression. |
60 |
< |
The first argument is the View matrix file that specifies how window output |
60 |
> |
The first argument is the View matrix that specifies how window output |
61 |
|
directions are related to some set of measured values, such as an array of |
62 |
< |
illuminance points or images. |
62 |
> |
illuminance points or pictures. |
63 |
|
This matrix is usually computed by |
64 |
+ |
.I rfluxmtx(1) |
65 |
+ |
or |
66 |
|
.I rcontrib(1) |
67 |
|
for a particular set of windows or skylight openings. |
68 |
|
The second argument is the window transmission matrix, or BSDF, given as |
69 |
< |
a standard XML description. |
69 |
> |
a matrix or a standard XML description. |
70 |
|
The third argument is the Daylight matrix file that defines how sky patches |
71 |
|
relate to input directions on the same opening. |
72 |
|
This is usually computed using |
73 |
< |
.I genklemsamp(1) |
74 |
< |
with |
75 |
< |
.I rcontrib |
76 |
< |
in a separate run for each window or skylight orientation. |
77 |
< |
The final input is the sky contribution vector or matrix, |
78 |
< |
usually computed by |
79 |
< |
.I genskyvec(1), |
80 |
< |
which may be passed on the standard input. |
63 |
< |
This data must be in ASCII format, whereas the View and Daylight matrices |
64 |
< |
are more efficiently represented as binary float data if machine |
65 |
< |
byte-order is not an issue. |
73 |
> |
.I rfluxmtx |
74 |
> |
with separate runs for each window or skylight orientation. |
75 |
> |
The last file is the sky contribution vector or matrix, |
76 |
> |
typically computed by |
77 |
> |
.I genskyvec(1) |
78 |
> |
or |
79 |
> |
.I gendaymtx(1), |
80 |
> |
and may be passed on the standard input. |
81 |
|
.PP |
82 |
< |
Sent to the standard output of |
82 |
> |
If the input sky data lacks a header, the |
83 |
> |
.I \-n |
84 |
> |
option may be used to indicate the number of time steps, which |
85 |
> |
will be 1 for a sky vector. |
86 |
> |
The sky input file must otherwise contain the number of |
87 |
> |
columns (time steps) specified in each sky patch row, |
88 |
> |
whether it is read from the standard input or from a file. |
89 |
> |
Input starts from the first patch at the first time step, then the |
90 |
> |
first patch at the second time step, and so on. |
91 |
> |
Note that all matrix elements are RGB triplets, so the actual size |
92 |
> |
of the sky vector or matrix is three times the number of steps times |
93 |
> |
the number of sky patches. |
94 |
> |
The |
95 |
> |
.I \-if |
96 |
> |
or |
97 |
> |
.I \-id |
98 |
> |
option may be used to specify that sky data is in float or double |
99 |
> |
format, respectively, which is more efficient for large matrices. |
100 |
> |
These options are unnecessary when the sky input includes a header. |
101 |
> |
.PP |
102 |
> |
Any of the matrix or vector files may be read from a command |
103 |
> |
instead of a file by |
104 |
> |
using quotes and a beginning exclamation point ('!'). |
105 |
> |
.PP |
106 |
> |
The standard output of |
107 |
|
.I dctimestep |
108 |
< |
is either an ASCII color vector with as many RGB triplets |
109 |
< |
as there are rows in the View matrix, or a combined |
71 |
< |
.I Radiance |
108 |
> |
is either a color vector with as many RGB triplets |
109 |
> |
as there are rows in the View matrix, or a combined Radiance |
110 |
|
picture. |
111 |
|
Which output is produced depends on the first argument. |
112 |
|
A regular file name will be loaded and interpreted as a matrix to |
113 |
|
generate a color results vector. |
114 |
|
A file specification containing a '%d' format string will be |
115 |
< |
interpreted as a list of |
78 |
< |
.I Radiance |
115 |
> |
interpreted as a list of Radiance |
116 |
|
component pictures, which will be summed according to the computed |
117 |
|
vector. |
118 |
|
.PP |
119 |
|
The |
83 |
– |
.I \-n |
84 |
– |
option may be used to compute multiple time steps in a |
85 |
– |
single invocation. |
86 |
– |
The sky input file must contain the number of |
87 |
– |
columns specified in each sky patch row, whether it is read |
88 |
– |
from the standard input or from an ASCII file. |
89 |
– |
The columns do not need to be given on the same |
90 |
– |
line, so long as the number of values totals 3*Nsteps*Npatches. |
91 |
– |
Input starts from the first patch at the first time step, then the |
92 |
– |
first patch at the second time step, and so on. |
93 |
– |
.PP |
94 |
– |
The |
120 |
|
.I \-o |
121 |
|
option may be used to specify a file or a set of output files |
122 |
|
to use rather than the standard output. |
123 |
|
If the given specification contains a '%d' format string, this |
124 |
< |
will be replaced by the time step index, starting from 1. |
124 |
> |
will be replaced by the time step index, starting from 0. |
125 |
|
In this way, multiple output pictures may be produced, |
126 |
< |
or separate results vector (one per time step). |
126 |
> |
or separate result vectors (one per time step). |
127 |
> |
If input is a matrix rather than a set of pictures, the |
128 |
> |
.I \-x |
129 |
> |
and/or |
130 |
> |
.I \-y |
131 |
> |
options may be necessary to set the output picture size. |
132 |
> |
If only one dimension is specified, the other is computed based |
133 |
> |
on the number of rows in the result vectors. |
134 |
> |
.PP |
135 |
> |
A header will normally be produced on the output, unless the |
136 |
> |
.I \-h |
137 |
> |
option is specified. |
138 |
> |
Default output format is ASCII text. |
139 |
> |
The |
140 |
> |
.I \-of, |
141 |
> |
.I \-od, |
142 |
> |
or |
143 |
> |
.I \-oc |
144 |
> |
option may be used to specify IEEE float, double, or RGBE (picture) output |
145 |
> |
data, respectively. |
146 |
> |
The |
147 |
> |
.I \-oc |
148 |
> |
option is set automatically if input is a collection of RGBE or XYZE pictures. |
149 |
|
.SH EXAMPLES |
150 |
|
To compute workplane illuminances at 3:30pm on Feb 10th: |
151 |
|
.IP "" .2i |
152 |
|
gensky 2 10 15:30 | genskyvec | dctimestep workplaneDC.dmx > Ill_02-10-1530.dat |
153 |
|
.PP |
154 |
< |
To compute an image at 10am on the equinox from a set of component images: |
154 |
> |
To compute a picture at 10am on the equinox from a set of component pictures: |
155 |
|
.IP "" .2i |
156 |
< |
gensky 3 21 10 | genskyvec | dctimestep viewc%03d.hdr > view_03-21-10.hdr |
156 |
> |
gensky 3 21 10 | genskyvec | dctimestep dcomp%03d.hdr > view_03-21-10.hdr |
157 |
|
.PP |
158 |
|
To compute a set of illuminance contributions for Window 1 on |
159 |
|
the Winter solstice at 2pm: |
160 |
|
.IP "" .2i |
161 |
|
gensky 12 21 14 | genskyvec | dctimestep IllPts.vmx Blinds20.xml Window1.dmx > Ill_12-21-14.dat |
162 |
|
.PP |
163 |
< |
To compute Window2's contribution to an interior view at 12 noon on the Summer solstice: |
163 |
> |
To compute Window2's contribution to an interior view at 12 noon on the summer solstice: |
164 |
|
.IP "" .2i |
165 |
< |
gensky 6 21 12 | genskyvec | dctimestep view%03d.hdr Blinds30.xml Window2.dmx > view_6-21-12.hdr |
165 |
> |
gensky 6 21 12 | genskyvec | dctimestep view%03d.hdr Blinds30.xml |
166 |
> |
Window2.dmx > view_6-21-12.hdr |
167 |
> |
.PP |
168 |
> |
To generate an hourly matrix of sensor value contributions from Skylight3 |
169 |
> |
using a 3-phase calculation, where output columns are time steps: |
170 |
> |
.IP "" .2i |
171 |
> |
gendaymtx -of Tampa.wea | dctimestep WPpts.vmx |
172 |
> |
shade3.xml Skylight3.dmx > wp_win3.dat |
173 |
> |
.PP |
174 |
> |
Generate a series of pictures corresponding to timesteps |
175 |
> |
in an annual simulation: |
176 |
> |
.IP "" .2i |
177 |
> |
gendaymtx NYCity.wea | dctimestep -o tstep%04d.hdr dcomp%03d.hdr |
178 |
> |
.PP |
179 |
> |
To multiply an irradiance view matrix through a pair of XML window layers using |
180 |
> |
a given exterior daylight matrix and sky vector: |
181 |
> |
.IP "" .2i |
182 |
> |
dctimestep Illum.vmx "!rmtxop -ff Blinds1.xml Windo1.xml" Exter.dmx Jan20.sky |
183 |
> |
.PP |
184 |
> |
To multiply two matrices into a IEEE-float result with header: |
185 |
> |
.IP "" .2i |
186 |
> |
dctimestep -of Inp1.fmx Inp2.fmx > Inp1xInp2.fmx |
187 |
> |
.SH NOTES |
188 |
> |
.I Dctimestep |
189 |
> |
optimizes its matrix concatenation by checking for all-zero rows |
190 |
> |
or columns, thus avoiding unnecessary vector multiplications. |
191 |
> |
This can improve performance when a daylight matrix contains |
192 |
> |
zero-filled column vectors corresponding to hours of darkness. |
193 |
> |
.PP |
194 |
> |
It rarely makes sense to specify the |
195 |
> |
.I \-od |
196 |
> |
output option with |
197 |
> |
.I dctimestep, |
198 |
> |
since matrix operations are carried out using 32-bit "float" values. |
199 |
> |
This take less memory, but can also be less accurate than an |
200 |
> |
equivalent invocation of |
201 |
> |
.I rmtxop(1) |
202 |
> |
or |
203 |
> |
.I rcomb(1), |
204 |
> |
which perform all operations on 64-bit "double" values. |
205 |
> |
.PP |
206 |
> |
.I Dctimestep |
207 |
> |
does not accept on input or produce on output Radiance |
208 |
> |
spectral pictures. |
209 |
> |
This is a limitation of the implementation and its underlying |
210 |
> |
data representation. |
211 |
> |
Use instead the similar |
212 |
> |
.I pvsum(1) |
213 |
> |
tool for spectral input and output. |
214 |
|
.SH AUTHOR |
215 |
|
Greg Ward |
216 |
|
.SH "SEE ALSO" |
217 |
< |
genklemsamp(1), genskyvec(1), mkillum(1), rcontrib(1), rtrace(1), vwrays(1) |
217 |
> |
dcglare(1), gendaymtx(1), genskyvec(1), getinfo(1), mkillum(1), |
218 |
> |
pvsum(1), ra_rgbe(1), rcollate(1), rcomb(1), rcontrib(1), rcrop(1), |
219 |
> |
rfluxmtx(1), rmtxop(1), rtrace(1), vwrays(1) |