Check it out: http://www.nrel.gov/docs/fy10osti/47522.pdf

It was a thrill to share the half-hour with Kostas Papamichael from the California Lighting Technology Center, and my buddy Mike Plann from Lightlouver. I hope one or two people listen, and are intrigued enough to explore daylighting design, or at least turn off the lights once in a while.

The cool thing is I’m now in the iTunes Music Store. Check it out by listening to the show on the BGBG’s website, or by checking out the podcast on the iTunes Music Store.

Thanks again, Tasha, for having me on the show.

Details here: initial results with rtrace’s multiprocessing feature

9QM93TAVDT59

I had assumed that simulation (real) times would decrease as I increased the number or processor cores allocated to the calculation. The calculation consists of a “grid” calculation of 630 points, sampled for illuminance in a complex daylit space. The simulation command was as follows:

Where {n} represents the number of processors available. The idea was to iterate on the grid points, calculating irradiance, converting to illuminance (in footcandles), and saving to a file, and increasing the amount of processors available to rtrace by one per iteration, up to 15. The system is a Mac Pro with two hyperthreaded quad core Intel Nehalem processors, essentially providing sixteen cores in the same physical system. Radiance jobs on this system have historically scaled nearly linearly when loaded with equivalent Radiance simulations with rpict (rad -n{n}) or mkillum (mkillum -n{n}) jobs. I have to confess ignorance on the effect of setting the horizontal resolution (I don’t fully understand the impact of flushing the output); but rtrace gives a warning about setting -n to a number higher than the horizontal resolution (set with -x), so for this test run I simply set -x = -n. The simulation options set in calc.opt are as follows:
-av 0.2 0.2 0.2 -ar 60 -aa 0.12 -ad 512 -as 256 -ab 4 -dp 256 -ds 0.2 -dj 0.5 -dt 0.2 -dr 1 -dc 0.5 -sj 0.7 -st 0.1 -lr 6 -lw 0.002

Below are the results from my first pass:

As you can see, the real time as reported by the time utility is pretty consistent from 1 to 15 processors. I expected some overhead, but also some speed gains in the real time for the simulation. But this chart shows that the final results take as long with 15 processors as they do with one, and overhead linearly increasing.

Curious about the effect of setting the horizontal resolution (or not), I did a second pass with no -x setting, which means “no output flushing will take place”. Here are the results of that run:

This round shows a slight improvement in real time needed for the simulation, but very slight, and diminishing returns occur almost immediately.

Mainly out out of curiosity (desperation?), I enabled ambient caching for a third run, and those results are shown below (for this run, -x = -n as well, as in the first run; note also the change in time scale):

Here, I’m seeing the trend I would have expected, with a rapid improvement in real execution times, a gradual diminishing return, and a steady increase in overhead as the number of processors increases. I sort-of expected to see a similar graph with no ambient caching, but with a slightly different slope and higher simulation times across the board. Instead, there seems to be almost no net gain in real simulation times.

For ease of comparison, here are all all the real times for all three scenarios plotted:

As a quick gut check, I split the 650-point grid file into two files with 315 points each and ran rtrace once on each file. The end result was that the real time was nearly identical for each run, even though they had half the original number of points. Finally, I did the same calculation on one single point, and that took 3 minutes. I would have assumed the 315 points to take roughly half the time as the 650 points to calculate, and the single point to be computed very quickly. Clearly, there is a flaw in my understanding of how rtrace works, or my test case is not ideal. Probably both.

UPDATE:
As usual, the members of the radiance-online.org mailing list provided swift feedback. Andrew McNeill writes:

“Hi Rob,

When there is no ambient file there is usually an ambient cache created in memory. If you don’t have an ambient file each rtrace process will build its own cache. I’m guessing that each process spends most of the time building the cache with a first point and the subsequent calculations are very quick. Because getting the cache to saturation is the majority of the calculation time and each processor is doing this independently before really getting going on the points it won’t matter if you have 1 or 16 processors, the simulation will take the same amount of time.

To completely turn off the ambient cache use -aa 0. I expect you will see a
linear correlation between number of processes and simulation times, but the
sim times will be much much longer.

On a side note, I’m very jealous of your 16 core mac pro!

Andy”

So, there you have it. The thing to take away here is that one would almost certainly take advantage of ambient caching in normal practice, so of course this new feature of rtrace works great.

Freshly inspired from the recent Radiance Workshop, and cooped up under 22 inches of snow in Boulder, yesterday I took an old web page I created and integrated it into my website. It’s a summary of my first foray into the use of illums on a project. This page dates back to 2003; I’ve been told it’s helpful, so I thought I’d get it back online with all my other crap.

Here’s the link: http://www.rumblestrip.org/interests/light/using-the-illum-material-for-smoother-renderings-in-radiance/

Happy rendering.

Full stats:
rpict user time: 3421
proc: Intel Core 2 Duo
cores: 1/2
clock speed: 2.4 GHz
cache: 3 MB
OS: OS X 10.5.6
Radiance ver: 4.0a
compiler: gcc 4.0.1
compile options: -O2 -ffast-math -funroll-loops
results: 691120680 rays
date: 2008-12-29
submitter: robg

Awards are stupid, until you win one. Yay!

Looking back, it’s interesting because this was the project that finally got me to get over the learning curve of Radiance, as the tools I had been using were simply not up to the job of simulating the daylight and electric lighting in this complex space. This project forced me to learn Radiance, made me jump back to the Apple Macintosh world (because of OSX’s superior UNIX environment), and, ultimately, those skills landed me my current job in beautiful Boulder, Colorado—and now, a couple of industry awards to boot.

Yay!

Scroll down a ways, through all kinds of compu-lighting-geekery, and you will discover that yours truly has added a tiny piece of functionality to a fantastically complex piece of software, software that excels at modeling the ultimate complexity, light.

While I realize that in comparison to all the work done by Greg Ward and several other giants in the Radiance community, my contribution—comprised of nothing more than a little copying and pasting from a shell script, I might add—amounts to the equivalent of a key grip credit on a Hollywood feature, I’m still pretty happy to see my name there, and I appreciate the credit.

Announcer: “Well, THE WAIT IS OVER!! That’s right, now there’s a script that has the ease of use of objview, but is scientifically engineered for use with Radiance light source input files! Plus, if you call now, we’ll include K-Tel’s “70’s platinum hits”—on eight-track—absolutely free! Don’t delay, limited offer, operators are standing by, yadda-yadda-yadda.”

Ahem, sorry. In all seriousness, I took Greg Ward’s objview script and modified it to take a single Radiance scene input file and place it at 0,0,0, then surround it on five sides (top, bottom, E, N, W) with opaque surfaces. It sets -ab 1 and -ds .15 and then loads rview with a view looking into the box. The box is 48 units square by default; you can change the size of the box with the -bs switch. All the other options in objview are available in ltview.

ltview is useful for making sure the distribution of your light source is what you think it is, and that nothing went awry during the ies2rad conversion. It’s also good for checking replmarks triangle orientations.

Download your own copy of ltview here.