Greetings, all.
Following an entire week in Las Vegas for Lightfair 2010, I am delighted to be home, with wallet and liver both beat up a little bit, but largely intact, and not hooked up to any machines or the like. The end of the week, as many of you know, featured a new Daylight Symposium organized by Lisa Heshong (which was an amazing and heroic event). That I was invited to attend this event, to be a part of the discussion that included many of the best and brightest minds in daylighting, was an honor -- and that is why I write this message with some trepidation, because I hope to not ruffle any feathers here. But I believe that the creation and subsequent misuse of the term “Dynamic Radiance” is leading us toward a blurred distinction between the tools and the techniques of climate-based daylight modeling (CBDM), and that this should be addressed.
As many of us know (and as John Mardaljevic pointed out the other week on radiance-online.org), daylight simulation is at an evolutionary crossroads. Core components of the Radiance toolkit have once again evolved, this time to support climate based daylight modeling (CBDM) in an efficient manner. The resultant new Radiance programs are largely the result of a support effort for the work being done by Lisa Heshong and Heshong Mahone Group in support of the IESNA’s Daylight Metrics Sub-Committee, and this work is being reported on a fair amount these days as the all the pieces of that important research come together. As a result, these new tools that were added to the Radiance toolbox, starting with rtcontrib and ending with all the recent tools developed to make rtcontrib usable by mortals (genklemsamp, dctimestep et al.), ended up getting a generic catch-all phrase for ease of use in discussion and in PowerPoint slides: “Dynamic Radiance”.
With all due respect to Lisa Heshong, I respectfully submit my opposition to the use of this name for these new tools and processes. I understand the need to wrap the new developments into something linguistically tangible; Lisa was one of the first people to have to refer to these new tools in a meaningful way in papers and presentations (and I saw many over the last week and previously). But I would argue that the core tools rtcontrib, genklemsamp and dctimestep are merely the latest additions to that wonderful collection of programs (rpict, rtrace, and over seventy others) which already exists, and for the past two decades has been collectively called, cited, and referenced as, Radiance.
Many times over the course of the Daylight Symposium I heard phrases like “the ‘new version’ of Radiance”, or “…used ‘Dynamic Radiance’ to calculate…”. Maybe I’m being a semantics wonk here, but I do feel we are doing the simulation community a disservice by referring to these new additions to Radiance as a whole new thing, with a whole new name. Indeed, the foundational tool (rtcontrib) for the three-phase CBDM simulation paradigm was initially released five years ago. (!) Rtcontrib and the other new tools were formally released a month or so ago as Radiance v4.0, and I submit to you all that “Radiance Version Four” (Radiance v4.x) is what we should be referring to when we talk of using Radiance at the most basic, “bare metal”, form, to perform daylight coefficient-based annual simulations -- with or without complex fenestration systems (CFS), user interactions, blinds, etc.
Were the tools in Radiance v4.x to be packaged in such a way as to be more easily used, either with a GUI or some sort of web-based frond end, that end result certainly would deserve and require a name like Dynamic Radiance, much like Desktop Radiance was a fitting title for the Windows/GUI project from LBNL, which was a stand-alone program that used Radiance. Today we have Daysim and SPOT and IESve that are also standalone software tools in their own right that use Radiance under the hood or behind the scenes or at its core or around the curtain or whatever phrase you like to use.
Applied in the traditional manner, so-called “Classic Radiance” refers to a single light-backwards raytracing step to solve for global illumination for a single point in time. So-called “Dynamic Radiance” is in actuality not a product or single tool, but the process of using the new Radiance tools to employ a three-phase approach to CBDM; we are still talking about a light-backwards step, albeit this time multiple light-backwards steps to build up matrices for applying BSDFs to simulate CFS in an annual daylighting simulation context. It’s a change in process (and a very important addition in capability), but the tool is the same and should be called the same thing.
Radiance has a marvelous evolutionary history spanning two plus decades; tools, materials and geometry primitives have all been added to Radiance over the years to add functionality to the suite. Yes, some real game changing tools have recently been added to Radiance, but it’s still Radiance. Let’s call the tool what it really is (Radiance v4.x), and agree to another term(s) for the process. Currently, this process is known as the three-phase approach, but I’m sure we can come up with a more interesting/fun one, or five or six that we can all argue over.
Papers will be written and presentations will be given over the coming months and years that discuss this process and its underlying tools. Codes, standards and building rating systems will evolve, adopting these tools and methods as their agents of formulation and refinement, and for determining compliance. All I would like to see are some sensible definitions and usage here.
Respectfully,
Rob Guglielmetti