VIEWS: 1 PAGES: 27 POSTED ON: 11/16/2012
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 used. 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 (www.thelightingcenter.com) 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 weaknesses. 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 metamorphosis. 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 (radiosity). 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 Lund) 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 Lightscape 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) http://www.alware.de, http://www.schorsch.com/rayfront/manual/ Adeline http://www.ibp.fraunhofer.de/wt/adeline/index.html AGI32 www.agi32.com Building Design Advisor http://gaia.lbl.gov/BDA Daylight http://www.archiphysics.com Daysim http://www.daysim.com Walkenhorst 2002 DeLight Carroll 2005, Hitchcock 2003, Vartiainen 2000 DIAL-Europe (was LESODIAL) http://www.estia.ch/ DIALux http://www.dialux.com/e/index4.html Eco Advisor (in development) http://www.ecoadvisor.com Eco Lumen http://www.walawalkar.com/info/EnergyManagement/EcoLumen/EcoLumen.htm Ecotect http://www.squ1.com FormZ RadioZity http://www.formz.com/products/formz_radiozity.html Bryan 2002 Genelux http://genelux.entpe.fr/sommaire.html Mitanchey 1997 IES - FlucsDL http://www.iesve.com IES - FlucsPro http://www.iesve.com IES - LightPro http://www.iesve.com IES - RadianceIES (Radiance UI) http://www.iesve.com Inspirer http://www.integra.co.jp/eng/products/inspirer/index.htm Lightscape http://usa.autodesk.com/adsk/servlet/index?siteID=123112&id=5235467 Altmann 2001, Bryan 2002 Lightswitch Wizard, The http://www.buildwiz.com/lightswitch/ Reinhart 2003 Lumen Micro/Designer http://www.lighting-technologies.com/ Bryan 2002 MIT Design Advisor http://designadvisor.mit.edu/design/ Radiance (Linux) http://radsite.lbl.gov/radiance/HOME.html Altmann 2001, Bryan 2002 Radiance Control Panel (Radiance UI) http://www.squ1.com S.P.O.T. sens place. & opt tool http://www.archenergy.com/SPOT Sketchup http://www.sketchup.com Sky Vision http://irc.nrc-cnrc.gc.ca/ie/light/skyvision/ Sombrero 3.01 http://nesa1.uni-siegen.de/ Spot http://code.arc.cmu.edu/archbook/index.html Bund 2005 SUPERLITE 2.0 http://btech.lbl.gov/tools/superlite/superlite20.html Visual http://www.VisualLightingSoftware.com Overall Sources: (besides listed websites) DOE Building Energy Toolbox (lighting) http://www.eere.energy.gov/buildings/tools_directory/ Lighting Wiki http://lightingwiki.com/LightingSoftware Bibliography 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 http://www.pab-opto.de/radiance/render_vergleich/. 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 Websites: DOE Building Energy Toolbox (http://www.eere.energy.gov/buildings/tools_directory/) The Lighting Resource (www.thelightingcenter.com) The Lighting Wiki (http://lightingwiki.com/LightingSoftware) For the websites of specific tools, see Table 8.
Pages to are hidden for
"Physical building simulations – in other words_ scale models –"Please download to view full document