Physical building simulations – in other words_ scale models – by leader6


									1 Introduction

Physical building simulations – in other words, scale models – have been part of
architecture since time immemorial. By turning a 2-dimensional concept into a 3-
dimensional physical object, as scale model gives the architect a better idea of how
spaces interact with each other, and how exterior factors interact with space. For
instance, if the photometric properties of the building materials are modeled along with
the geometry, a scale model can predict the interaction of light with the full-scale space.
For this reason, scale models have traditionally been used, not only by architects, but also
by lighting specialists, to determine light levels in a building.

Unfortunately, it is tricky to physically (and accurately) model a lighting situation to
scale. Even if you correctly scale the basic geometry, it is difficult to add enough
detailing (especially regarding fenestrations), and it is difficult to scale the photometric
properties of some materials. Relative photosensor areas (small in a life sized room,
large in a model) can also be a point of inaccuracy. In fact, if a scale model is being used
for quantitative light measurements, overestimation from 25% to +100% is common
[Thanachareonkit et al. 2005, Cannon-Brookes 1997].

Computer simulation, if used correctly can mitigate many of these errors; if provided
with enough scene and sky detail, Radiance, the leading ray-tracing software, has
provided numbers within 5.6% of life measurements [Mardaljevic 1995]. Some of these
programs can even do a photorealistic 3d rendering of the modeled space. Additionally,
computer simulations are often more easily iterative than scale models, as many design
changes would require rebuilding the scale model from scratch. The question remains,
however, do computer simulations, with all their admirable advances, help modern
architects to make better lighting design decisions? To answer that question, it is
necessary to look at the capabilities of modern lighting software tools, to determine
which sector of the building industry is using them, and to ascertain how they are being

2 Existing Tool Capabilities

The field of lighting design software is highly fractured, encompassing an enormous
number of programs, such that it is impossible to find a complete list. Most of the tools
in this review were pulled from the Department of Energy’s Building Energy Software
Tools directory (the lighting-specific portion) with several additions, based on
recommendations or the author’s experience. Quite a few other software lists are
available, however. For instance, William Carroll of LBNL made a software list (as part
of his report for the IEA’s task 21) which overlaps somewhat with the DOE list [Carroll
1999]. Alternatively, the website Lighting Resource ( has its
own list of software including the categories “Lighting Application Design” and
“Lighting Simulation”. Only three of the listed programs overlapped with the DOE list
(AGI32, LesoDIAL, now DIAL-Europe, and Lumen Micro, now Lumen Designer).
Another software list was created and is repeatedly changed and distributed by the
IESNA Computer Committee and distributed through the magazine Lighting Design and
Application. Again, there were few overlaps with the DOE list, although it was implied
that software inclusion was on a producer-voluntary basis, and that only 60 companies
were surveyed. In short, it seemed more like an advertisement opportunity for
commercial programs rather than an exhaustive list.

The most interesting point about the discrepancy between these lists is that they also
serve different audiences. Whereas an engineer or researcher might be more likely to
search the DOE and IEA for information, the LD+A list would probably be seen mostly
by lighting designers and architects. This difference in exposure foreshadows a deeper
split between each group’s approach to the field of lighting. In short, the selection of
tools reviewed in this study were chosen more from a lighting engineering/research
perspective than an architectural one, although a few tools that are popular with architects
were included for the purposes of comparison.

The characteristics which indicate software capability are broken into three major
sections (represented by Tables 2 through 7): design and environmental inputs,
calculation methods, and the output content and the method of display. As a broad
generalization, the complexity allowed in the model input gives an indication of the
intended use of the program and its place in stages of design. Similarly, the analysis
capability of a certain tool is a function of its data output, and the ease of that analysis is
facilitated by the graphic or tabular representation of that output. (For instance, if a tool
is accurate and detailed in output, but is unintuitive, it will rarely be used to its full
potential.) The computation method of a tool is both an indication of output accuracy,
and of which kinds of scenarios are appropriate for that tool to model. The other
information given in Tables 1 and 8 are more general information about the tool and the
sources of information.

        2.1 Inputs

The inputs common to all tools on the chart (but one) are in the form of a building model
and an environmental model. The building model includes the geometric and
photometric aspects of the building plus any artificial lights sources which might exist in
the model. If the software includes daylighting capabilities (which most do) an
environmental model – in the form of a sky model – is included. The main difference
between existing tool inputs can basically be boiled down to the complexity of geometric,
photometric (materials), and sky models allowed by the software, and the range of
existing tools represents innumerable combinations of these model complexities.

The complexities of geometric models range from simple box-like geometries, which
may even be entered numerically rather than graphically, to detail-oriented complex
geometries, which can be modeled in programs such as Radiance or Lightscape. The
category of “simple” models includes such programs as Daylight, for which the only
inputs are wall and unilateral window shapes, sizes, and positions, and DElight, which
allows only box-like geometries. DElight, which was developed by the Lawrence
Berkeley National Laboratory, now seems to be linked to their Building Design Advisor
which, like the MIT Design Advisor, is another good example of software that only takes
simple geometries. Both “Design Advisors”, although they are not dedicated to lighting
only, incorporate some sort of lighting analysis. Both take simple, box-like geometric
models only, but both can take several model variations at a time, and are intended as
early-design tools. In fact, this seems to be a trend within the set of tools that takes only
simpler geometries: either they are a bit older and have not been lately updated, or they
are intended as comparative, decision-making, early-stage design tools. In other words,
they are not meant to give accurate illuminance values for a specific design, but to show
the difference between general design choices (such as the height or glazing type of the
windows), and thus facilitate the architect’s design decisions. This was the motivation
behind programs like the Building Design advisor, whose authors observe:

       Performance prediction is necessary but not sufficient for decision making. The
       true essence of decision-making is evaluation, that is the assignment of
       “goodness” or “appropriateness” to the predicted performance. Since “good”
       and “bad” can only make sense when there are at least two of a kind,
       performance evaluation requires comparison of alternative courses of action.
       [Papamichael, et al., 1997].

The other common model type seen in the tools tables are listed as “complete” models.
Basically, this means that the program allows geometric complexity and some sort of
model detailing, and a good indication of this level of model complexity is whether or not
the tool has the ability to import CAD files. By the importation of CAD files from an
outside program, a piece of software is basically inviting the user to upload as detailed a
design as they wish, and it also offers the implication that this software will try to be as
physically accurate as possible. Software tools such as these seem to be intended for the
later stages of design, when there is already a somewhat complete building design
available, and many of the most basic decisions have already been made. The purpose of
using a design tool at this stage would be to optimize or verify existing decisions, to
fulfill code requirements, to try to predict the actual appearance of the space, or to create
attractive pictures to show clients. Tools in this category include the ubiquitous Radiance
and Lightscape, and also Genelux, Adeline, AGI32, Lumen Micro and its upgrade Lumen
Designer, and the software package from the IES Virtual Environment. Most of them
(especially the newer programs) include a graphical modeling environment, allow CAD
import, or both. The one notable exception to this is Radiance, which was originally
written in Linux, requires designers to enter their models in a sort of Radiance computer
code language, and has no graphical user interface at all. Radiance, however, remains a
popular program by virtue of general faith in its accuracy, and so a vast number of
Radiance user interfaces (such as RayFront and the Radiance Control Panel, which have
been included in the tables below) have been created by outside parties. These interfaces
certainly make Radiance more user-friendly, but may encourage users to surrender
control over many model details. There is also a Radiance interface called Desktop
Radiance, which was made by the Radiance creators as a plug-in for AutoCAD. The
most restricting thing about this interface is that it only works with AutoCAD R14 or
AutoCAD 2000.

Under geometric inputs, the final subset is those tools which are listed as “moderate” in
complexity. This either means that the allowed geometry, though not box-like, is
restricted some way, or that very complex models are unusable in the software
environment and generally crash the system. An example of the former is the veteran
program SUPERLITE, which allows some slants and curves, and an example of the latter
is the program Ecotect which, in the author’s experience, cannot often handle a complex
CAD import without crashing or generally failing in some way. Obviously, programs of
this sort are not advertised as such, so it is possible that more programs in the tools tables
should be listed as “moderate”, but are not because of the author’s lack of personal
experience with that program.

In a lighting simulation program, building materials must also be modeled in some way,
however, the allowed complexity of building materials, and that of geometries does not
always match. As LBNL’s Konstantinos Papamichael observed, “The CAD system and
the simulation tools model the world in totally different ways. The primary goal of a
CAD system is to allow the user to specify and manipulate geometry… [whereas] the
physical model is rich with non-geometric attributes.” [Papamichael et al., 1997] Some
of these non-geometric attributes include the diffuse reflection, specular reflection, and
textural components of materials, and since the majority of light in a space often comes
from indirect inter-reflections, these photometric properties become very important to the
physical accuracy of calculations. For instance, one of the biggest criticisms of the
radiosity method of calculation (discussed below) is that it can only handle diffuse
materials, whereas most materials contain at least some degree of specularity. Because of
this, many radiosity-based programs will include a one-bounce ray-tracing calculation for
renderings with specific views, but in general, this is to make the rendering look more
realistic and does not really have an effect on the illuminance values themselves. Ray-
tracing programs, on the other hand, can handle any type of material description in its
calculations, and so these programs have a far greater potential for material accuracy.
The program Radiance probably has the most potential for accuracy, because one can
program a description for any type of material in existence. For example, every tool but
one listed in Table 3 as having “BT(R)DF” capabilities is based on a Radiance
calculation engine. (BT(R)DF stands for Bi-directional Transmission (or Reflection)
Data Function, and is an empirical set of data describing the exact behavior of light
transmitted through or reflected off of a certain material.) Of course, implementing this
would take a great deal of skill and experience, however, even the Radiance “shortcuts”
for normal materials offer quite a bit of descriptive leeway.

Finally, if daylight is involved in the program, the user must enter some sort of a sky
model. This model, in its simplest form, involves only direct light from the sun, and is
only useful to find cast shadows. Two programs that use a sun-only model are Sombrero
3.01 and Spot (not to be confused with S.P.O.T., the Sensor Placement and Optimization
Tool). More common is some combination of the Uniform sky, which gives every point
in the sky the same luminance value, and the CIE overcast sky, which assumes the sky’s
zenith to be three times the luminance of the horizon. The official definition of “Daylight
Factor” assumes a CIE overcast model, so even tools which allow more complexity in the
sky usually include the CIE overcast sky as an option, making it the most popular sky
model available. One level more complex includes the other CIE models for clear and
intermediate skies. Some programs that offer a combination of these four sky types are
Adeline, AGI32, Building Design Advisor, Ecotect, the IES Visual Environment, and
Lumen Micro/Designer. Lightscape defines its sky model by sun position and percentage
of cloud cover, although this sky model does not take turbidity into account (whereas
other common sky models do). [Inanici 2001]
It is interesting to note that many of these programs allow very complex geometries, but
only very generalized sky models. Part of this is due to the timing of the development
and acceptance of better sky models (although the more accurate Perez sky model was
developed in the early nineties), part is probably due to the general trust in the
Commission Internationale De L’Eclairage as an authority, but it is also probably
indicative of the lower demand for accurate sky models and the relatively higher demand
for accurate building geometries. There is also a computational time cost involved in
modeling complex skies, but this is just as true for complex geometries, so in the end, it
comes down to priorities.

There are a few tools which offer more complex sky models. Genelux allows sky
definitions in up to 5180 patches, and S.P.O.T. uses Typical Meteorological Year
(TMY2) weather data, although they are not explicit in how they use it. Daysim’s
calculation method requires the use of varying weather conditions, so it uses EnergyPlus
weather files, which are modeled using the Perez sky. (Ecotect takes EnergyPlus weather
files as an input for the sun positions, but all they offer in terms of sky model are the CIE
defined skies.) Radiance and Superlite both allow the user to input any sky-irradiance
pattern. This makes them very accurate in specific situations, but it is unlikely the
common user has such information on hand, and it makes the sky cumbersome to model.
Radiance offers quicker shortcuts to the CIE and Perez models [Altmann and Apian-
Bennewitz, 2001], though many Radiance front ends, such as RayFront, allow only CIE
sky modeling capability.

On the subject of inputs, it is important to note that even an accurate program will give
inaccurate results if the model itself is inaccurate in some way. For instance, validations
of the Radiance software have been made against the BRE’s International Daylight
Measurement Programme (BRE-IDMP) dataset, which is an extensive and thorough set
of 1-1 scale illuminance data made on some test rooms with several different complex
fenestration systems in comparison with an identical reference room, and is generally
thought to be the most detailed reference data set in existence [Aizlewood 1993,
Mardaljevic 2001]. The most important aspect of this dataset is the detailed sky
illuminance data which was gathered at the same moment of every set of internal
illuminances. Under these accurately modeled skies, Mardaljevic’s Radiance predictions
for the BRE-IDMP rooms had a mean difference from actual measurements of 5.6% with
a standard deviation of 3.4% [Mardaljevic 1995], although where a CIE sky is used to
provide daylight factors, Radiance has been found inaccurate by about 50% [Ng 2001].
The latter study, however, is more a comment on the inaccuracy of the daylight factor
method than on the accuracy of the RADIANCE program.

       2.2 Calculation Method

Much of lighting research in the 20th century was spent developing geometric and
mathematical hand calculations for light prediction – the development of the Daylight
Factor calculations, for instance, took several decades. [Collins, 1984] One calculation of
this type is the Split-flux method, in which the incoming light is split into a direct
component and a reflected component, and each contribution is calculated according to
the reflectance and other factors of the room in question. A couple of modern programs
still use this method of calculation, including the Building Design Advisor, and DIAL-
Europe. The split-flux method is also used to calculate light in the DOE2 software. The
computation times for hand calculations are basically instantaneous with modern
computer capabilities, but the programs which use these calculations are no more
accurate than the hand calculations themselves.

The other major calculation options are known as “physical modeling”, and the two most
common physical modeling schemes are ray-tracing and radiosity. There is a significant
debate in the lighting software industry over whether radiosity or ray-tracing is a better
method for lighting computation and prediction. Radiance, a Monte Carlo backwards
ray-tracer, is the most recognizable ray-tracer available, and most other available ray-
tracers use Radiance as a calculation base, including Daysim, Adeline, RadianceIES, and
S.P.O.T. One of the only other independent ray tracers on the current list of tools is
Genelux, which is primarily a Monte Carlo forward ray-tracer. The world of radiosity,
which is a finite element method of inter reflection calculation, is more fragmented.
Lightscape is one of the most famous radiosity-based programs, and other big names
include Lumen Micro/Designer, Superlite, Adeline (which fronts both Radiance and
Superlite), and AGI32. Though perhaps not foolproof, case-study comparisons of some
of these tools are interesting way to gain an insight into their strengths and weaknesses.

The most popular comparison to make is between Radiance and Lightscape, and one of
the most thorough papers on the subject was by Kurt Altmann and Peter Apian-
Bennewitz in 2001. They made detailed models of the Kimbell art Museum in Fort
Worth, Texas, in both programs and drew conclusions about the strengths and
weaknesses of each. In brief, they liked the user-friendliness of Lightscape much better
than that of Radiance – of which one of the most common criticisms is that it has no
graphical user interface, nor helps the user in any way. They seemed satisfied with the
level of geometric detail allowed by both programs, but pointed out significant
restrictions in the allowed material definitions in Lightscape. In particular, they were
dissatisfied with the modeling of non-diffuse materials, for although Lightscape allows
definitions of specularity, they are used more for visual effect and not light calculation.
In Radiance, they noted that the basic material definitions looked similar to Lightscape,
but specularity was handled much better, and any material imagined could be modeled
with the right data sets or technical expertise, including any texture or BRDF. They also
noted the much greater complexity of sky model allowed in Radiance. [Altmann and
Apian-Bennewitz 2001]

Where calculations were concerned, Altmann and Apian-Bennewitz concluded that the
Radiance ray-tracing algorithms were “superior” to Lightscape’s radiosity algorithms, “as
they calculate the light transport for surfaces which are not ideally diffusely reflective.”
[Altmann and Apian-Bennewitz 2001] On the other hand, they saw a greater image
quality for shorter calculation time in Lightscape and liked the fact that you could see and
“check on” the image before it finished rendering. They did, however, admit that
comparable quantitative results took a similar amount of computation time for each.
Finally, they warned about several ways in which a Lightscape image might mislead the
user. For instance, Lightscape allows the user to define the appearance of a luminaire
when seen directly in the image, which is a function entirely separate from the light
distribution and intensity from that luminaire when used for calculation. This might
cause the user to ignore potential glare from that luminaire.
Several other comparative studies, while they did not go into as great detail, did look at
programs other than Radiance and Lightscape (although these two were always included).
Harvey Bryan of Arizona State University compared Desktop Radiance, Lightscape,
Lumen Micro, and FormZ RadioZity, Ubbelohde and Humann of U.C. Berkeley
compared Radiance, Lightscape, Lumen Micro, and Superlite, and Mehlika Inanici of the
University of Michigan compared Radiance, Desktop Radiance and Lightscape. [Bryan
2002, Ubbelohde and Humann 1998, Inanici 2001] Although each study had separate
perspectives, they generally agreed on a few points. First, they all found
Radiance/Desktop Radiance to be the most physically accurate software, but also found it
the most difficult to use. Second, that Lightscape was a good photorealistic renderer, but
treated light coming through windows inaccurately. In this case, Bryan concluded that
there must be something wrong with the sun position algorithm, but Inanici pointed out
that Lightscape treats windows as diffuse area light sources, and thus that exterior light
directionality does not get transmitted. [Bryan 2002, Inanici 2001] Ubbelohde and
Humann found Radiance and Lightscape to be much more accurate for their case study
than either Lumen Micro or Superlite, but supposed this to be a fault of the geometric
restrictions of the latter pair, and Bryan found RadioZity to use approximated algorithms
and concluded it was not good for lighting analysis. [Ubbelohde and Humann 1998,
Bryan 2002]

There were a couple papers that obviously championed radiosity over ray-tracing. First,
Ubbelohde and Humann declared that radiosity could be more accurate than ray-tracing,
but did not back up this conjecture. There was also an IBPSA conference paper by
Geebelen and Neuckermans of K. U. Leuven, Belgium which defined ray-tracing as best
for specular materials, point light sources, any geometry, and view-dependant pictures.
They defined radiosity as best for diffuse materials, large area light sources, faceted
geometries, and view-independent renderings, and claimed that since most building
materials are more diffuse than specular, radiosity was the correct direction to take in
lighting software tools. [Gleebelen and Neuckermans 2003] They claimed that even
crude radiosity meshes could be as accurate as ray tracing, but to prove this, they used a
simple example model which was favorable to radiosity and showed none of its

As a summary, Radiance, the most well-known ray-tracer, is widely seen as the most
accurate software available, but also the one that is hardest to use. Lightscape is often
seen as amongst the most accurate radiosity programs, and many people praise the
quickness with which one can get a nice-looking image from Lightscape, although some
have found that to get accurate quantitative results, the rendering times are comparable
for each. On the whole, the restrictive material and sky definitions in Lightscape are
worrying, and the inability to check on Radiance renderings before they are done makes
it difficult to use it to render many design choices for comparison. In short, Radiance
seems to have the most accuracy and attention to detail, while Lightscape and other
radiosity programs are more user-friendly, quicker, and more easily iterative.

One side note must be made about Lightscape. Although it has been one of the most
trusted and popular radiosity-based programs in the past, it has recently undergone a huge
change. Rather than being a stand-alone program, it has now been integrated into
Autodesk VIZ, and must be reevaluated in its current form. The discussion on
Lightscape included in this report refers only to the program as it was before its

       2.3 Output

The output of a tool includes both the information given and the method of its display.
The output of a lighting software tool is usually given in the form of light levels, or other
quantitative measurements of light. The most common output amongst the listed tools is
illuminance (the amount of light reaching a surface), and about two thirds of these also
give output in luminance (the amount of light emitted from a surface). Quite a few
programs also give data in the form of daylight-specific metrics, the most common of
which is Daylight Factor (DF). Although this is the oldest daylighting metric, and
although most daylighting codes (such as LEEDS) are in the form of Daylight Factor, the
lighting research community is beginning to question the value of this metric. For one
thing, it is calculated as a worst-case scenario underneath a CIE overcast sky, which does
not apply to all climates, it ignores things like building orientation, and in general, does
not correlate well with real sky luminances [Mardaljevic 2004]. For this reason, Daylight
Autonomy (DA), a metric that takes the typical climate and building orientation into
account, has been developed in North America, while similar metrics like Annual
Daylight Profiles (ADP) or Annual Daylight Sufficiency (ADS) have been developed
simultaneously in Europe. [Walkhenhorst et al. 2002, Mardaljevic 2000] Daysim, the
Canadian program which coined the DA metric, uses a form of Daylight Autonomy
which calculates light levels every 5 minutes throughout a whole year. [Walkenhorst et
al. 2002] S.P.O.T., created in California and advertised for the California High
Performance Schools (CHPS) program, uses both the traditional definition of Daylight
Autonomy, which does not give credit for light levels under the cutoff, and a different
definition which gives partial credit for lower light levels. [Architectural Energy
Corporation 2006] 3DSolar also uses a DA, but one that is based on daylight factors,
which seems to defeat the purpose of Daylight Autonomy. DIAL-Europe gives
information in the form of ADS.

The existence of glare is another piece of information that only a few programs offer, and
the methodologies are even more scattered than those of DA. Some describe it a
maximum illuminance, and some use more or less standard glare metrics, such as the
Unified Glare Rating (UGR), the Daylight Glare Index (DGI), the CIE Glare Index, the
Guth Visible Discomfort Probability, and the Guth Disability Glare Rating. Where glare
is concerned, there seem to be a lot of different ways to measure it, but none which are
accepted by many as a “standard.” One interesting and unusual glare metric is S.P.O.T.’s
maximum illuminance daylight autonomy, which takes ten times the original target
minimum as its target maximum. [Architectural Energy Corporation, 2006] Basically, it
uses the Daylight Autonomy calculation to find out the frequency and location of very
bright light. Besides glare and illumination, any further information offered by existing
programs tends to be energy-related. For instance, several of the listed tools calculate the
Lighting Power Density, and several others calculate annual energy use or savings.
Although many programs focus on the accuracy of the data, the usefulness of a certain
tool is determined almost as much by its method of data display as by the data itself. In
this age of information overload, we are usually not lacking for information, but for ways
to interpret and filter that information. Similarly, the way data is displayed has a great
effect on a user’s ability to analyze and use that information to its full effect, especially if
that user is not a lighting expert. In the group of existing tools, the normal methods of
data display are as simple as tables of values or as complex as full 3D photorealistic
renderings. It seems that a majority of programs has the ability to produce tables or
bar/line graphs (since they are only lists of numerical calculations), and that graphical
displays relating to the building geometry and light distribution are the usual additional
forms of analysis.

The most common geometric data displays are either 2D graphs, such as a work plane
analysis grid, or they are 3D renderings of the space in question. Both 2D and 3D
geometric displays can include contour lines, false color, or numerical grid overlay
options, but several programs with 3D rendering capabilities also try to make a rendered
picture as photorealistic as possible. Successful programs in the latter category tend to be
highly regarded, and these include the ubiquitous Radiance and Lightscape, Lumen
Micro/Designer, and AGI32. The similar part of the IES package, called RadianceIES,
also does photorealistic renderings. There are also programs like Adeline, Ecotect, and
S.P.O.T. which use Radiance to produce 3D renderings, and some, like Adeline, which
give the user a choice between rendering by Radiance (ray-tracing), or Superlite

The seductive quality of photorealistic rendering lies in the fact that it allows some
qualitative as well as quantitative analysis. It provides a kind of preview of the room’s
lighting that cannot be produced by a grid of numbers, or a contour or falsecolor map.
While those types of displays promote light quantity analysis, like target illuminances or
code compliance, photorealism suggests what the room will actually look like, and it
provides an excellent picture to show clients. Unfortunately, it is also tempting to get
sidetracked by the detailing of photorealism (such as the material colors or finishes)
rather than using it to analyze the lighting.

Although 3D spatial rendering is a relatively common output of lighting software tools,
only a few display temporal information. Daylight, however, is very time-dependant, so
there are a few tools that have chosen to incorporate some information on the transient
nature of lighting. AGI32 includes a “daylight study viewer” which can show sequences
of the same image over multiple days or hours, and Ecotect has a very intuitive and
interactive sun path model, which traces the full year of sun paths in the sky and casts
shadows on the model. Spot, which is mainly a fancy shadow-cast program, does have
an interesting temporal feature: each “spot” chosen can have its “percent daylit”
information displayed in a spreadsheet with times of day on one axis and times of year on
the other. [Bund and Do 2005] In this way, it is easy to see how the light on this spot
changes with the time of day and the season.

3 Existing Tool Utilization
The capabilities of existing software tools are quite diverse, and in some cases,
impressive in their accuracy or their scope. However, the best tool in the world is only as
useful as the skill of the hand that wields it, so it is necessary to look, not only at the
existing tool capabilities, but also at who is using them and how. For this sort of
information, user surveys are very informative – if one reads enough of them, certain
trends can become evident. In this area, 3 papers each summarizing the results of a
different survey were reviewed, as well as one paper which briefly summarized the
results of 10 other surveys. Although these 13 surveys were given by different
organizations with different agendas to different subsets of the user population, there are
remarkable similarities in some of their conclusions, especially on the subject of existing
tool utilization.

The three firsthand summaries reviewed were very different from each other. The first,
chronologically, was an early British Research Establisment (BRE) “Client Report” from
1994 in which Aizlewood and Littlefair surveyed architects, daylight specialists, and
government officials on daylight prediction methods. [Aizlewood and Littlefair 1994]
This survey enquired about the use of hand calculations and scale models as well as those
software tools that were then available. The second survey reviewed was given by
Reinhart and Fitz of the National Research Council of Canada (NRCC) a decade later,
and was a web-based survey whose user pool was drawn from software design tool email
lists. [Reinhart and Fitz, 2004, 2006] In this way, the participants were a bit self-
selecting, but if this is kept in mind, the results were relatively in agreement with that
survey’s contemporaries – many of which were also summarized by Reinhart and Fitz in
their more recent paper. [Reinhart and Fitz, 2006] The third firsthand survey was given
in 2006 by Mark Lawrence of the Harvard GSD. His participants were both students and
practitioners in the field of architecture and did not include (as most other surveys did)
engineers, consultants, or lighting specialists. [Lawrence 2006] It provides a more
focused look at modern architects’ attitude towards lighting design tools than many of the
other surveys.

There are several questions we would wish to answer with these surveys. To begin with,
how many architects actually use lighting design tools, and which ones do they use? In
1994, Aizlewood and Littlefair reported a high use of scale models and hand calculations
amongst both architects and lighting specialists. Of those who did use computer
programs, nearly all listed a different program, showing that even when few programs
were available, the field of lighting software tools was relatively fractionalized. Most of
those surveyed also expressed a lack of faith in the accuracy of the tools available.
[Aizlewood and Littlefair 1994]

A decade later, Reinhart and Fitz claim that this lack of faith has been cured. For one
thing, the collected survey summaries indicate a more recent trust in computer
simulations. [Reinhart and Fitz 2006] Furthermore, their own survey concluded that over
75% less lighting specialists use scale models for lighting prediction, which seems
reasonable as there have been several papers decrying the inaccuracy of scale models.
[Reinhart and Fitz 2004, Thanachareonkit et al. 2005, Cannon-Brookes 1997] It is
important, however, to regard their exact statistic with a bit of suspicion, because of the
self-selection inherent in using software tools email lists as a large part of the user pool.
Another interesting statistic supplied by Reinhart and Fitz is that although they received
342 votes for 42 different simulation tools, about 50% of those votes went to Radiance-
based software. [Reinhart and Fitz 2004] There are a few conclusions that can be drawn
from this fact. First, it indicates that the field of software tools is still fractionalized,
although it seems to indicate that Radiance is the most trusted calculation engine in
existence. On the other hand, one could recall that the majority of ray-tracing programs
have a Radiance base, which means that most of the 50% who did NOT use Radiance-
based tools were probably using a radiosity or hand-calculation tool. It would be very
interesting to see how the users split into categories of ray-tracing, radiosity, and hand
calculations, though the author’s belief is that this statistic still shows a measure of trust
in the accuracy of Radiance which no other single tool can surpass.

A slightly different perspective was gained by Lawrence’s survey, which had a purely
architectural base. Although it does still show greater faith in computers than in times
past (computers were the most popular rendering tool by far), the users surveyed had
relatively little computer experience, in geometric computer modeling and especially in
light rendering. Specifically, over one third of those surveyed did not use light rendering
software, and only 5.5% had used rendering software for more than five years. [Lawrence
2006] Similarly, Reinhart and Fitz had noted a discrepancy between designers and
engineers using computer tools, reaching approximately the same percentage of
architect/designer computer tool users (over 60% of designers claimed to use lighting
computer tools, as opposed to over 80% of engineers and over 90% of researchers).
[Reinhart and Fitz 2004] Unlike Lawrence, however, Reinhart and Fitz did not ask the
users’ level of experience with these programs.

As in the previous example, one noticeable trend in all the surveys available was the
discrepancy between the tools chosen by designers and engineers. As Reinhart and Fitz
discovered, engineers and researchers were quite a bit more likely to use a computerized
simulation method, and there was support for this fact in the surveys they summarized as
well. In 1996, Robinson noted a tendency for architects to chose simple tools, while
engineers chose more complex and detailed tools, although “both groups believed their
simulation errors to be minimal.” [Reinhart and Fitz 2006] Two years later, a survey was
given in Singapore by Lam et al. in which most users expressed the belief that
daylighting software was a tool only for the lighting specialist. From these and the other
surveys summarized, Reinhart and Fitz concluded that “detailed simulation tools remain
the domain of engineers.” [Reinhart and Fitz 2006] This conclusion merely confirms the
observation which had motivated their survey – that although computerized lighting
prediction software had been available for more than 15 years, it was not being fully
utilized by the realm of building design.

The fact that most architects seem to prefer simple computer tools (or none at all) and
engineers seem to prefer detailed tools is made more interesting by Robinson’s follow-up
observation that both groups used these computer tools at the same stages of the design
process. This observation, from the point of view of tool developers, “went against
common belief that simplified tools are synonymous with pre-design tools, whereas
detailed tools are used at more mature design stages.” [Reinhart and Fitz 2006] It seems
that the next question which must be asked is: What is the difference between a tool’s
intended use and the way in which it is actually used? The unanimous answer was that
computer tools are mainly used in the later stages of design, while an architect will rely
largely on previous experience, rules of thumb, handbooks, or case studies when making
early design decisions. This was particularly supported by Donn’s 1996 survey in the
USA and New Zeeland, De Wilde et al. in the Netherlands, and Pilgrim et al. in Great
Britain (1999). [Reinhart and Fitz 2006] Furthermore, De Wilde and Pilgrim found that
all computer software, no matter its complexity or intended purpose, seems to be mainly
used for design validation, code compliance, and optimization procedures. [Reinhart and
Fitz 2006] In their own survey, Reinhart and Fitz found that tools were primarily used
(in order of frequency) for choosing a shading controls/type, sizing windows, choosing a
glazing type, choosing lighting controls, deciding building orientation, analyzing interior
surface properties, and optimizing room dimensions. [Reinhart and Fitz 2006] This list
seems the reverse order of one that might be made by tool developer.

One final piece of information which may be extracted from user surveys is a list of what
would make the ideal tool from the designer’s or engineer’s point of view. In 1994,
Aizlewood and Littlefair’s participants were concerned about tool reliability and showed
an interest in shading analysis. In general, they wished for tools which were easier to
use, less expensive, and more compatible with CAD software. [Aizlewood and Littlefair
1994] Although users seem more satisfied with the accuracy of computer tools, many of
their wishes have remained unchanged throughout the years. Like their predecessors,
Reinhart and Fitz found that users generally wanted better documentation and training
along with tools that were easier to use with improved and more intuitive interfaces.
Another similarity was the continuing request for better links to CAD software. Users
also desired better quality assurances and self-checking routines, and automated routines
to help chose daylighting or shading devices. [Reinhart and Fitz 2006] The participants
in Lawrence’s recent study also overwhelmingly asked for a combination of ease of use
and quick renderings. On the subject of accuracy, some people favored greater accuracy
in programs, but there were significant requests for “quick and dirty” ballpark solutions
to help move the architect faster through design iterations. [Lawrence 2006]

In summary, all of the surveys considered (both primary and secondary sources) tended
towards similar conclusions. The first of these is that, despite gaining ground amongst
engineers and lighting specialists, lighting simulation tools are underutilized by architects
and other designers. Furthermore, when they do use computer tools, architects tend
towards simpler tools while engineers prefer the more detailed, and often more accurate,
tools. This is hardly surprising as most users are self-taught, and most computer tools are
written by engineers and are therefore probably more intuitive to engineers. Certainly,
the most provably accurate tool, Radiance, is also the least user friendly, and those
graphical front ends created for Radiance often come at the expense of much of the
detailed control for which the original program is known. It is notable that both types of
users mostly limit their computer simulations to the later stages of design, primarily for
the purpose of optimizing previous design decisions. It is also notable that the vast
majority of existing tools facilitate this pattern of use, as most of them (especially the
most popular) focus on accurate renderings of detailed spaces and most allow the
importation of complex geometries. The continuous user “wish” for better CAD
importation facilities is also an indication that most users intend their computer
simulations for the later stages of design, after a complete CAD model has already been
constructed and many design decisions made. On the other hand, it is encouraging that
several participants in Lawrence’s survey indicated an interest in “quick and dirty”
renderings. By their very nature, these kinds of calculations lend themselves to the early
part of the design process.

4 LightSolve Goals

If we draw no other conclusions about the state of the art of lighting computer simulation
tools, we must acknowledge that the field is, in some ways, very fractionalized. There
are so many tools in existence that it would be no small feat to list them all, nor has the
author found evidence that anyone has ever done so. It is therefore a good idea to
examine the intended niche of any proposed new tool before adding one more program to
the lists. For the sake of comparison, an ideal, theoretical LightSolve entry has been
added to Tables 1-7, and specifics in the areas of “input”, “calculations”, and “output” are
discussed below, in comparison with those of existing tools.

LightSolve will be intended as an early design tool which is meant to appeal first to
architects. This means that, unlike the majority of existing programs, LightSolve should
take a moderately complex building geometry. There is a balance to be found between
giving too much detail (for nothing slows down computations like an excess of detail)
and in only allowing geometry so simple that the architect must confine design
exploration to rectangular forms. The greatest pitfall from this perspective is allowing
geometric CAD imports. User surveys indicate that architects almost universally desire
good links to CAD or other geometric modeling software, but facilitating good CAD
imports may involve allowing more complexity than is in the program’s best interest. On
the other hand, if a tool is aimed at architects and architects desire good CAD links, then
a program without CAD import abilities might repel its intended audience. The ideal
situation would be for LightSolve to allow CAD import, but to be able to simplify it in
some way. This idea, however, comes with significant implementation problems.

The photometric properties of materials have a great effect on the distribution of light in a
space, so LightSolve should allow a relative complexity of material definitions. For
opaque surfaces, the basic Radiance definitions would be ideal, as they include both
diffuse and specular reflectance coefficients. The same is true for the Radiance definition
of glass, which includes index of refraction plus RGB transmission coefficients. (In fact,
the early prototypes of LightSolve will probably use Radiance material definitions, as
Radiance is intended to be the first calculation engine as well.) On way in which
LightSolve may be considered unusual could be in its intended treatment of complex
fenestration systems (CFSs). CFSs, as the name states, are complex in either materials or
geometry, and their explicit modeling inside a simulation would greatly increase the
rendering time. One idea, therefore, is to treat them as a black box whose “material”
definition is a BT(R)DF – in this way, the distribution of light could be drawn from a data
file, rather than a costly physical modeling simulation.

The sky model intended for use in LightSolve is the Perez model used by Daysim. As
discussed above, the uniform and CIE clear, cloudy, and overcast skies are not accurate
enough to represent the changes over the year and in different weather types. Like
Daysim, LightSolve should do calculations under the skies for different times of day and
year, but not to make those calculations every five minutes. Rather, the intention is group
the year and the day into sets of similar moments. Currently, the idea is to divide the
sunlight hours (however long they may be) into seven groups, and to split the year into
eight pieces, using equinoxes and solstices as markers. This would result in the
calculation of 56 moments, although there would only be 28 unique sun positions.

The one aspect of LightSolve which is not really represented in the existing tools tables is
the idea of goal-based inputs. This is the idea that one could approach the program with
some model constraints and some lighting goals, and the program would, though genetic
optimization algorithms and databases of lighting logic, help the user meet those goals.
In fact, the only program which touches on goals at all is EcoAdvisor, a web-based
program which cannot be truly considered a simulation tool, but is more of a teaching
tool. EcoAdvisor, which is still under construction, is a website which pulls the user
through a series of scenarios intended to instruct the user in better daylight practice. For
instance, on one page, the user may change the room depth/height ratio, on another the
user plays with window shading and transmissivity, and on another the user sees how
office cubicle partitions affect light propagation. Pre-done Radiance renderings illustrate
the difference between options. While this program is not a rendering tool, it is the only
program found which incorporates the ideas of goal-based design. It should not be
surprising that the only such tool is meant as a teaching tool, for hopefully LightSolve
will be a sort of daylighting expert, giving advice to users and helping them to learn
better daylighting practice through the process of optimizing design decisions.

As for the intended method of calculation, LightSolve will start with a Radiance
calculation engine, with the hopes of it being altered slightly and made quicker. Speed of
rendering seems to be very important to users, and as such, one cannot entirely throw out
the idea of using a radiosity base. However, great simplification of materials that
radiosity requires is discouraging, so hopefully LightSolve can end up using an optimized
form of ray-tracing.

Besides goal-based inputs, the most unique niche that LightSolve intends to fill is that of
graphical spatio-temporal outputs. As mentioned above, the transient nature of daylight
is only touched on by a couple programs, and none of them provide a graphical output
through which both temporal trends and spatial renderings can be accessed. The intended
time-based displays derive from Mardaljevic’s spatio-temporal graphs [Mardaljevic
2004a]. On these graphs, seen in the figure below, it is easy to see how the data that is
being displayed varies both over the course of the year and over the course of the day.
Obviously, for the sake of these graphs, any information displayed will have to be
condensed to one value per instance. For example, illuminance might be given as a
percentage of the workplane over a target illuminance, and this number could be
displayed as a color on the spatio-temporal map. Furthermore, if one clicks on the map,
it is intended that a 3D rendering which corresponds to that instant in time will appear to
the side of the map, or that the user could click on a full day and get a slideshow or
animation of the space as it changes through the day. Finally, it would be desirable for
the output to produce a summary in the form of three pictures – one would represent an
average or common moment during the year, one would represent a best-case moment,
and the third would represent a worst-case moment. The user could then compare a best,
worst, and average scenario in the configuration that they were testing, which would give
them a more complete understanding of that space’s performance.
In conclusion, LightSolve should be a program with some features that are not common
to many existing programs. Most particularly, the proposed LightSolve would be nearly
unique in its goal-based input approach and in its treatment of the temporal aspects of
daylighting, which, being highly graphical in nature, would hopefully appeal to
architects. Challenges for LightSolve will probably include balancing between
complexity and calculation speed and convincing architects to use it in the earlier stages
of design with a simplified model. Early stages of the program, as noted above, will
probably use a Radiance calculation base and input files so that the program’s form and
lighting database may be developed at the same time as the calculation optimization.

The object of the proposed software tool LightSolve is to help architects make better
early design decisions about light by taking their lighting goals as input and by making
the output highly graphical and easily understood. Many existing tools encourage use in
the later stages of design, by requiring complex inputs and advertising accurate outputs,
and many users, by their own admission, use even those tools intended for early design
decisions during the later stages of design to verify, not to make, decisions. It is the
author’s hope that LightSolve can help to change some of these practices and to
encourage good lighting design decisions throughout the architectural community.

                 Figure: A conceptual design of the proposed 2-D temporal output.
Appendix A: Tools Tables

Table 1: Basic Info
               Tool Name                Product State                Focus                     Creator           IEA task 12 = International research team
    3DSolar/RayFront(Radiance UI)         supported           Lighting/Daylighting              Alware           (Fraunhofer-Institut für Bauphysik (current
                  Adeline                 supported           Lighting/Daylighting           IEA task 12         distributer/support), Bundesministerium für
                   AGI32                  supported           Lighting/Daylighting      Lighting Analysts, Inc   Wirtschaft und Technologie, Projektträger
        Building Design Advisor            updating       Lighting/Daylighting/Energy            LBNL            Biologie, Energie,Umwelt des
                 Daylight                  updating                Daylighting            Troy Nolan Peters      Bundesministeriums für Wirtschaft und
                  Daysim                   updating                Daylighting                NRC-IRC
                                                                                                                 Technologie, LBNL, EPFL, IEA, University of
                  DeLight                   writing     Lighting/Daylighting (Thermal)           LBNL
    DIAL-Europe (was LESODIAL)            supported                Daylighting                   EPFL
                  DIALux                   updating           Lighting/Daylighting                Dial
     Eco Advisor (in development)           writing     Training (Lighting/Daylighting) The Deringer Group       LBNL = Lawrence Berkeley National
               Eco Lumen                   stagnant                 Lighting                Tata Infotech        Laboratory
                  Ecotect                  updating       Lighting/Daylighting/Energy        Square One
            FormZ RadioZity               supported           Architectural Design       formZ, LightWorks       NRC-IRC = National Resarch Council
                 Genelux                  supported           Lighting/Daylighting         CNRS-ENTPE            (Canada) – Institution for Research in
              IES - FlucsDL               supported                Daylighting                    IES            Construction
             IES - FlucsPro               supported           Lighting/Daylighting                IES
             IES - LightPro               supported     Lighting (luminaire placement)            IES            EPFL = École Polytechnique Fédérale de
   IES - RadianceIES (Radiance UI)        supported           Lighting/Daylighting                IES            Lausanne
                  Inspirer                supported                 Lighting                    Integra
                Lightscape                supported           Lighting/Daylighting          Autodesk, Inc        CNRS – ENTPE = Centre National de la
        Lightswitch Wizard, The           supported          Daylighting/(Lighting)           NRC-IRC
                                                                                                                 Recherche Scientifique – École Nationale des
         Lumen Micro/Designer             supported          Lighting/(Daylighting)
          MIT Design Advisor               updating           Energy (Daylighting)                MIT
                                                                                                                 Travaux Publiques de l’Etat
           Radiance (Linux)                updating           Lighting/Daylighting       LBNL (Greg Ward)
 Radiance Control Panel (Radiance UI)     supported          prepare Radiance run            Square One          IES = Integrated Environmental Solutions
    S.P.O.T. sens place. & opt tool       supported      Lighting/Daylighting/Sensors            AEC
                 Sketchup                 supported        Architectural Design (sun)                            AEC = the Architectural Energy Corporation
                Sky Vision                supported          Daylighting (Skylights)          NRC-IRC
             Sombrero 3.01                supported              Solar Shading           Universität Siegen      Notes: The funding to Eco Lumen was cut
                    Spot                   updating                Sunlighting            U. of Washington            Lightscape is now part of Autodesk VIZ
            SUPERLITE 2.0                unsupported          Lighting/Daylighting               LBNL                 Ecotect includes Radiance Cntrl Panel
                   Visual                 supported                 Lighting                AcuityBrands              DeLight is attatched to the BDA
        Ideal LightSolve Profile           writing           Lighting/Daylighting               MIT
Table 2: Geometry Input
               Tool Name                          Libraries/Databases                    Geometric Complexity                    Input Method
    3DSolar/RayFront(Radiance UI)                  Materials/luminaires                         moderate             menu build, CAD import to RayFront
                  Adeline               EDITABLE object/material/color/luminaire/CFS            complete             num build, CAD build, .dxf, .rad, .mod
                   AGI32                          Object/Material/import                        complete                   graphical build,DWG,DXF
        Building Design Advisor                object/custom/default values                       simple                    basic geometry/operation
                 Daylight                             simple windows                          VERY simple                     box geometry(graph)
                  Daysim                           few Energy Plus files                        complete                  geom.rad, mat.rad, sens.pts
                  DeLight                                                                     VERY simple                     box geometry (DOE2)
    DIAL-Europe (was LESODIAL)          DaylightRules/case studies/4 shading devices              simple                    simple build (num,graph)
                  DIALux                        materials/luminaires/objects                    moderate                            menu build
     Eco Advisor (in development)                            n/a                          Goals (no real input)                         n/a
               Eco Lumen                                    none                              VERY simple                        basic geometry
                  Ecotect                      Materials/Cad/Object/Luminaire          moderate (complex crashes)       simple graphical build,3DS,DXF
           FormZ RadioZity                        objects/shapes/materials                      complete                  graphical build/ CAD imports
                 Genelux                           hourly skies/luminaires                      complete                  coded geometry,CAD import
              IES - FlucsDL                    construction/weather (custom)                    complete                   VE 3D model (IES specific)
             IES - FlucsPro                       luminaires from LightPro                complete/light criteria          VE 3D model (IES specific)
             IES - LightPro                      luminaires/lamps (custom)                      complete                   VE 3D model (IES specific)
   IES - RadianceIES (Radiance UI)                     LightPro library                         complete                   VE 3D model (IES specific)
                  Inspirer                materials/textures/objects/light sources              complete           graphical build/ DXF, other imports
                Lightscape                                                                      complete                               DWG
        Lightswitch Wizard, The                    user behavioral rules                VERY simple/pre-defined           simple build(menus-limited)
         Lumen Micro/Designer                   luminaires/objects/materials           moderate(micro)/complete(d)     simple build, CAD env/DWG/DXF
          MIT Design Advisor                                                                  VERY simple                   simple build (num, menu)
           Radiance (Linux)                               default values                        complete                  coded geometry, define mat
 Radiance Control Panel (Radiance UI)                          n/a                              complete                            .RAD, .RIF
    S.P.O.T. sens place. & opt tool              luminaires/RAD default val                     moderate                       box geometry(num)
                 Sketchup                         no connection with lighting                   complete              graphical build/imported 3d model
                Sky Vision                      glass (trans, abs, refl, SHGC)           skylight geom/spacing                 box geometry(num)
             Sombrero 3.01                                    none                                simple                       simple build(graph)
                    Spot                                      none                              complete                    "Sketched" in "spacepen"
            SUPERLITE 2.0                                     none                              moderate                          text geometry
                   Visual                         refl, few web photometrics                simple/complete             graphical build/CAD,DWG,DXF

        Ideal LightSolve Profile           Logic/rules of thumb/Daylight rules/CFS              moderate                      simple build or import
Table 3: Materials Input
                                            Diffuse                     Other                    Texture or "Texture"                           Other          Refractive   Luminance
               Tool Name                    Reflect    Specularity      Reflect        BT(R)DF "roughness" Pattern       Transmittance         Transmit          Index       or "glow"
    3DSolar/RayFront(Radiance UI)            RGB        yes [0-1]                      BT(R)DF    yes [0-1]    yes            RGB                                 yes           yes
                  Adeline                color samp       yes          "spread"       BTDF (CFS)                           color samp          "spread"
                   AGI32                     RGB          yes*        color bleed                             yes**       yes (no info)                                        yes
        Building Design Advisor               yes                                                                              yes
                 Daylight                    fixed                                                                        0.2, 0.7, 0.8
                  Daysim                     RGB        yes [0-1]                      BT(R)DF      yes [0-1]    yes          RGB                                 yes          yes
                  DeLight               ave grayscale*                                BTDF (CFS)                           (as BTDF)
    DIAL-Europe (was LESODIAL)            qualitative*
                  DIALux                   grayscale                                                             yes        grayscale        pollution fact.
     Eco Advisor (in development)          grayscale                                                                        grayscale
               Eco Lumen
                  Ecotect               Hex, gray, RGB      yes                                        yes                  grayscale                             yes
           FormZ RadioZity                    yes                                                                yes
                 Genelux                     RBG           RBG                                                                RGB
              IES - FlucsDL                   yes                                                                             yes
             IES - FlucsPro                   yes                                                                             yes
             IES - LightPro                   not        applicable
   IES - RadianceIES (Radiance UI)           RGB          yes [0-1]                    BT(R)DF*     yes [0-1]    yes*           RGB                               yes*         yes*
                  Inspirer                    yes           yes     RGB HVS XYZ                                                  yes                              yes           yes
                Lightscape                RGB, HVS       yes [0-2]* shininess[0-1]*      none      smoothness*   yes    [0-1] transparancy                      [1-2.5]*    yes [cd/m2]
        Lightswitch Wizard, The           grayscale                                                                          grayscale
         Lumen Micro/Designer                 yes           yes         "funky"                        yes                       yes
          MIT Design Advisor            grayscale 30%                                                                     couple choices
           Radiance (Linux)                  RGB         yes [0-1]                     BT(R)DF      yes [0-1]    yes            RGB                               yes          yes
 Radiance Control Panel (Radiance UI)        RGB         yes [0-1]                     BT(R)DF      yes [0-1]    yes            RGB                               yes          yes
    S.P.O.T. sens place. & opt tool       grayscale                                                                          grayscale
                 Sketchup                     not        applicable
                Sky Vision                    yes                                                                              yes
             Sombrero 3.01                    not        applicable
                    Spot                      not        applicable
            SUPERLITE 2.0                     yes                                                                        couple choices
                   Visual                 grayscale                                                                        grayscale

        Ideal LightSolve Profile            RGB             yes                        BT(R)DF        yes        yes          RGB                                 yes          yes
Table 4: Sky Input
                                        Sun-Only                CIE         CIE           CIE       (EnergyPlus)   User-Defined
               Tool Name                (or none)   Uniform   Overcast     Clear     Intermediate      Perez       Luminances Other
    3DSolar/RayFront(Radiance UI)                               yes         yes           yes                                   editable
                  Adeline               sun only      yes       yes         yes                                                 Average Skies (from data)
                   AGI32                                        yes         yes          yes                                    IES, CIE-AS
        Building Design Advisor                                 yes         yes
                 Daylight                             yes
                  Daysim                                                                                yes
                  DeLight                                                                                                        TMY2 weather, pre fixed sun positions, cloud fraction
    DIAL-Europe (was LESODIAL)                                  yes                                                              horizontal sky luminance det. by Euro local averages
                  DIALux                                        yes         yes          yes
     Eco Advisor (in development)                               yes      sometimes
               Eco Lumen                  none
                  Ecotect                                       yes         yes          yes
            FormZ RadioZity             sun only
                 Genelux                                                                                                         up to 5180 patches,var modls, genl Eur wea zones
              IES - FlucsDL                           yes       yes
             IES - FlucsPro                           yes       yes
             IES - LightPro               none
   IES - RadianceIES (Radiance UI)                              yes         yes          yes                                     "internat recog sky cond"
                  Inspirer                none
                Lightscape                                                                                                       defined by amt covered by clouds + sun position
        Lightswitch Wizard, The                                                                         yes
         Lumen Micro/Designer                                   yes         yes          yes
          MIT Design Advisor                                                                                                     Direct sun plus window as "diffuse daylight" source
           Radiance (Linux)                                     yes         yes          yes            yes            yes
 Radiance Control Panel (Radiance UI)                           yes         yes          yes            yes            yes       (can theoretically take any radiance sky file)
    S.P.O.T. sens place. & opt tool                                                                                              TMY2 weather
                 Sketchup               sun only
                Sky Vision                                      yes         yes          yes                                     IESNA, Dynamic
             Sombrero 3.01              sun only
                    Spot                sun only
            SUPERLITE 2.0                                                                                              yes
                   Visual                 none

        Ideal LightSolve Profile                                                                        yes
Table 5: Calculation method
               Tool Name                                                Methods
    3DSolar/RayFront(Radiance UI)                   Rayfront (Radiance) - backward raytrace
                  Adeline                     Radiance, Superlite - backward raytrace, radiosity
                   AGI32                               dir comp illum, Radiosity, Ray Trace
        Building Design Advisor                      DOE2 algorthims: direct solar, split-flux
                 Daylight                            sky component DF calculation (uni sky)
                  Daysim                                     Daylight coefficient method
                  DeLight                            DOE2 algorithms, radiosity, EnergyPlus
    DIAL-Europe (was LESODIAL)                                          split-flux
                  DIALux                                              ray-tracing?
     Eco Advisor (in development)                                          n/a
               Eco Lumen                                      (guess: direct calculation)
                  Ecotect                             Split-flux (can export to Radience too)
            FormZ RadioZity                             radiosity (approximated algorithm)
                 Genelux                        progr radiosity, forward ray trace (monte carlo)
              IES - FlucsDL                                      progressive radiosity
             IES - FlucsPro                                      progressive radiosity
             IES - LightPro                                        no analysis done
   IES - RadianceIES (Radiance UI)                                     ray-tracing
                  Inspirer              deterministic radiosity, monte-carlo ray-trace (forward and back)
                Lightscape                        progressive radiosity, ray trace postprocess
        Lightswitch Wizard, The                            DAYSIM (daylight coefficients)
         Lumen Micro/Designer                               radiosity, "direct calculation"
          MIT Design Advisor                                            radiosity
           Radiance (Linux)                                      backwards ray trace
 Radiance Control Panel (Radiance UI)                   RADIANCE (backwards ray trace)
    S.P.O.T. sens place. & opt tool                     RADIANCE (backwards ray trace)
                 Sketchup                                         ray-casting (guess)
                Sky Vision                                             ray-tracing
             Sombrero 3.01                                      guess: geometric calc
                    Spot                           simplified shadowcast backwards raytrace
            SUPERLITE 2.0                                               radiosity
                   Visual                                  Lumen Method (electric lights)

        Ideal LightSolve Profile             ray-trace, accurate enough to make good decisions
Table 6: Output Metrics
               Tool Name                Daylight specific        Illuminance         Luminance             Glare             Other Metrics
    3DSolar/RayFront(Radiance UI)       DF, "DA" (from DF)            yes                yes         human vis response   elec/dayl correlation
                  Adeline                 DF, hourly data             yes                yes           CGI, Guth VCP       annual elec saving
                   AGI32                        DF                H,V,var aim        reg,"veiling"       UGR, CGI              LPD, STV
        Building Design Advisor                 DF                    yes                                   yes
                 Daylight                    DF (part)
                  Daysim                 DF, DA (5min int)            yes                yes                               ann. Light eng use
                  DeLight                                             yes                                                    elec light use
    DIAL-Europe (was LESODIAL)          DF, ADS (like DA)             yes                                                  Overheating Days
                  DIALux                   DF (sort of)      V,H,semi-cyl,hemi-sph       yes                UGR
     Eco Advisor (in development)
               Eco Lumen                                              yes
                  Ecotect                      DF                     yes                yes
           FormZ RadioZity                    none
                 Genelux                DF, "DA" (from DF)           yes                 yes             DGI, UGR          color temperature
              IES - FlucsDL                    DF                H,V,semi-cyl            yes                                   %area DF
             IES - FlucsPro                    DF                H,V,semi-cyl            yes            yes (electric)
             IES - LightPro                   none                   n/a                 n/a                 n/a                   n/a
   IES - RadianceIES (Radiance UI)             DF                V,H,semi-cyl            yes           Guth,CGI,UGR       comfort, right-to-light
                  Inspirer                                           yes                 yes                                   intensity
        Lightswitch Wizard, The          DF,DA(daysim)                                                                         energy use
         Lumen Micro/Designer                 DF                      yes            surf lum/exit
          MIT Design Advisor                                          yes                                                     energy use
           Radiance (Linux)                    DF               yes (any orient)         yes                yes            user definted calc
 Radiance Control Panel (Radiance UI)          n/a                    n/a                n/a                n/a                   n/a
    S.P.O.T. sens place. & opt tool       DA, uniformity                                               (max DA metr)             LPD
                 Sketchup                     none                    no                  no                no                    no
                Sky Vision                     DF                     yes                                                   see output form
             Sombrero 3.01                     n/a                    no                  no                 no                  GSC
                    Spot                                                                                                   % time spot sunlit
            SUPERLITE 2.0                                             yes
                   Visual                     none                    yes                yes                               Light Loss Factor

        Ideal LightSolve Profile             DF, DA                  yes               maybe                yes             emphasis (qual)
Table 7: Output Graphic Display
               Tool Name                           Tables/Graphs                                                Rendering
    3DSolar/RayFront(Radiance UI)             Illuminance/DF profiles           falsecolor, contour, human vis appearance, limited DF temporal spread
                  Adeline                    value tables, 2D profiles                      Radiance, Superlite, glare circled, luminance click
                   AGI32                           numerical tables                  interactive render, falsecolor, contour, daylight sequence, jpeg
     Building Design Advisor (BDA)              tables/graphs 2D,3D
                 Daylight                  workplane falsecolor/number
                  Daysim                           numerical tables
       DeLight (in development)                            ?
    DIAL-Europe (was LESODIAL)                        2D profiles                       Workplane color map, compare pre-simulated and real
                  DIALux                 illuminance at each pixel (click)                        photorealistic render, falsecolor
     Eco Advisor (in development)                                                                   Radiance image examples
               Eco Lumen                         plane contour graph
                  Ecotect                  workplane falsecolor, graphs                                 Radiance renderings
            FormZ RadioZity                                                                             photorealistic render
                 Genelux                           numerical tables                                     3D render, falsecolor
              IES - FlucsDL                         tables, graphs                           workplane contours, wireframe geom render
             IES - FlucsPro              threshold, illum tables/contours
             IES - LightPro
   IES - RadianceIES (Radiance UI)                                                             3D render, photoreal, falsecolor, contour
                  Inspirer              numerical table, surface contours                          photorealistic render, falsecolor
                Lightscape                                                                         interactive render, photrealistic
        Lightswitch Wizard, The                 workplane falsecolor
         Lumen Micro/Designer                      numerical tables                       3D render, grayscale, color, contours, number grid
           MIT Design Advisor                       graphs, tables                               (quick render of room and workplane)
            Radiance (Linux)                      numerical text files                interactive render, photorealistic, falsecolor, contour, pics
 Radiance Control Panel (Radiance UI)
    S.P.O.T. sens place. & opt tool                                                                 3d render (Radiance, simple)
                 Sketchup                                                                         geometric and shadow render only
                Sky Vision
             Sombrero 3.01            geometric SC values (mean or hourly)                             rough, simple render
                    Spot                                                                            geometric and shadow render
            SUPERLITE 2.0                         numerical text files
                   Visual              numerical table, workplane contour                    workplane contours, wireframe geom render

        Ideal LightSolve Profile                                             graphical: render, series of pictures, temporal map, best/worst/average case
Table 8: Sources
               Tool Name                                                          Web                                Extra Sources
 3D-Lighting (part of 3DSolar package)  ,
        Building Design Advisor                               
                  Daysim                                                              Walkenhorst 2002
                  DeLight                                                                                            Carroll 2005, Hitchcock 2003, Vartiainen 2000
    DIAL-Europe (was LESODIAL)                                      
     Eco Advisor (in development)                               
               Eco Lumen         
            FormZ RadioZity                              Bryan 2002
                 Genelux                                              Mitanchey 1997
              IES - FlucsDL                                        
             IES - FlucsPro                                        
             IES - LightPro                                        
   IES - RadianceIES (Radiance UI)                                 
                Lightscape              Altmann 2001, Bryan 2002
        Lightswitch Wizard, The                                        Reinhart 2003
         Lumen Micro/Designer                                         Bryan 2002
          MIT Design Advisor                              
           Radiance (Linux)                                       Altmann 2001, Bryan 2002
 Radiance Control Panel (Radiance UI)                              
    S.P.O.T. sens place. & opt tool                        
                Sky Vision                             
             Sombrero 3.01                                      
                    Spot                                        Bund 2005
            SUPERLITE 2.0                        

                                        Overall Sources: (besides listed websites)
 DOE Building Energy Toolbox (lighting)
             Lighting Wiki    

Aizlewood, M. E. “Innovative daylighting systems: An experimental evaluation.” Lighting Research and Technology, Vol 25 (4),
             pp.141-152, 1993

Aizlewood, M. E., and P. J. Littlefair. Daylight prediction methods: a survey of their use. BRE Client Report, April 1994

Altmann, Kurt, and Peter Apian-Bennewitz. Report on an Investigation of the Application and Limits of Currently Available
      Programme Types for Photorealistic Rendering of Light and Lighting in Architecture: The Kimbell Art Museum as a Case
      Study for Lightscape, Radiance and 3D-Studio MAX. Available at April
      7, 2001

Architectural Energy Corporation. Daylighting Metric Development Using Daylight Autonomy Calculations In the Sensor Placement
       Optimization Tool: Development Report and Case Studies. Prepared for the CHPS Daylighting Committee, Daylighting
       Forum, NWEEA, March 17, 2006

Bryan, Harvey. Lighting/Daylighting Analysis: A Comparison. Proceedings of the American Solar Energy Society Conference,
       Reno, Nevada, 2002

Budn, Sébastien, and Ellen Yi-Luen Do. Spot! Fetch Light Interactive navigable 3D visualization of direct sunlight. Automation in
       Construction, vol 14, 2005, pp. 181-188

Cannon-Brookes, S. W. A. “Simple scale models for daylighting design: Analysis of sources of error in illuminance prediction.”
      Lighting Research and Technology, Vol 29 (3), pp.135-142, 1997

Carroll, William L. Daylighting Simulation: Methods, Algorithms, and Resources. A Report of IEA SHC Task 21 / ECBCS ANNEX
        29, December 1999

Collins, J. B., “The development of daylighting – a British view.” Lighting Research and Technology. Vol 16 (4), pp.155-170, 1984
Crabtree, Peter, Nick Kyriakopedi, Evan Milles, Philip Haves, Roland J. Otto, Mary Ann Piette, Peng Xu, Rick Diamond, Joe
       Deringer, and Chuck Frost. Developing a Next-Generation Community College Cjurriculum for Energy-Efficient High-
       Performance Building Operations. Proceedigns of the 2004 ACEEE Summer Study on Energy Efficiency in Buildings.
       Pacific Grove, CA, August 22-27, 2004

De Groot, Ellie, Laurens Zonneveldt, and Bernard Paule. DIAL-Europe: A Decision Support Tool for Early Lighting Design. Eighth
      International IBPSA Conference, Eindhoven, Netherlands, August 11-14, 2003

Estes, James M., Jr., Susan Schreppler, and Tonya Newsom. Daylighting Prediction Software: Comparative Analysis and
        Application. Fourteenth Symposium on Improving building Systems in Hot and Humid Climates, Texas, May 17-18, 2004

Geebelen, Benjamin, and Herman Neuckermans. Optimizing Daylighting Simulation for Speed and Accuracy. Eighth International
      IBPSA Conference, Eindhoven, Netherlands, August 11-14, 2003

Hitchcock, Robert J., and William L. Carroll. DElight: A Daylighting and Electric Lighting Simulation Engine. Eighth International
       IBPSA Conference, Eindhoven, Netherlands, August 11-14, 2003

Inanici, Mehlika N. Application of the State-of-the-Art Computer Simulation and Visualization in Architectural Lighting Research.
        Seventh International IBPSA Conference, Rio de Janeiro, Brazil, August 13-15 2001

Lawrrence, Mark. Integration of Lighting Early in the Design Process: evaluations of tools and methodologies. Paper for an MIT
      Building Technology Seminar (4.481), Dec 16, 2005

Mardaljevic, J. “Validation of a lighting simulation program under real sky conditions.” Lighting Research and Technology, Vol 27
               (4) pp.181-188, 1995

Mardaljevic, J. “Simulation of annual daylighting profiles for internal illuminance.” Lighting Research and Technology, Vol 32 (3),
               pp.111-118, 2000

Mardaljevic, J. “The BRE-IDMP dataset: a new benchmark for the validation of illuminance prediction techniques.” Lighting
               Research and Technology, Vol 33 (2), pp.117-136, 2001
Mardaljevic, J. “Verification of program accuracy for illuminance modeling: assumptions, methodology and an examination of
               conflicting findings.” Lighting Research and Technology, Vol 36 (3), pp.217-242, 2004

Mardaljevic, J. Spatio-temporal dynamics of solar shading for a parametrically defined roof system. Energy and Buildings vol 36,
      2004, pp. 815-823

Mitanchey, Richard, Pierre Laforgue, Marc Fontoynont, Olivier Marolles, Pascale Avouac-Bastie, Dominique Dumortier, Jean-Marc
      Duport, Parul Kenny, Christine Badinier, Cécile Demé. Lighting Calculations on the Internet Using Genelux-Web.
      Proceedings of the Right Light 4 Conference, vol 1, 1997, pp. 125-130

Ng, Edward. “A study on the accuracy of daylighting simulation of heavily obstructed buildings in Hong Kong.” Seventh
      International IBPSA Conference, Rio de Janeiro, Brazil, August 13-15, 2001

Papamichael, Konstantinos, John La Porta, and Hannah Chauvet. Decision Making through Use of Interoperable Simulation
      Software. Proceedings of the Building Simulation ’97 Fifth International IBPSA Conference, Prague, Czech Republic, Vol II,
      September 8-10, 1997.

Paule, Bernard, and Jean-Louis Scartezzini. “Leso-DIAL”, a new Computer-based Daylighting Design Tool. Proceedings of the
       Right Light 4 Conference, Copenhagen, vol 1, 1997, pp. 93-97

Reinhart, Christoph, and M. Morrison. The Lightswitch Wizard – Reliable Daylight Simulations for Initial Design Investigation.
       Eighth International IBPSA Conference, Eindhoven, Netherlands, August 11-14, 2003, vol 3, pp. 1093-1100

Reinhart, Chirstoph, and Annegret Fitz. Key Findings form an Online Survey on the Use of Daylight Simulation Programs.
       Proceedings of eSim 2004, Vancouver, B.C., June 10-11, 2004, pp. 175-182

Reinhart, Chirstoph, and Annegret Fitz. Findings from a survey on the current use of daylight simulations in building design. Energy
       and Buildings, Vol 38, 2006, pp. 824-835

Thanachareonkit, A., J.-L. Scartezzini, M. Andersen. “Comparing daylighting performance assessment of buildings in scale models
             and test modules.” Solar Energy Vol 79, pp.168-182, 2005
Ubbelohde, M. Susan, and Christian Humann. Comparative Evaluation of Four Daylighting Software Programs. ACEE Summer
      Study on Energy Efficiency in Buildings Proceedings, 1998

Vartiainen, Eero. Daylight Modelling with the Simulation Tool DElight. Helsinki University of Technology Publications in
       Engineering Physics, TKK-F-A799. Ottaniemi, 2000

Walkhenhorst, O., J. Luther, C. Reinhart, and J. Timmer. Dynamic annual daylight simulations based on one-hour and one-minute
      means of irradiance data. Solar Energy, vol 72, no 5, May 2002, pp. 385-395


DOE Building Energy Toolbox (

The Lighting Resource (

The Lighting Wiki (

For the websites of specific tools, see Table 8.

To top