LBNL-40110IO-403

Automation in Construction 8 (1999) 339-350. The Netherlands. Elsevier Science B.V. 1999.

This work was funded, in part, by the California Institute for Energy Efficiency (CIEE), a research unit of theUniversity of California. Publication of research results does not imply CIEE endorsement of or agreement withthese findings, nor that of any CIEE sponsor. This work was also supported by the Assistant Secretary for EnergyEfficiency and Renewable Energy, Office of Building Technology, State and Community Programs, Office ofBuilding Systems of the U.S. Department of Energy, under Contract No. DE-AC03-76SF00098.

Product modeling for computer-aided decision-making

K. Papamichael, H. Chauvet, J. LaPorta and R. Dandridge

Building Technologies DepartmentEnvironmental Energy Technologies Division

Lawrence Berkeley National LaboratoryUniversity of California

1 Cyclotron RoadBerkeley, CA 94720 USA

March 1997

1

Product modeling for computer-aided decision-makingK. Papamichael, H. Chauvet, J. LaPorta and R. Dandridge

Building Technologies Department, Environmental Energy Technologies Division,Lawrence Berkeley National Laboratory, Berkeley, CA 94720, USA

AbstractIn this paper we describe the product

modeling techniques that we use for thedevelopment of a computer-aided decision-making tool for the building industry. Westart with an introduction to modeling and abrief description of the goals and scope ofthe project, and follow with an extensivepresentation and discussion of the modelingtechniques employed. We conclude with abrief description of our plans for the future.

IntroductionWe use the term “product” to refer to

building components and systems. While theprimary focus of our efforts will serve thebuilding industry, we believe that ourtheories and techniques will be of value toother industries as well. The productmodeling techniques described herein arebeing applied in the development of theBuilding Design Advisor (BDA), acomputer-based tool that will assistdecision-makers in the building industry.

Modeling theory

We understand product modeling as therepresentation of a product in terms ofparameters that reflect its descriptive andperformance characteristics. Descriptiveparameters, such as geometry, color, etc.,are defined herein as those controlled by thedecision-maker. Performance parameters,such as comfort levels, energy requirements,etc., are defined as those that the decision-maker uses to judge the appropriateness ofthe product. Context parameters are thoseused to describe the environment withinwhich the product is assumed and evaluated.The values of performance parameters may

depend not only on the values of descriptiveparameters, but context ones as well.Modeling based on these parametersfacilitates communication and supportstesting applications of new and existingproducts.

Based on the above definitions, mostactivities in building design are forms ofmodeling. Currently, the most commonmodels used in the building industry aredrawings, such as plans, sections, elevations,isometrics, perspectives, etc., as well asphysical scale models. These modelsadequately support the evaluation of spatiallayout and aesthetic appeal and are usuallycomplimented by mathematical models thataddress other aspects, such as structural,energy and economic performance.

Computer-based models

Advances in computer applications overthe last few decades have resulted in thegradual replacement of manual modelingwith computer-simulation models. Whilecomputer-based models have beendeveloped for a large variety of buildingperformance considerations, computer-aideddrafting models have been the most widelyused in the building industry. Most otherstend to be used mainly for researchpurposes, modeling performance aspectssuch as comfort, energy, and economics.Some of these models are able to address notonly the building design needs, butconstruction and operational requirements aswell.

Computer-aided drafting was originallydeveloped to serve the needs of electroniccircuitry design and typically generated very

2

complex two-dimensional drawings. Thesame types of algorithms were later adaptedfor general drafting applications, includingarchitectural and engineering drawings ofbuildings, their components and systems.The main limitation of the widely useddrawing-based models is the distancebetween the very abstract, two-dimensionalrepresentations and the actual products thedrawings suggest for construction. Themajor advancement in computer-graphicsthat facilitates the representation of three-dimensional solids and the tools to createand visualize these objects brings us onestep closer to representing the actualcomponents of construction.

Parallel to the developments incomputer graphics, a large number ofcomputer-based models, or simulations, arebeing developed by building researchers,that address various aspects of buildingperformance, such as comfort, energy,economics, etc. The development of suchmodels over the past twenty years has beenbroad, with various levels of success inmodeling capabilities and predictionaccuracy. While most models wereoriginally implemented on mainframe andmini computers, those that are still underdevelopment have shifted their developmentonto powerful workstations and personalcomputers. Developed primarily forresearch purposes only, most of theseapplications tend to be difficult to use. Theyrequire an extensive description of thebuilding and its context and they provideoutput in the form of alphanumeric tablesthat are cumbersome to review and interpret.

Research efforts in computerapplications in the building industry duringthe last decade have focused on developingnew models that will combine thecapabilities of a large variety of existingmodels. These new models will provide formore cost-effective performance predictionof multiple design alternatives. In this paper

we describe the results of such efforts withinthe Building Technologies Program of theEnvironmental Energy TechnologiesDivision at Lawrence Berkeley NationalLaboratory.

BackgroundResponding to the energy crises of the

early 1970s, Lawrence Berkeley NationalLaboratory began development of cost-effective and environmentally friendlystrategies and technologies to improve theenergy efficiency of buildings withoutcompromising comfort. The researchprocesses followed in this development areconceptually identical to building design.The main difference, however, is thatresearch projects devote many months andeven years focusing on a specific subject,while actual building projects may only beable to afford a few hours or perhaps days inconsideration of the same issues. Anotherdifference is the context within whichresearchers test their ideas. To understandthe general performance trends of energyefficient strategies and technologies,researchers must examine them in variousapplications, parametrically changing keydesign and context parameters whilekeeping most constant. As a result, researchfindings are usually general and may not beapplicable to specific applications.

Simulation tools

Extensive research efforts during the1970s and 1980s resulted in thedevelopment of several computer-basedmodels used to simulate buildingperformance with respect to energy,comfort, environmental impact, economics,etc. A computer-based simulation modelcan be seen as the representation of andinteraction among the parameters that arerequired to describe a phenomenon.Depending on the performance aspect beingconsidered, these parameters andinteractions may vary drastically. Walls

3

could be “thermal barriers with U-valuesand areas” for thermal computations,“polygons with reflectance values andtextures” for lighting computations,” or“assemblies with construction, maintenanceand repair costs” for economiccomputations. These different modelingrequirements fostered the development ofindependent simulation programs such asDOE-2 for energy and energy costscomputations [1], SUPERLITE fordaylighting computations [2], RADIANCEfor lighting and rendering computations [3],COMIS for airflow and indoor air qualitycomputations [4].

These types of simulation programswere developed over long periods of timeand most of them are still underdevelopment, improving their modelingcapabilities and prediction accuracy. Theyhave proven most instrumental for thedevelopment of a large variety of energy-efficient strategies and technologies. Whenwe initiated efforts to transfer thesestrategies and technologies to the buildingindustry, we realized that the generalstatements about their performance were notadequate for decision-making in specificprojects. Since our simulation models werevery hard to use by architects and engineers,our efforts were redirected to making themeasy to use routinely in everyday buildingdesign. In collaboration with severalacademic and research institutions, we spentseveral years exploring the design anddecision-making process. By 1991 we haddeveloped a design theory [5, 6] that servedas the foundation for the development of ademonstration prototype that incorporatedmultiple simulation tools during the buildingdesign process. This tool attracted theinterest of California Utilities, whichinitiated support for the development of theBuilding Design Advisor [7] through theCalifornia Institute for Energy Efficiency.

Objectives and strategies

The main objective of the BuildingDesign Advisor (BDA) project is to developa computer-based tool that allows buildingdecision-makers to quickly and easilyintegrate energy considerations intodecision-making, throughout the earlyphases of building design. The functionalrequirements of the BDA include the use ofa graphic editor for the specification of thegeometric attributes of building componentsand systems.

From our research in design theoriesand methods we realize that a successfulcomputer-based prototype system mustsupport the use of multiple simulation tools.This system must also support the variousbuilding representations required by thedifferent simulation tools. To meet thisrequirement, we developed a single buildingmodel that is a superset of the parametersused by individual tools. This single modelcould be used to communicate with the userand is mapped to the individualrepresentations of the simulation tools sothat we can automate the preparation of theirinput, as well as integrate their output formulti-criterion decision making.

Another major challenge rises from theneed to use detailed simulation modelsduring the initial, schematic phases ofbuilding design, when decisions on detailedissues have not yet been made. Since thesimulation tools that are linked to the BDArequire values for all input parameters, wedeveloped a schema that assigns “smart”default values to all parameters that are notyet defined by the user. Since default valuesrepresent design decisions, they are clearlyindicated to the user, and may be modifiedat any time during the design process.

Decision-making

Our research efforts also indicated thatin order to support decision-making we mustnot only provide a means for performance

4

Fig 1. Schematic diagram of the Building Design Advisor general architecture, illustratingthe basic strategy of a single, object-oriented model of the building and its context. The intentis to provide a single user interface for controlling the various simulation tools and databases.

prediction but for performance evaluation aswell. Since performance evaluation requirescomparison among alternatives, we supportthe evaluation of concurrent designsolutions, as well as links to a Case StudiesDatabase of actual buildings. Finally, wedeveloped a graphical user interface thatconsists of two main elements: the BuildingBrowser and the Decision Desktop [7].

The Building Browser allows buildingdesigners to quickly navigate through themultitude of descriptive and performanceparameters required by the simulation toolslinked to the BDA. Through the BuildingBrowser, the user can edit the values ofinput parameters and select any number ofparameters for display in the DecisionDesktop. The Decision Desktop allowsmulti-criterion decision-making, throughcomparison of multiple alternative designsolutions with respect to multipleperformance parameters. The DecisionDesktop supports a variety of data types,including 2-D and 3-D distributions, images,sound and video.1

1 In this paper we focus on the modeling methods andtechniques used for the development of the BDA,

Modeling techniquesOur overall strategy is to develop an

expandable environment that supports themapping of a single model of the buildingand its context to multiple simulation toolsand databases, driven by a simple graphicaluser interface (Fig. 1). Following thegeneral trends in the current approaches torepresenting buildings, we use an object-oriented representation of the building andits context. Since we did not know whichtools we would eventually link to the BDA,we developed a model that would allow usto expand the single, object-orientedrepresentation of the building and its contextas required for the addition of simulationtools and databases in the future. Thismodel consists of three databases andvarious applications that operate on them(Fig. 2).

presenting applications that are meant for developers,rather than users of the BDA. A detailed descriptionof the BDA application from the user’s point of view,including screen captures of the BDA user interfaceand the Schematic Graphic Editor, is presented inreference #7.

Graphical User Interface

ObjectOrientedBuildingModel

Interfaceto

Applications

Building DesignProject

TMY-2Weather Data

PrototypesLibraries

Case Studies ofActual Buildings

UtilityRate Structures

FurnitureLibraries

RS MeansCost Data

SchematicGraphic Editor

DVSValue Selector

DElightDaylight Analysis

RADIANCELighting/Rendering

DOE-2Energy Analysis

COMISAir Flow

Commercial CADSoftware

EnvironmentalImpact Data

RESEGYEnergy Analysis

Commercial ProductCatalogs

EAMCost Analysis

Interfaceto

Databases

2

The schema database

The Schema Database is a datadictionary where definitions for BuildingObject Types (e.g. space, wall), Properties(e.g., height, U-value), Units (e.g., ft., cm.,degrees), Relations (e.g., has, faces) andSimulation Tools (e.g. DOE-2, RADIANCE,etc.) are stored. Parameters of buildingcomponents and systems are then defined aslinks between Object Types and Properties(e.g., space height, wall U-value). Eachparameter is also linked to the simulationtools that use it as input or output along withthe associated type of units (Fig. 3).

To facilitate the development of theSchema Database we developed a GraphicalUser Interface that allows developers to

define new Simulation Tools, BuildingObject Types, Properties, Units, andRelations, as well as Relationships andParameter Lists for each Building ObjectType (Figs. 4 and 5). The Schema Databasealso has reporting utilities that allowdevelopers to check the consistency andsemantics of the Schema (e.g., parameterdefinitions and links to simulation tools).

The prototypes database

The Prototypes Database is used tostore Libraries of Building Object TypeInstances (or Prototypes). Each Prototype iscreated with its own list of parameters asdefined in the Schema Database, and eachparameter is assigned a Value from someSource or Data Reference. The PrototypesDatabase is the main source of buildingcomponents and systems available to theuser for the description of the building. Likethe Schema Database, the PrototypesDatabase has its own Graphical UserInterface that allows developers to enter newPrototypes and modify existing ones (Fig.6). Moreover, it too has reporting utilitiesthat support the listing and printing of allInstances for each Object Type.

The project database

The Project Database is used to storethe Building Object Type Instances createdat run-time by the BDA. Staying with our“generic” approach, we did not defineclasses for different building objects.Rather, we defined classes for Run-timeBuilding Object Type Instances, Run-timeParameter Instances, and Run-time ValueInstances along with five derived classes tohandle integer, real, string, real array, image,and multi-media data types.

In the BDA run-time system, theBuilding Object Type Instances as well asParameters and Values are represented asC++ objects. This allows Parameters to

Fig. 2. Schematic diagram showing the three maindatabases used in the BDA and the main processesthat operate on them.

Fig. 3. Schematic diagram of the meta-schema usedfor the development of the Building Design Advisor,showing the main objects and their relationships.

Simulation tool

Unit conversion

Unit

Property

Parameter

Building object

Relation

OutputInputToFrom M MM

M

M

M

Primary Inverse

SchemaSchemaEditorEditor

SchemaSchemaDatabaseDatabase

ValueValueSelectorSelector

ProjectProjectDatabaseDatabase

PrototypesPrototypesEditorEditor

PrototypesPrototypesDatabaseDatabase

BuildingBuildingBrowserBrowser

GraphicGraphicEditorEditor

Developer

Computer

User

User

Developer

3

Fig. 4. Example screen captures from the Schema Editor illustrating the definition ofproperties and their assignment to objects as parameters.

4

Fig. 5. Example screen captures from the Schema Editor illustrating the definition ofrelations and their use in defining relationships between pairs of objects.

5

more than one Value, each from a separateSource or Simulation Tool. The reason forthis “expensive” representation is the desireto use the BDA environment for theimplementation of a Building LifecycleInformation Support System (BLISS).BLISS will expand beyond original designto address the data needs of buildingconstruction, commissioning, operation, andso on. To satisfy the need for performanceevaluation, the BDA supports multipledesign alternatives within a project database.A new alternative design solution isgenerated at any point as a copy of any ofthe existing solutions. The BDA userinterface supports the concurrent review andmanipulation of any number of alternativedesign solutions. Moreover, it supports theirside-by-side comparison with respect tomultiple performance considerations.

The building model

The development of the SchemaDatabase is guided by the tools that we are

linking to the BDA. For the 1.0 version, wehave been addressing the needs of DElight, adaylighting tool that uses the DOE-2daylighting algorithms [8], RESEGY, asimplified thermal and energy analysis tool[9], and SGE, a Schematic Graphic Editorthat we developed specifically for the BDA.SGE allows users to graphically enter thegeometric attributes of building componentsand systems, thereby modeling buildingcomponents as opposed to merely usinglines to represent them [7].

Currently, the BDA building model is anetwork schema with five types of relationsused to link the various building componentsand systems among themselves as well aswith the objects used to define the buildingcontext (Figs. 7 and 8). All relations aredefined as pairs of primary and inverseexpressions as follows:

Fig. 6. Example screen capture from the Prototypes Editor illustrating the definition ofspecifications for an absorption chiller.

6

Composed Of/Part OfAn object maybe an assembly that is composed of one ormore parts. When an assembly is deleted,then all of its parts are also deleted. Eachpart is part of one and only one assembly.Deletion of a part has no effect on theexistence of its assembly.

Contains/Contained InAn object maybe a container, that is it may contain one ormore contents. The deletion of a content hasno effect on the existence of its container.Each content may be contained in one ormore containers. When a container isdeleted, only those contents are deleted that

do not have either a part of or a contained inrelationship to any other container.

Has/Owned ByAn object may be anowner, that is it may have one and only onefeature of a particular object type. Deletionof a feature has no effect on the existence ofits owner. Each feature is owned by one andonly one owner. When an owner is deleted,then all of its features are also deleted.

Uses/Used ByAn object may be aclient, using one or more servers. Clientdeletion has no effect on the existence of aserver. Each server is used by one or moreclients. Server deletion has no effect on the

Fig. 7. Partial view of the building model focusing on the schema that relates thebuilding to the spaces its boundaries.

Fig. 8. Partial view of the building model focusing on the schema that relatesthe building to the HVAC system.

Building

HVAC Zone

Space

Storey

Composed Of

Contains

Boundary

Boundary Segment

Finish

Part Of Composed Of Part Of

Contained In Composed Of Part Of

Composed Of Part Of Faces Faced By

Contains Contained In Composed Of Part Of

Hourly Schedule

Building

HVAC ZoneComposed Of

Distribution System

Heating Plant

Monthly Schedule

Part Of

Composed Of Part Of

Uses Used By

Has Owned By

Uses Used By Uses Used By

Cooling Plant

Composed Of Part Of

Has Owned By Has Owned By

7

existence of a client but it does eliminate theservice that was provided.

Faces/Faced ByThis is a specialrelation that we use to address spaces andtheir boundaries. A boundary’s finish facesone and only one space. Boundary deletionhas no effect on the existence of the spacethat it faces. Each space is faced by one ormore boundary finishes. When a space isdeleted, then boundaries whose finishes donot face other spaces are deleted, while theones whose finishes face other spaces mayswitch to a different instance (e.g., frominterior to exterior wall).

Data Assignment Scenario

During the creation of a new space inthe Schematic Graphic Editor, the user isasked to select a Space Prototype from thoseavailable in the Prototypes Database, such as“Lobby,” “Conference Room,” etc. Whenthe “Space” Run-time Building ObjectInstance is created, its Object Type field isdynamically set to “Space,” the SchemaDatabase is queried for the list of Parametersrequired for a “Space,” and Run-timeParameters are created and placed in the“Space” Run-time Object parameter list.Following this, the Prototypes Database isqueried and Run-time Values are created foreach Run-time Parameter in the parameterlist of the “Space” Run-time Object. Therules for the selection of the default valuesfollow building codes, standards, andrecommended practice. These values aredrawn from a number of sources, such as theASHRAE Handbook of Fundamentals [10]or the Handbook of the IlluminatingEngineering Society [11]. The user maychange the default values at any pointthrough the BDA user interface.

DiscussionThe greatest difficulty in incorporating

simulation tools within a building designsystem is that the CAD system and thesimulation tools are radically different. The

primary goal of a CAD system is to allowthe user to specify and manipulate geometry.This is accomplished by representationsutilizing various graphic objects (entities orsymbols), such as lines and polygons. Theseentities can be easily created andmanipulated by the user because as anobject, a CAD polygon knows how todisplay itself, show grip handles at itsvertices, and respond to mouse clicks anddrag events. The second model is that of thephysical world. In the A/E/C industry, thisis a model of building objects such asspaces, walls, windows, etc. The Physicalmodel is rich with non-geometric attributes,but does not translate readily into a graphicversion on a computer screen. This Physicalmodel required by simulation engines thatreason about various domain parameters inenergy, comfort, structures, etc. A simpleexample of the disparity between the twomodels can be seen in a wall object. In thePhysical model, a wall object contains along list of non-geometric attributes such assurface reflectance, materials, U-Values, anda set of relationships to other objects such asspaces, doors and windows. The wall wouldcontain only that geometry necessary todescribe itself in the real worldthat is a listof vertices. By contrast, in the CAD model,the Wall object consists of a polygondefining the wall, layer information, linesstyles, color, pen thickness, and rich set ofmethods which allow it to display itself andbe modified through mouse-basedinteractions with the user.

The Dual Model Approach

In the BDA, the disparate needs of thetwo models resulted in two separateapplications to create and maintain them.The CAD model is maintained by theSchematic Graphic Editor (SGE) and thePhysical model is maintained by the BDA inthe Project Database. Because the SGE is aseparate application built on top of a thirdparty library of CAD functions with no

8

interface to our database managementsystem, all the objects drawn in SGE aresaved to a file that is independent of theBDA Project database. As a result, the twoseparate representations must besynchronized during the “save” and “load”operations. This synchronization problemprevents us from using the Project databaseto its full advantage. If both the SGE andthe BDA operated on the same BuildingObject, then changes could be saved as theyoccur and only those parts of the Projectdatabase that needed to be displayed wouldbe loaded, truly utilizing all of theadvantages of a Data Base ManagementSystem. The only advantage of our currentapproach is that the Physical model in theBDA can be kept free of the large amountsof CAD information that is extraneous to theneeds of the simulation tools.

The single, integrated model

The most viable long-term solution thatwe see is the merging of the two models intoone that supports both the CADfunctionality required by the user, and thedatabase functionality required by thesimulation tools. In this approach, the wallobject will “know” everything about being awall in the physical world, as well as how todisplay itself on the screen and respond tomouse clicks and drags. Unfortunately, suchan environment does not yet exist.However, the industry is moving closer to itwith the efforts of the International Alliancefor Interoperability (IAI). The IAI isdeveloping the Industry Foundation Classes(IFC), which is a data model that willencompass both the graphic needs of CADsystems and the data needs of analysis tools.The other goal of the IAI is that ofstandardization. If a standardized modelexisted, then the conversions betweendifferent CAD and analysis programs wouldbe eliminated. No conversion would berequired since all programs would simplycreate IFC Wall objects, IFC Window

objects, etc. However, a new generation ofsimulation tools may have to be written totake full advantage of this approach.

Real versus Conceptual Objects

Another major challenge in ourdevelopment efforts has been the modelingof conceptual objects, such as plenums,schedules, activities, etc., which do notreally exist as “real,” physical objects. Themost common and problematic conceptualobject is the “space.” The space has been afocal point not only in the requiredfunctionality of the Schematic GraphicEditor (e.g., users want to be able to “movespaces around…”) but in the modeling ofthe simulation tools as well. Most daylightcalculations are performed on a space-by-space basis, as are many of the thermal andair quality calculations. This is intrinsicallyproblematic in modeling because the objectthat we consider as most important does notexit in the physical realm. The space is anabstraction that permits us to reason about agiven volume that is defined by acombination of physical and imaginaryboundaries. In the simplest case, a space isdefined on all sides by physical boundaries(e.g., walls, floor and ceiling). However,spaces can also be defined by a small changein elevation, or a change in the floormaterial, or by completely imaginaryboundaries that we use to mentally “close” aroom, but which do not exist in the physicalworld.

Boundaries and Boundary Segments

The approach that we have taken in theBDA is to allow the user to define eachspace by drawing a polygon in the SGE,explicitly closing it. Then, after the spacehas been defined, the user may edit specificspace boundaries and designate theirconstruction to NULL. This provides for anexact definition of the space, while allowingfor non-physical boundaries. One problemthat arises from this approach is that walls

9

shared by two spaces are defined twice,since each space is explicitly described. Tosolve this problem we introduced the notionof the Wall Segment object. While Wallobjects are still used to define the perimeterof each space, each Wall is composed of oneor more Wall-Segments. When the SGEdetects overlapping Walls, these areautomatically segmented into the propernumber of Wall Segments, so that there isno overlap. The Wall Segment is then usedto define the construction and other physicalattributes required by the simulation tools.Through this approach we model theconceptual boundaries of the space usingWall objects and the physical boundaries ofthe space using Wall-Segments. Theautomatic generation and maintenance of theWall-Segment objects has been one of themost challenging implementation efforts ofthe SGE. This functionality allows the userto freely move entire spaces at any timeduring the design process, which isextremely important during the early,schematic phases of building design.

ConclusionsOur product modeling efforts in the

development of the Building DesignAdvisor have been directed towards anexpandable system that will potentiallysatisfy the needs of many simulation toolsand databases. In the current building modelwe have implemented the objects andparameters needed for DElight andRESEGY. During this implementation,however, we have been addressing andconsidering the data needs of linking toadditional tools that we plan to implement inthe future.

For the 2.0 version of the BDA we planto develop links to DOE-2 and RADIANCE.Our plans for future expansions include thedevelopment of links to COMIS, as well aseconomic analysis and environmentalimpact tools, building rating tools,

commercial CAD software and electroniccatalogs of actual products frommanufacturers of building components andsystems. We are also participating in theInternational Alliance for Interoperabilityefforts and plan to implement the IndustryFoundation Classes when they will reach alevel that satisfies the data needs of the toolsthat are linked to the BDA.

AcknowledgmentsThis work was funded, in part, by the

California Institute for Energy Efficiency(CIEE), a research unit of the University ofCalifornia. Publication of research resultsdoes not imply CIEE endorsement of oragreement with these findings, nor that ofany CIEE sponsor. This work was alsosupported by the Assistant Secretary forEnergy Efficiency and Renewable Energy,Office of Building Technology, State andCommunity Programs, Office of BuildingSystems of the U.S. Department of Energy,under Contract No. DE-AC03-76SF00098.

References [1] F.C. Winkelmann, B.E. Birdsall, W.F.

Buhl, K.L. Ellington, A.E. Erdem, J.J.Hirsch and S.D. Gates: “DOE-2Supplement: Version 2.1E” LawrenceBerkeley Laboratory report no. LBL-34947, 1993.

[2] M. Modest: “A general model for thecalculation of daylighting in interiorspaces,” Energy and Buildings, Vol. 5,pp. 66-79.

[3] G. J. Ward: “Visualization.” LightingDesign and Application, Vol. 20, No. 6,pp. 4-20, 1992.

[4] H.E Feustel: “Annex 23 multizoneairflow modeling – an internationaleffort,” Proceedings of the InternationalSymposium on Air Flow in MultizoneStructures, Budapest, Hungary, 1992.

[5] K. Papamichael: “Design process andknowledge; possibilities and limitations

10

of computer-aided design.” Ph.D.Dissertation, Department ofArchitecture, University of California,Berkeley, CA, August 1991.

[6] K. Papamichael and J.P. Protzen: “TheLimits of Intelligence in Design,”Proceedings of the Focus Symposiumon Computer-Assisted Building DesignSystems, of the Fourth InternationalSymposium on System Research,Informatics and Cybernetics, Baden-Baden, Germany, August 3-4, 1993.

[7] K. Papamichael, J. LaPorta, H.Chauvet: “Building Design Advisor:automated integration of multiplesimulation tools,” Automation inConstruction, Vol. 6, No. 4, August1997.

[8] F.C. Winkelmann: “Daylightingcalculation in DOE-2,” LBNL reportNo. LBL-11353, III.2.9, LawrenceBerkeley National Laboratory, 1983.

[9] W.L. Carroll, B.E. Birdsall, R.J.Hitchcock, and R.C. Kammerud:“RESEM: An evaluation tool for energyretrofits in institutional buildings,”Proceedings of the InternationalBuilding Performance SimulationAssociation, 1989, pp. 107-112.

[10] ASHRAE: ASHRAE FundamentalsHandbook, American Society ofHeating, Refrigerating and Air-conditioning Engineers, 1993.

[11] IESNA: IESNA Handbook, IlluminatingEngineering Society of North America,1993.