hds beagle 1.0

DESIGN OPTIONEERING:

VARIATION – EXPLORATION – CORRELATION

H.D.S BEAGLE 1.0 A U TO D E S K I D E A S TU D I O R E S E A R C H P R O J E C T

U N I V E R S I TY O F S O U T H E R N C A L I F O R N I A

Project Team: Principle Investigator: Dr. David Jason Gerber Assistant Professor, USC School of Architecture Professor of Engineering, USC Sonny Astani Department of Civil and Environmental Engineering (Courtesy Joint) [email protected] Research Assistant: Shih-Hsin (Eve) Lin, LEED AP BD+C Ph.D. Candidate, USC School of Architecture [email protected] Bei (Penny) Pan Ph.D. Student, USC Department of Computer Science [email protected] Document Category: Technical Report Last Date of Revision: 20 January 2012

H.D.S Beagle 1.0 (His/Her Design Service Beagle 1.0) Inspired by Charles Darwin’s evolutionary theory, the USC IDEA Studio Applet is a reference to his sailing vessel – H.M.S. Beagle. The name reflects the goal of the project, which is to carry all the different design perspectives through the evolutionary process.

USC IDEA STUDIO RESEARCH | Design Optioneering Dr. David Jason Gerber, Shih-Hsin (Eve) Lin, Bei (Penny) Pan

ACKNOWLEDGEMENTS Many thanks for the research opportunity and for all the support provided by the Autodesk IDEA Studio. Thanks to Kimberly Whinna, who coordinated the research team with all the possible resources to support the research. Many thanks to the Vasari team, ADN, and Green Building Studio team for providing biweekly consulting time to help solve the encountered issues, in particular Matt Jezyk and John Kennedy for all their help and support. Special thanks to the following people who, with all their support and contributions, made this research possible. David Astbury, Sr. Research Manager Arjun Ayyar, Senior Software Engineer Nancy Clark Brown, Sr. Manager, America’s Education Programs Jeff Clayton, Gallery Technical Specialist Jim Cowan, AEC Education Solutions Specialist Aniruddha Deodhar, Program Manager, Sustainability Mikako Harada, AEC Technical Lead, Autodesk Developer Network Akimitsu Hogge, Intern Rick Jones, Facilities Consultant Electra Katelanis, Marketing – IDEA Studio Intern Zachary Kron, Sr. QA Analyst Cosimo Leone, Intern Ian Molloy, Energy Analysis Engineer Lira Nikolovska, User Experience Architect Jim Quanci, Director, Autodesk Developer Network Melrose B. Ross, Resource Specialist, Autodesk Developer Network Lillian Smith, Principal User Experience Designer Gopinath Taget, Senior Developer Consultant, Autodesk Developer Network Barry Tsai, Software Development Manager Tom Vollaro, Sr. Principal Interaction Designer Mark Webb, Software Development Manager Jason Winstanley, Director, AEC User Experience Also thanks to Laura Haymond and Tiffany Lai for all her editing support.

2


TABLE OF CONTENTS ACKNOWLEDGEMENTS .......................................................................................................................................... 2 TABLE OF CONTENTS.............................................................................................................................................. 3 LIST OF TABLES ...................................................................................................................................................... 5 LIST OF FIGURES..................................................................................................................................................... 6 ABSTRACT .............................................................................................................................................................. 8 ABBREVIATIONS .................................................................................................................................................... 9 1

INTRODUCTION ........................................................................................................................................... 10 1.1 1.2

2

ORIGINAL PROJECT PROPOSAL ...........................................................................................................................10 INTRODUCTION OF THE REPORT .........................................................................................................................13

METHODOLOGY .......................................................................................................................................... 14 2.1 SYSTEM OVERVIEW .........................................................................................................................................14 2.2 PROBLEM FORMULATION: PARAMETERS, DESIGN SCENARIO AND OBJECTIVE FUNCTIONS..............................................17 2.2.1 Parameter Categories ............................................................................................................................17 2.2.2 Design Scenario ......................................................................................................................................35 2.2.3 Objective Functions ................................................................................................................................40 2.2.4 Summary ................................................................................................................................................41 2.3 CONCEPTUAL ENERGY ANALYSIS (CEA) WORKFLOW..............................................................................................42 2.3.1 Method to Parameterize and Identify the Zone .....................................................................................42 2.3.2 Approaches considered regarding the appropriateness of the energy simulation result ......................45 2.3.3 Summary of the Final CEA Workflow .....................................................................................................47 2.4 DESIGN EXPLORATION & OPTIMIZATION..............................................................................................................48 2.4.1 Introduction of Genetic Algorithm .........................................................................................................48 2.4.2 Project Problem Introduction and Objectives ........................................................................................49 2.4.3 Genetic Algorithm of this Project ...........................................................................................................51

3

TECHNICAL DEVELOPMENT DETAIL .............................................................................................................. 57 3.1 SYSTEM OVERVIEW .........................................................................................................................................57 3.1.1 Integration Data Flow Chart ..................................................................................................................57 3.1.2 System Architecture of H.D.S. Beagle 1.0 ..............................................................................................59 3.1.3 H.D.S. Beagle 1.0 User Interface Introduction .......................................................................................60 3.2 PROCESS INTEGRATION & AUTOMATION .............................................................................................................61 3.2.1 Vasari Automation .................................................................................................................................61 3.2.2 Excel Automation ...................................................................................................................................70 3.2.3 GBS Automation.....................................................................................................................................73 3.3 CLOUD COMPUTING STRATEGIES (INTERNAL USE) .................................................................................................86 3.3.1 Motivation for Cloud ..............................................................................................................................86 3.3.2 Cloud Architecture in H.D.S Beagle 1.0 ..................................................................................................86 3.3.3 Existing Cloud Services Comparison (Microsoft & Amazon) ..................................................................88 3.3.4 Final Notes .............................................................................................................................................88

4

TEST CASES & ANALYSIS RESULTS ................................................................................................................ 89 4.1 4.2 4.3 4.4

SCENARIO 1 – SITE EXTRUSION WITH COURTYARD .................................................................................................93 SCENARIO 2 – FOUR GEOMETRIES FOUR SPACES TYPES ..........................................................................................95 SCENARIO 3 – FLUCTUATING ROOF .....................................................................................................................98 SCENARIO 4 – STACKING BOXES .......................................................................................................................101 3


4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 4.13 4.14 5

SCENARIO 5 – TWISTED TOWER 1 ....................................................................................................................104 SCENARIO 6 – ORTHOGONAL BOX ....................................................................................................................106 SCENARIO 7 – TOWER WITH NO TWIST AND 4 SPACE TYPES ..................................................................................109 SCENARIO 8 – TWISTED TOWER WITH 2 SPACE TYPES ..........................................................................................110 SCENARIO 9 – TOWER WITH NO TWIST AND 2 SPACE TYPES ..................................................................................111 SCENARIO 10 - OFFICE ...................................................................................................................................114 SCENARIO 11 – ADSK NOVI ...........................................................................................................................117 SCENARIO 12 – MODIFIED TWISTED TOWER ......................................................................................................119 SCENARIO 13 – LAUSD PROJECT.....................................................................................................................121 RUN TIME SUMMARY ....................................................................................................................................124

SUMMARY ................................................................................................................................................. 125 5.1 5.2

MAJOR ISSUES ENCOUNTERED .........................................................................................................................125 CURRENT LIMITATIONS OF H.D.S. BEAGLE 1.0 ...................................................................................................127

REFERENCES....................................................................................................................................................... 129 APPENDIX A A.1 A.2 A.3

PREPARE MODEL & CONSTRAINT FILE ...............................................................................................................131 SET UP EXTERNAL TOOL ADD-IN ......................................................................................................................160 EXECUTE ADD-IN COMMAND: PRODUCT USER INTERFACE GUIDELINES ...................................................................162

APPENDIX B B.1 B.2

PREVIOUS DEMO DOCUMENTATION ........................................................................................ 167

DEMO DEVELOPMENT ROAD MAP ...................................................................................................................167 DEMO USER INTERFACE IMPROVEMENT ............................................................................................................168

APPENDIX C C.1 C.2 C.3 C.4

APPLICATION USER MANUAL .................................................................................................... 130

TECHNICAL FAQ ........................................................................................................................ 175

ADN SUBMITTED QUESTIONS .........................................................................................................................175 TEAM MEETING QUESTIONS ...........................................................................................................................178 BASIC PROGRAMMING QUESTIONS ...................................................................................................................181 OTHER FAQ.................................................................................................................................................188

APPENDIX D

SAMPLE CODE ........................................................................................................................... 190

D.1 SAMPLE CODE DESCRIPTION............................................................................................................................190 D.1.1 RFA file Processing ...............................................................................................................................190 D.1.2 Excel processing ...................................................................................................................................191 D.1.3 Conceptual energy analysis .................................................................................................................192 D.1.4 Concetual Construction Processing ......................................................................................................193 D.1.5 Mass Population ..................................................................................................................................194 D.2 SAMPLE CODE MANUAL .................................................................................................................................196

4


LIST OF TABLES Table 1: Global energy parameters used in this project ............................................................................. 27 Table 2: The 32 building types categories used in GBS and its energy related parameter setting ............ 29 Table 3: Conceptual construction categories and its related energy parameter ....................................... 30 Table 4: Individual modifiable mass element energy setting parameters.................................................. 31 Table 5: H.D.S. Beagle 1.0 - financial related parameters .......................................................................... 34 Table 6: Scenario development roadmap ................................................................................................... 38 Table 7: CEA approaches comparison......................................................................................................... 47 Table 8: The comparison between classic Genetic Algorithm and the applied GA in H.D.S. Beagle 1.0 .... 51 Table 9: The Excel automation running performance comparision ........................................................... 72 Table 10: The automation summary of getting energy analysis result from GBS by using GBS SDK ......... 76 Table 11: Vasari Excel part testing summary .............................................................................................. 82 Table 12: Existing cloud services comparison ............................................................................................. 88 Table 13: Scenarios summary ..................................................................................................................... 89 Table 14: Scenario 1 parametric model design........................................................................................... 93 Table 15: Scenario 2 parametric model design........................................................................................... 96 Table 16: Scenario 3 parametric model design........................................................................................... 99 Table 17: Scenario 4 parametric model design......................................................................................... 102 Table 18: Scenario 5 parametric model design......................................................................................... 104 Table 19: Scenario 6 parametric model design......................................................................................... 106 Table 20: Scenario 7 parametric model design......................................................................................... 109 Table 21: Scenario 8 parametric model design......................................................................................... 110 Table 22: Scenario 9 parametric model design......................................................................................... 111 Table 23: Scenario 10 parametric model design....................................................................................... 114 Table 24: Scenario 11 parametric model design....................................................................................... 117 Table 25: Scenario 12 parametric model design....................................................................................... 119 Table 26: Scenario 13 parametric model design....................................................................................... 121 Table 27: Scenario 13 analysis result summary ........................................................................................ 123 Table 28: Scenario 13 energy simulation feedback process comparison ................................................. 123 Table 29: Scenarios’ run time summary ................................................................................................... 124 Table 30: Worksheets name and description in the constraints file ........................................................ 156 Table 31: Demo 1 user interface description............................................................................................ 168 Table 32: Demo 2 user interface description............................................................................................ 169 Table 33: Demo 3 user interface description............................................................................................ 172 Table 34: Demo 4 user interface description............................................................................................ 173

5


LIST OF FIGURES Figure 1: Original proposed system information loop ................................................................................ 10 Figure 2: Final system architecture of H.D.S. Beagle 1.0 ............................................................................ 15 Figure 3: Parameterizing method - exploring different width and depth combinations while providing a consistent footprint area. ........................................................................................................................... 19 Figure 4: Parameterizing method - exploring varying building orientations. ............................................. 19 Figure 5: Parameterization - setting site boundaries.................................................................................. 20 Figure 6: Parameterization -using site constraints to drive the geometry ................................................. 21 Figure 7: Parameterization - include level height and number of levels as drivers to determine the total height of the geometry ............................................................................................................................... 22 Figure 8: Illustration of CEA process: A. create mass family; B. associate mass with level; C. enable energy model .......................................................................................................................................................... 22 Figure 9: Vasai’s Energy Setting dialog box................................................................................................. 25 Figure 10: Mass Opening, Mass Exterior Wall and Mass Glazing individual property setting dialog box .. 32 Figure 11: H.D.S. Beagle 1.0 - financial model ............................................................................................ 33 Figure 12: Sunset Boulevard site satellite image from Google Earth ......................................................... 35 Figure 13: Site zoning at the West Hollywood zoning map (City of West Hollywood 2011)................... 36 Figure 14: A. Form properties in the Mass Family editing environment; B. Mass properties in the project environment. .............................................................................................................................................. 43 Figure 15: Mass Family types properties .................................................................................................... 44 Figure 16: CEA’s testing configuration ........................................................................................................ 46 Figure 17: Typical framework of Genetic Algorithm ................................................................................... 48 Figure 18: Design parameters for a simple orthogonal building ................................................................ 50 Figure 19: H.D.S. Beagle 1.0 information flow diagram.............................................................................. 57 Figure 20: System architecture of H.D.S. Beagle 1.0 .................................................................................. 59 Figure 21: Green Building Studio parallelism diagram within H.D.S. Beagle 1.0 ........................................ 78 Figure 22: Vasari parallelism diagram in H.D.S. Beagle 1.0 ........................................................................ 81 Figure 23: Summary diagram of GBS automation ...................................................................................... 83 Figure 24: H.D.S. Beagle 1.0 – GBS version folder structure....................................................................... 84 Figure 25: H.D.S. Beagle 1.0 – Vasari version folder structure ................................................................... 85 Figure 26: Cloud structure for H.D.S Beagle 1.0 ......................................................................................... 86 Figure 27: Scenario 2 experiment results ................................................................................................... 97 Figure 28: Scenario 3 error - inability to form the Mass Zone. ................................................................. 100 Figure 29: Scenario 3 experiment results ................................................................................................. 100 Figure 30: Scenario 4 - Run_20110919_1213 setting ............................................................................... 103 Figure 31: Scenario 4 - Run_20110919_1213 result illustration .............................................................. 103 Figure 32: Scenario 5 variations ................................................................................................................ 105 Figure 33: Scenario 6 – GBS_Run_20110930_1432 settings .................................................................... 107 Figure 34: Scenario 6 – GBS_Run_20110930_1432 result illustration I ................................................... 107 Figure 35: Scenario 6 – GBS_Run_20110930_1432 result illustration II .................................................. 108 Figure 36: Scenario 9 – GBS_Run_20111014_0828 setting ...................................................................... 112 Figure 37: Scenario 9 – GBS_Run_20111014_0828 result illustration I ................................................... 112 Figure 38: Scenario 9 – GBS_Run_20111014_0828 result illustration II .................................................. 113 Figure 39: Scenario 10 is a geometrically moderate case. The total modifiable parameter number is 6. The result shows the improvement of EUI and NPV when the generation number increases. ............... 115 6


Figure 40: Scenario 10 - Run_20110919_1213 result illustration ............................................................ 116 Figure 41: Scenario 11 result illustration .................................................................................................. 118 Figure 42: Scenario 12 result illustration .................................................................................................. 120 Figure 43: Overall H.D.S. Beagle 1.0 workflow ......................................................................................... 130 Figure 46: H.D.S. Beagle 1.0 technical development road map ............................................................... 167

7


ABSTRACT This research describes a Design Optioneering methodology that is intended to offer multidisciplinary design teams the ability to systematically explore a large number of design options much more rapidly than current conventional methods. Design Optioneering involves defining a range of design options using associative parametric design tools, coupling the model with integrated simulation-based analysis, and using computational design optimization methods to systematically search though the defined range of alternatives in search of design options that best achieve the problem objectives while satisfying any constraints. This research seeks to further develop, test, and validate a Design Optioneering method for use by students and practitioners. The performance of the proposed methodology will be discussed in terms of a designer’s ability to capture the design intent by integrating parametric modeling with expert analysis domains, which can then generate a large number of alternatives from which to choose. Finally, the potential of Design Optioneering to reduce latency, advance domain integration, and enable the evaluation of more design alternatives in practice will be further enumerated and related to cloud computing strategies for design. The overall research is separated into two phases: the technical development phase and data generation and analysis phase. This report primarily focuses on documenting the technical development of the prototype, which includes the detailed technical development roadmap, questions and issues encountered, and the decision making process. The final product of the technical development period and limitations will also be explored and discussed.

8


ABBREVIATIONS ADN AEC API CAD CAE CEA EUI FAR GA GUI GUID GBS MDO MEP NPV PI SDK UI

Autodesk Development Network Architecture, Engineer and Construction Application Programing Interface Computer-Aided Design Computer-Aided Engineering Conceptual Energy Analysis Energy Use Intensity Floor Area Ratio Genetic Algorithm Graphic User Interface Globally Unique Identifier The Autodesk® Green Building Studio® web-based energy analysis service Multidiscipline Design Optimization Mechanical Electrical and Pluming Net Present Value Principle Investigator Software Development Kit User Interface

9


1 INTRODUCTION 1.1 ORIGINAL PROJECT PROPOSAL The research seeks to experiment with integrating Autodesk’s Vasari, Green Building Studio (gbXML), and Maya with an Excel based financial model in an automation and optimization routine. The prototype will integrate conceptual design and conceptual energy use with development economics, Vasari, Maya, Green Building Studio, and Excel. The research proposes to develop a working prototype or a roadmap/specification of a prototype, a technical report, and an exhibition of the platform product in the form of 3D prints and a visually and analytically rich wallpaper and website.

Figure 1: Original proposed system information loop

Need: Conventional practice, methods and current research are limited by the technical ability and understanding of the value of parametric design coupled with simulation and optimization in a semi-automated feedback loop. Current Computer-Aided Design and Engineering (CAD/CAE) tools allow architects and engineers to simulate many different aspects of building performance (e.g. financial, structure, energy, lighting). However, designers are often not able to leverage simulation tools early in the design process because of the time required to complete a design cycle: it often takes multidisciplinary design teams longer than a month to complete a single cycle. High design cycle latency in current practice has been attributed to software interoperability and lack of collaboration between design disciplines, among other issues. Associative parametric CAD tools have been shown to both reduce latency associated with the generation of design options and manage greater project complexity. A parameter in this context is a design variable that can be associated or related to other parameters to define particular design logic. The designer can then manipulate a single parameter or set of parameters to rapidly generate 10


many unique design configurations. Parametric modeling as a concept and mathematical construct (e.g. parametric curves and surfaces) has been around for years, with the first parametric CAD tools emerging in the 1960’s. However, providing tools that enable designers to readily develop these robust and rigorous input models that describe their design intent in order to guide design generation remains a challenge. The use of associative parametric tools to reduce design cycle latency in current AEC practice has been limited primarily by two factors. First is the inherent difference in the way architects, owners, and engineers iteratively define and represent design, which makes it difficult for these disciplines to agree on a common parametric representation of the design. This is particularly apparent when collaboration is limited by organizational and/or geographic boundaries. Few methods have been developed to instruct practitioners on how to use parametric methods in collaborative, multidisciplinary environments; those that have been developed have not been widely disseminated. The second factor involves the limited interoperability between the parametric CAD tools commonly used by architects and the CAE tools used for engineering analysis. Because of this, engineers are not able to provide timely simulation-based performance feedback on the parametric variations generated by the design team, with few exceptions. This research proposal introduces the Design Optioneering methodology, which aims to address the limitations associated with parametric modeling discussed above. The research is conceived through the following structure. First, a Design Optioneering method is described. Second, the context of initial use is described and put into practice; the findings of the use-case are then presented. Finally, the potential implications of Design Optioneering to reduce latency and enable the evaluation of more design alternatives in practice are discussed. Proposed Research: The Design Optioneering methodology for Multidisciplinary Design Optimization (MDO) consists of three primary activities which are described in more detail below: problem formulation, process integration, and design exploration/optimization. Problem Formulation: The first step is to formally define the design problem, including the design objective, variables, and constraints. The design objective is the goal of the optimization exercise and involves maximizing or minimizing a real function (e.g. cost, energy consumption, etc.). The constraints are the criteria that a design option must satisfy to be considered feasible. Finally, the variables are the parameters of the design that can be manipulated within a defined range to achieve the objectives and satisfy the constraints. These definitions are then used to inform the creation of an associative parametric digital model. This involves creating a parametric representation of the project in CAD that is driven by the design variables specified. Designers can then test the parametric model by modifying the variable values and observing the resulting design configuration to ensure that it is consistent with their original design intent. The iterative nature of this process allows the observations made from variable testing to lead to the selection of new variables and/or ranges as well as the refinement of parametric model logic. Process Integration: The goal of this activity is to create an integrated process model that includes the parametric CAD model created in the previous activity as well as any financial/CAE models used to assess design objectives and constraints. Process integration involves first defining the information dependencies between all of the different tools used in the design process. Next, the data flow between the tools is automated to reduce the design cycle latency that is pervasive in current practice. Finally, the integrity of the data flow and the analysis representation is checked by 11


modifying the variables in the parametric CAD model and ensuring that the necessary analysis configurations update correctly to ensure rapid evaluation of all design domains. Design Exploration/Optimization: Once the design problem is formalized and an integrated process model has been created, the designer will be capable of completing a design cycle much more rapidly than conventional processes. However, exploring the design space using manual trial and error methods is still often impractical due to the large number of possible alternatives. In this case, computational techniques such as Design of Experiments or optimization algorithms can be applied to systematically explore the design space in an automated fashion. The proposed approach includes several experimental steps towards enhanced and enriched integration of parametric and analytical domains and tools sets. 1) As described above this proposal tests the integration of Vasari and Green Building Studio with an optimization feedback loop through a financial model, with exports to Maya for visualizations and 3D print generation. 2) Most of the initial effort is expected to be in technology integration through existing API’s. A use case in the form of a tall building scenario will then be developed to generate an expansive solution space and set of graphics illustrating the expansion of the solution space, the correlation of quality and analysis of each solution, and the reduction in design cycle latency. 3) Finally, a tangible exhibition of the Design Optioneering process will be presented through the use of the IDEA studio’s 2D and 3D printing capabilities. The integration is first demonstrated with a financial analysis, since it is the initial and necessary integration that a design project would incorporate. Owners would begin with a financial model and derive a brief with which an architect would generate geometric solutions. Following this integration would be structural and more detailed environmental performance domain integrations for future research and sponsorship. Phase 1: Platform specification, platform tool integration, testing, experimental runs, and product generation (2D graphics and analysis, renderings, and plots; and 3D prints with analytical data). Phase 2: Publication, post production, data analysis and exhibition of the work. Educational Outreach: All the PI’s research proposals and projects are reported to the University Provost’s office and approved by the School of Architecture Dean and Vice Dean. Federal and Corporate sponsorships are recorded and disseminated by the Dean’s Development Office and the University Provost’s Sponsored Research Office. Faculty teaching and research activities are reported in both the Undergraduate and Graduate program peer reviews and NAAB accreditation reviews. We will ensure that the research is included in our annual reports. The PI is specifically targeting a number of journals and design and computation conference venues, including the International Journal of Architecture and Computing, The Journal of Design Studies, The Journal of Automation and Construction, and the Journal of Architecture Education. The conference targets include ISARC, ACADIA, CAADRIA, ECADDE, SIMAUD, CAAD FUTURES, Autodesk University, DCC, Siggraph, and ultimately TED. In addition to publication and dissemination of the research through conferences and lecturing, we would like to bring this cutting edge and emerging technology solution into the classroom. This would eventually include integration with the PI’s design seminar sequence and design studios along with other domains and departments like civil engineering, where the PI holds a joint appointment. The courses typically involve graduate and advanced standing undergraduate students and can be brought into the curriculum rapidly through the development of an experimental course which, if successful, can become a repeatable elective or

12


eventually a core component with the understanding that it fulfills and exceeds NAAB accreditation criteria. Broader Impacts: Results of the study could be used to further validate the importance and possibility of domain integration within the AEC. The design hypothesis – that design can be further aided by intelligent computing – will also contribute to the real world problem of design cycle latency. The broadest impact would be to illustrate visually and prove analytically the potential and value of Design Optioneering as a new collaboration paradigm that allows for rapid design iteration, rapid design evaluation, and rapid search for optimality.

1.2 INTRODUCTION OF THE REPORT This report is a research experiment documenting the working prototype of the Design Optioneering platform that was generated during the technical development period. This report includes the following: tool integration method, recording of all encountered issues, prototype user manual, and a comprehensive description of each step of the tool’s definition and use. Also included are issues where further development is recommended for the prototype to be fully realized. This report will also include a sample of coding utilized by the prototype and files used during the testing phase.

13


2 METHODOLOGY 2.1 SYSTEM OVERVIEW During the prototype development period the information flow and tool integration method was evolved from the original proposed method (Figure 1) to the current system architecture as illustrated in Figure 2. It should be noted at this time that, due to time limitations, the 2D and 3D representation portion of the integration was excluded from this technical development period. While the major platforms used – Autodesk® Project Vasari 2.0/Revit Architecture 2012, the Autodesk® Green Building Studio® web-based energy analysis service (GBS), and Microsoft® Excel 2010 – maintained their purpose as contributing tools throughout the course of the research, the exact nature of their purpose as tools were expanded and modified according to evolving needs of the prototype. Autodesk® Project Vasari 2.0 /Revit Architecture 2012 (Vasari): This is the major parameterization platform enabling designers to define their geometry while providing a series of parameters that impact the development of varying geometric configurations. This platform also serves as an insert point for the energy settings necessary for a schematic energy analysis through GBS. This provides a streamlining capability for generating analysis results and bypasses parameters necessary for a more extensive energy analysis through GBS. The process utilizes the Energy Setting dialog box designed in Vasari 2.0/Revit Architecture 2012 by the Vasari team which intentionally employs a simplified energy assessment designed to be more accessible at the early stages of the design phase. While there are various sophisticated usages proved by Vasari/Revit, this project mainly utilizes the Conceptual Design Environment where mass families were the main objects to present the design form. NOTE: At the beginning of this project the research team needed to select an implementation platform between Revit Architecture 2012 and Vasari2.0. While both platforms provided the same functions required by the project, only Revit Architecture 2012 API offered extensive technical support through the Autodesk Developer Network (ADN). At the suggestion of the Vasari Team, the research team decided to develop the prototype using Revit Architecture 2012 with the intention that the resulting product be compatible with Project Vasari 2.0. In addition, during the prototype development period of this project, the Vasari team improved Vasari’s API functionality and provided the newly developed API for the team to use at the end of the research period. As a result, there were various Vasari versions tested during the development phase. Please refer to Section 3 for a more detailed record. For this report, Vasari is used to represent the design platform, including Vasari 2.0, Vasari 2.1, and other Vasari Build versions, unless otherwise specified. As Revit Architecture 2012 is to have Vasari incorporated into the program the term Vasari is to include reference to Revit Architecture 2012 as well.

Autodesk® Green Building Studio® web-based energy analysis service (GBS): This serves as the energy simulation engine for the prototype. The original intent of this research was for H.D.S. Beagle 1.0 to be able to interact with GBS and utilize its extensive parameter settings (compared to the limited parameter settings available in Vasari). However, the research team was unable to gain 14


access to the GBS Software Development Kit (SDK) until the late stages of the research period, thereby reducing the ability to explore integration options with H.D.S. Beagle 1.0 and GBS. In addition, the received SDK functionality did not include the ability to vary parameters directly through GBS. As a result, H.D.S. Beagle 1.0 utilizes the energy settings available in Vasari as a more effective means of acquiring the necessary information to proceed with the research. Despite the energy settings input being generated through Vasari, there was still a need for direct interaction with GBS and H.D.S. Beagle 1.0. This is due to the inability of Vasari API to provide the function of automatically generating analysis results as desired. During the automation process there were various options of automatically obtaining energy analysis results explored. For detailed documentation please refer to the 0 section. Microsoft® Excel 2010® (Excel): For the current project framework Excel is crucial, not only as a financial Pro Forma and as a means of containing the financial parameters, but also as a platform on which designers can set up design parameter ranges, constraints, the design score calculation formula, etc. This is due to the current framework requiring a platform for designers to inform H.D.S. Beagle 1.0 on how to vary specified parameters and how to calculate the design score. Currently Vasari does not provide these functions, and each design project and configuration contains unique combinations of parameters and constraints. Therefor the research team found that the most straightforward method was to generate an Excel template from which the application could read the user-defined parameter variation ranges, level settings, and calculation formula. For the detail setting format and manual please refer to Appendix A.1.

Figure 2: Final system architecture of H.D.S. Beagle 1.0

H.D.S. Beagle 1.0: This plugin, created by the research team, is the core of this body of research. It integrates the necessary information of each platform and enables multidiscipline optimization and optioneering. The following is a summary of provided functions by H.D.S. Beagle: 1. Automatically assigns individual identification means for all surfaces. 2. Calculates design and financial objective functions according to definitions provided by Excel. 3. Obtains the objective function of energy performance from a gbXML file. 4. Updates geometry definitions in Vasari according to the populated parameter values. 15


5. Connects to GBS for energy analysis. 6. Enables user-defined Genetic Algorithm settings to proceed population, Pareto ranking, selection and repopulation. For the detailed development code and algorithms of each function please refer to Section 3. The following report will present the prototype methodology in these three major components: 1. Problem Formulation 2. Multidiscipline Design Optimization Methodology and Algorithm 3. Automation Method The above components enable the creation of the solution spaces as proposed by the user. Section 2 focuses on the problem formulation and optimization algorithm. The detailed automation method and technical development is documented in Section 3.2.

16


2.2 PROBLEM FORMULATION: PARAMETERS, DESIGN SCENARIO AND OBJECTIVE FUNCTIONS In order to automatically generate a solution space for optioneering, it is necessary to first formally define the design problem. This includes formally defining the design objectives, variables, and constraints. The design objectives are defined as the goals of the optimization exercise and generally involve maximizing or minimizing a real function (e.g. cost, energy consumption, etc.). Constraints are defined as the criteria that a design option must satisfy in order to be considered a feasible design solution (e.g. site setbacks, height constraints, etc.). The variables are parameters of the design that can be manipulated within a defined range to achieve the objectives and satisfy the constraints. These definitions are then used to generate an associative parametric digital model. This involves creating a parametric representation of the project in CAD – for this example, Vasari – that is driven by the design variables specified. Designers can then test the model by modifying the variables and observing the resulting design configuration to ensure consistency with design intent. This section describes the method of formulating the design problem in order for H.D.S. Beagle 1.0 to provide a series of automatically generated design scenarios. This section includes the case categories that the research team used for testing the framework and the cases that served as means of validation. In addition, the definition of the parameters and objective functions that H.D.S. Beagle 1.0 used as a basis for selection and ranking of each design configuration is provided. Finally, this section documents the testing performed by the research and the resulting workflow.

2.2.1 PARAMETER CATEGORIES One of the most critical issues when dealing with parameter driven design exploration is the thorough definition and coordination of parameters between H.D.S. Beagle 1.0, Vasari, and Excel. Essentially, if there is an interest in exploring the impact of an element through a series of parametric values, for example the height of the building, this parameter must be consistently named and defined across all platforms that are being utilized. H.D.S. Beagle cannot explore the impact on varying the height of the building if what is used to determine the height of the building is not defined in Vasari and if the range of values of interest is not defined in Excel. Therefore, careful consideration and time must be taken to carefully layout what elements are of interest and what parameters are necessary in each platform before proceeding. There were varying parameters used in this project within the specific platform. These parameters can be categorized into three areas according to their use: 1. Design Parameters 2. Energy Setting Parameters 3. Financial Pro Forma Parameters The following sections provide a more detailed description of each parameter’s definition and usage with regards to this project.

17


2.2.1.1 DESIGN PARAMETERS Parameters in this category were typically used to define the design configuration. In this project, Vasari was used as the design platform, therefore this project utilized the “Conceptual Design Environmenti” and the “Conceptual Energy Analysisii” functions as provided by Vasari. In Vasari, the Conceptual Design Environment was initially designed for designers to explore design ideas using mass forms. Vasari also has the Conceptual Energy Analysis function available at this stage which translates the mass form into an energy model (gbXML) to be provided to GBS for energy analysis. (Autodesk, Inc. 2011) As such, all design parameters were associated with the Mass Family and thereby provided influence solely in application to the available massing configurations of the design problem in question. One goal of the research is for each design configuration to reflect the design intent, site constraints and varying level to level height and space usage. As a result, the parameterizing process needs to take into consideration at least a three step thinking process: 1. Form driving parameters: design intent 2. Site Constraints parameters: take site constraints into consideration 3. Level setting parameters: enable varying level to level heights and assign space usage accordingly. The following is a more detailed description of the parameterization process and how to implement it with regards to generating designed geometry. Form Driving Parameters: In order for the system to automatically generate solution spaces later on, the parameter settings should reflect a designer’s design intent and reflect how they want to explore possible geometric solutions. As a result, designers cannot proceed with manually manipulating 3D geometry as a means of exploring design ideas, but need to critically contemplate how to explore the geometry through a series of defined desired attributes. As each design problem is unique in its collection of desired attributes this exact process will vary individually by design problem and designer. For a simplified example, if there is an interest in exploring the various depth and width combinations available with an equivalent footprint area, then the setup of a width ( ) and depth ( ) parameter to drive the geometry would be needed. In order to ensure a constant footprint area, another parameter with a constant value ( ) would be needed. The resulting calculation would then proceed to explore the various combinations of width and depth so that area remained constant, as shown in Figure 3. For another example, if there is an interest to explore the possible orientations of an entire building, then the rotate angle ( ) parameter must be defined as such that the possibilities of entire building rotations can be displayed, as shown in Figure 4.

http://wikihelp.autodesk.com/Revit/enu/2012/Help/Revit_User's_Guide/0140-Prelimin140/0208Conceptu208#WS1A9193826455F5FF-7F10494411F03A24F24-6CEC ii http://wikihelp.autodesk.com/Revit/enu/2012/Help/Revit_User's_Guide/2427-Analyze_2427/2428-Conceptu2428 i

18


Figure 3: Parameterizing method - exploring different width and depth combination s while providing a consistent footprint area.

Figure 4: Parameterizing method - exploring varying building orientations.

19


Site Constraints Aside from form driving parameters, constraints of the site must also be considered in order to generate feasible design solutions to a design problem. Therefore, parameters reflecting site constraints must be defined as needed. For example, the previously defined problem regarding the varying available width and depth combinations while maintaining a defined footprint area would provide a series of solutions that meet these criteria. However, only solutions which feel with the confines of a site setback could be considered feasible. Therefore, in order to isolate the various width and depth combinations available that are feasible for a site, the parameter defining the site setback requirements must be defined. In order to define the site setback constraints the site boundary must be defined first in the Mass family, as shown in Figure 5. This parameter is then set to constrain the geometry or used as a means of evaluation. For example, if the site setback requirement is a minimum of 15ft, the site setback ( ) parameter should be set to have a range of at least 15ft to the desired value, i.e. the setback parameters should be set from 15ft to 20ft instead of 10ft to 20ft. Another approach is to use the parameter value to evaluate or filter the varying scenarios. For example, if the total height limit of the site is 60ft, there is the desire to explore geometry beyond this requirement then the variation range can be set from 50ft to 80ft with the use of the value of 60ft as an evaluation or filter criteria at the end. Figure 6 illustrates how the exploration of possible width and depth values of a building are now further constrained by the site boundary and the site setback value.

Figure 5: Parameterization - setting site boundaries 20


Figure 6: Parameterization -using site constraints to drive the geometry

Level Numbers, Level to Level Height & Space Usage The last parameter category is the parameters related to the level setting. There are two reasons to have the parameters in a separate category. One is due to the need generated by real world application. The other is because of the specific system configuration of Vasari platform. With regards to the need generated by real world applications, in order to explore space programing area, level numbers and level to level height of each space is necessary in evaluating possible design solutions. In order for H.D.S. Beagle 1.0 to explore varying values for a parameter and the resulting influence of said parameters on the generated geometry, these parameters should be defined within the mass family. For example, the total height of a building is no longer solely driven by a single parameter ( ). Now it should be driven by the combination of floorto-floor height ( ) and the level number ( ) so that the . Therefore, in order to enable the floor-to-floor height ( ) and the level number ( ) as part of the driving parameters that influence generated design solutions these parameters must be included within the Mass Family. Figure 7 below uses the orthogonal building geometry as an example to demonstrate a parameter setting that takes level parameters into consideration.

21


Figure 7: Parameterization - include level height and number of levels as drivers to determine the total height of the geometry

The other importance of the level setting parameters is due of the system configuration design of Vasari. One of the important functions that H.D.S Beagle 1.0 utilizes is the “Conceptual Energy Analysis” (CEA) function provided by Vasari. The CEA function translates mass families into an energy model as a gbXML file format that is then provided to GBS for energy analysis. The critical key process to enable the smooth translation is to associate mass with each level of the project, otherwise an energy model cannot be generated by Vasari. Figure 8 illustrates a mass without assigned mass floors, and one with mass floors assigned. Also please note the model with the mass floors assigned is the one with the energy model enabled in Vasari. The more detailed conceptual energy analysis process can be found on the Autodesk’s WikiHelp page.i

Figure 8: Illustration of CEA process: A. create mass family; B. associate mass with level; C. enable energy model

i

http://wikihelp.autodesk.com/Revit/enu/2012 22


Level is a Datum Elementi available only when handling the project in question and cannot be altered when defining Mass Family element. A level is considered to be a system familyii and thereby can only be modified in the project environment. As a result, in order to synchronize the geometry variations and the project levels, H.D.S. Beagle 1.0 needs to read the level setting in the Excel template to automatically update the geometry (mass family) and the project level settings simultaneously. In order to accomplish this, it is not only important to have geometry (mass family) possess level relative parameters but these parameter settings must also be coordinated within the project environment. In addition, H.D.S. Beagle 1.0 must be notified on how to vary the level and the associated massing accordingly. This is done by coordinating the parameters previously defined with a range of values that there is interested in being explored. This also ensures that the geometry generated and the energy model generated during this process will coordinate, ensuring relevant feedback from the energy model analysis. This project also used the level parameters to link levels massing to specific program usage information that H.D.S. Beagle later uses when generating the energy model. For example, this is where information regarding occupancy type, material construction, glazing, etc. was ascribed. The scenarios used in the project will further demonstrate the parameterization method in detail. Please refer to Section 4 and to the Appendix A for more information.

Revit Elements are divided into six groups: Model, Sketch, View, Group, Annotation and Information. Please refer Element Classification from AutodeskWiki for more detail information. (http://wikihelp.autodesk.com/Revit/enu/2012/Help/API_Dev_Guide/0000-API_Deve0/0001-Introduc1/0034Elements34/0035-Element_35) ii There are three kinds of families in Revit Architecture: system families, loadable families, and in-place families. System families are predefined families that can only be modified in project environment. Please refer to System Family from AutodeskWiki for more detail information. (http://wikihelp.autodesk.com/Revit/enu/2012/Help/Revit_User%27s_Guide/0325-Build_th325/1279Revit_Fa1279/1296-System_F1296) i

23


2.2.1.2 ENERGY SETTING PARAMETERS For this project the number of parameters available for the energy performance calculation is determined by the available energy settings with in Vasari. Vasari divides energy related parameters between two places: 1) global energy settings (or project-wide settings) and 2) individual energy settings in mass zone and mass surfaces. To form the energy model, Vasari transforms a mass into an energy model with the following elements: 1. 2. 3. 4. 5. 6. 7. 8. 9.

Mass Exterior Wall Mass Floor Mass Glazing Mass Interior Wall Mass Opening Mass Roof Mass Skylight Mass zone Mass Shade

Each mass element has properties that are directly related to expected energy consumption. The user can either assign desired properties in the energy setting dialog box (global energy setting), as shown in Figure 9, or customize individual settings in the individual element energy setting dialog box.

24


Figure 9: Vasai’s Energy Setting dialog box

25


Table 1 summarizes the list of fixed & modifiable energy parameters used by this project within the global energy setting dialog box. Please note that not all modifiable energy settings in the energy dialog box are recommended to be utilized as modifiable parameters while running H.D.S. Beagle 1.0. For example, building type, ground plane, location, project phase, etc. are recommended to remain as fixed energy parameters for each run.

26


Table 1: Global energy parameters used in this project

ID

Parameter Name

Type

Common Building Type

Enumeration

Ground Plane Location Detailed Model Project Phase

Enumeration Address Enumeration

Sliver Space Tolerance

Double

Export Complexity Energy Model Create Energy Model Core Offset

Table 2 Level 1

New Construction (Project Length Unit)

Enumeration Yes/No Double Yes/No Enumeration

E2 E3

Divide Perimeter Zones Conceptual Construction E1-1 Mass Exterior Wall E1-2 Mass Interior Wall E1-3 Mass Exterior Wall - Underground E1-4 Mass Roof E1-5 Mass Floor E1-6 Mass Slab E1-7 Mass Glazing E1-8 Mass Skylight Mass Shade Mass Opening Target Percentage Glazing Target Sill Height

E4

Glazing is Shaded Shade Depth

Yes/No Double

E5 E6

Target Percentage Skylight Skylight Width & Depth

Double Double

E1

Range/List (Unit)

Double Double

Energy Model – Building Services Building Operation Schedule HVAC System Outdoor Air Information Note:

Enumeration Enumeration NA

* Project setting value

27

Yes (Project Length Unit) No Table 3

[0,1] [0,*] (Project Length Unit) Yes [0,*] (Project Length Unit) [0,1] [0,*] (Project Length Unit)

Modifiable (Yes/No)

Note

No

1

No No

2 3

No No

4

No

5

No No

6 7

No Yes Yes Yes Yes Yes Yes Yes Yes Yes No No Yes Yes

7

No Yes

Yes Yes

No No No

8 9


There are more detailed descriptions of each setting available in the “Energy Settings” section of Autodesk’s i WikiHelp. The following notes are additional notes specific for this project. Whether a parameter should be available as modifiable or not modifiable was recommended by the project team. Although H.D.S Beagle can be enabled to vary all defined parameters within the energy setting dialog box it is recommended that some parameters such as “Sliver Space Tolerance”, “Export Complexity”, “Outdoor Air Information”, etc. remain fixed for each run. 1.

There are 32 default types for users to select from. The building type includes assumptions about the typical schedule of the building based on usage. Please see 2. Table 2 for the assumption values of each building type. Due to the current limitations of GBS which do not allow for multiple building types in a single run it is necessary to assign only a sing building type for each run. The building type selected should be based on the most dominant building type to represent the whole project. (Please see Section 2.3 for further discussion resulting in this recommendation). While each building type has its own operation schedule assumption, the later “Building Operation Schedule” setting can overwrite the default assumption value of any building type. 3. This can be defined as any available level in the project. However, it is suggested to use Level 1 as the ground plan in order for other level parameters to be set accordingly. 4. Although it is possible to vary the project location, it is suggested for current H.D.S. Beagle design, to limit the sites explored to one location per run. Should alternative locations, and their impact on energy performance, be of interest then is recommended to that each location be run separately. 5. This value is recommended to be set as a fixed value within one project. 6. This relates the detail level of how the energy model is formed with 5 options available. More complex models will require longer formation time and delay analysis feedback. Here it is suggested to use “Simple with Shading Surfaces” for the conceptual analysis. 7. This has to be enabled so that the mass can be transform in to an energy model. 8. Although Vasari can automatically form the core and dividing parameter zones, the automatically generated core and zones might not meet the desired zoning and exploring method. As a result, this project does not utilize these two parameters to explore design solutions. 9. If the project uses the assumption value of the building type, the value can remain as “default.” Otherwise, there are 10 options to be selected from in order to overwrite the default value. 10. There are 12 choices in this category. It is recommended to specify one type for each run.

http://wikihelp.autodesk.com/Revit/enu/2012/Help/Revit_User%27s_Guide/2427-Analyze_2427/2428Conceptu2428/2432-Energy_S2432 i

28

Space Type_id

62 56 31 37 34 36 76 54 105 55 53 78 107 64 77 12 76 65 94 98 24 13 105 116 124 121 22 76 30 31 4 88 123

Building Type_id

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 34 28 29 30 31 32

gbXML-BuildingDefinition

Unknown AutomotiveFacility ConventionCenter Courthouse DiningBarLoungeOrLeisure DiningCafeteriaFastFood DiningFamily Dormitory ExerciseCenter FireStation Gymnasium HospitalOrHealthcare Hotel Library Manufacturing Motel MotionPictureTheatre MultiFamily Museum Office ParkingGarage Penitentiary PerformingArtsTheater PoliceStation PostOffice ReligiousBuilding Retail SchoolOrUniversity SingleFamily SportsArena TownHall Transportation Warehouse Workshop

People Per 100 Sq Meter 15 25 3.5 35 50 35 10 10 15 33.5 10 2.5 10 2.5 2.5 75 2.5 33.5 3.5 2.5 10 75 15 3.5 75 10 25 0.945 75 33.5 50 5 10

People Activity Level Standing, light work; walking Standing, light work; walking Moderately active office work Sedentary office work Sedentary office work Sedentary office work Standing, light work; walking Walking 3 mph; light machine work Standing, light work; walking Standing, light work; walking Standing, light work; walking Standing, light work; walking Standing, light work; walking Walking 3 mph; light machine work Standing, light work; walking Standing, light work; walking Standing, light work; walking Standing, light work; walking Standing, light work; walking Standing, light work; walking Standing, light work; walking Standing, light work; walking Standing, light work; walking Standing, light work; walking Standing, light work; walking Standing, light work; walking Standing, light work; walking Standing, light work; walking Standing, light work; walking Standing, light work; walking Standing, light work; walking Standing, light work; walking Light bench work

People Sensible Heat Gain (W/person) 73 73 73 81 81 81 73 110 73 73 73 73 73 110 73 73 73 73 73 73 73 73 73 73 73 73 73 73 73 73 73 73 81

People Latent Gain (W/person) 59 59 59 81 81 81 59 183 59 59 59 59 59 183 59 59 59 59 59 59 59 59 59 59 59 59 59 59 59 59 59 59 139

People Sensible Heat Gain (Btuh/person) 250 250 250 275 275 275 250 375 250 250 250 250 250 375 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 250 275

People Latent Gain (Btuh/person) 200 200 200 275 275 275 200 625 200 200 200 200 200 625 200 200 200 200 200 200 200 200 200 200 200 200 200 200 200 200 200 200 475

Lighting Load Density (W/sqMeter) 9.7 12.9 12.9 14.0 15.1 17.2 10.8 10.8 10.8 11.8 12.9 10.8 14.0 14.0 10.8 12.9 7.5 11.8 10.8 3.2 10.8 17.2 10.8 11.8 14.0 16.1 12.9 10.8 11.8 11.8 10.8 8.61141012 15.06

Lighting Load Density (W/SqFt) 0.90 1.20 1.20 1.30 1.40 1.60 1.00 1.00 1.00 1.10 1.20 1.00 1.30 1.30 1.00 1.20 0.70 1.10 1.00 0.30 1.00 1.60 1.00 1.10 1.30 1.50 1.20 1.00 1.10 1.10 1.00 0.80 1.40

Power Load Density (W/sqMeter) 16.14 15.06 15.06 16.14 19.37 20.44 16.14 15.06 13.99 18.29 17.22 18.29 16.14 23.67 21.52 17.22 10.76 17.22 13.99 3.23 12.91 16.14 13.99 17.22 23.67 20.44 16.14 10.76 16.14 15.06 12.91 12.91 18.29

Power Load Density (W/SqFt) 1.50 1.40 1.40 1.50 1.80 1.90 1.50 1.40 1.30 1.70 1.60 1.70 1.50 2.20 2.00 1.60 1.00 1.60 1.30 0.30 1.20 1.50 1.30 1.60 2.20 1.90 1.50 1.00 1.50 1.40 1.20 1.20 1.70

0.5 0.5 0.5 0.5 0.5 0.5 0.5 0.5 0.5 0.5 0.5 0.5 0.5 0.5 0.5 0.5 0.5 0.5 0.3 0.5 0.5 0.5 0.3 0.5 0.5 0.5 0.5 0.5 0.5 0.5 0.5 0.5 0.5

Carpet (Y/N) N Y Y N N Y Y Y N N N Y Y N Y Y Y Y Y N N Y Y N N N N Y N Y N N N

Infiltration Flow(ACH) 0.25 0.10 0.10 0.25 0.25 0.10 0.25 0.25 0.10 0.10 0.10 0.10 0.10 0.10 0.25 0.10 0.25 0.10 0.10 5.00 0.25 0.25 0.10 0.10 0.10 0.10 0.25 0.50 0.10 0.10 0.10 0.10 0.10

Infiltration (CFM/sq ft) 0.038 0.038 0.038 0.038 0.038 0.038 0.038 0.038 0.038 0.038 0.038 0.038 0.038 0.038 0.038 0.038 0.038 0.038 0.038 0.038 0.038 0.038 0.038 0.038 0.038 0.038 0.038 0.038 0.038 0.038 0.038 0.038 0.038

ConditionType Heated HeatedAndCooled HeatedAndCooled HeatedAndCooled HeatedAndCooled HeatedAndCooled HeatedAndCooled HeatedAndCooled Heated Heated HeatedAndCooled HeatedAndCooled HeatedAndCooled Heated HeatedAndCooled HeatedAndCooled HeatedAndCooled HeatedAndCooled HeatedAndCooled Vented Heated HeatedAndCooled HeatedAndCooled HeatedAndCooled HeatedAndCooled HeatedAndCooled Heated HeatedAndCooled HeatedAndCooled HeatedAndCooled HeatedAndCooled Heated HeatedAndCooled

OA L/S person N/A 8 8 15 10 10 7.5 10.5 8 13 10 9 8 8 9 9 7.5 8 10 N/A 9 9 8 8 8 7.75 8 7.5 8 8 8 6 8

OA Flow Per Area (M3/hr/M2) 27.4 3.7 3.7 3.7 3.7 3.7 3.7 3.7 3.7 3.7 3.7 3.7 3.7 3.7 3.7 3.7 3.7 3.7 3.7 27.4 3.7 3.7 3.7 3.7 3.7 3.7 3.7 3.7 3.7 3.7 3.7 0.9 3.7

Unoccupied Cooling Set Point 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82


Table 2: The 32 building types categories used in GBS and its energy related parameter setting

29

Electrical Equipment Radiant Percentage


Heat Capacity (IP Units) Btu/(ft2•°F)

Heat Capacity Metric J/(m² • °K)

139.54 155.97 184.15 301.46 455.55 495.67 477.14 512.67 669.35 108.25 108.25 73.04 73.04 101.56 101.56 227.82 23.54 33.13 48.57 156.51 602.93 602.93 602.93

4.788 4.372 3.947 4.001 3.947 22.804 22.095 22.063 21.963 3.223 3.223 2.518 2.518 2.233 2.233 1.948 1.417 1.381 1.355 0.660 24.581 24.581 24.581

0.234 0.214 0.193 0.196 0.193 1.116 1.081 1.080 1.075 0.158 0.158 0.123 0.123 0.109 0.109 0.095 0.069 0.068 0.066 0.032 1.203 1.203 1.203

unitless Solar Heat Gain Coefficient (SHGC)

Visible Transmittance (Tvis) unitless

kg/m2 Unit Density metric

28.53 31.89 37.65 61.64 93.14 101.34 97.56 104.82 136.86 22.13 22.13 14.93 14.93 20.77 20.77 46.58 4.81 6.77 9.93 32.00 123.27 123.27 123.27

lbm/ft2 Unit Density (IP Units)

4.47 3.05 1.73 1.38 0.49 2.91 2.58 1.91 0.24 5.63 5.63 3.87 3.87 2.11 2.11 0.35 5.18 3.67 2.48 0.74 2.84 1.96 1.08

SI Units => W/(m2·oC)

Mass Glazing Mass Skylight

Single Pane Clear – No coating Single Pane – Tinted Single Pane – Reflective Double Pane Clear – No coating Double Pane - Tinted Double Pane - Reflective Double Pane Clear – LowE Cold Climate, High SHGC Double Pane Clear – LowE Hot Climate, Low SHGC High Performance Double Pane Clear - High Performance, LowE, High Tvis, Low SHGC Triple Pane - Clear, LowE Hot or Cold Climate Quad Pane - Clear, LowE Hot or Cold Climate

25.4 17.3 9.8 7.81 2.81 16.55 14.65 10.85 1.35 31.99 31.99 21.99 21.99 11.99 11.99 1.99 29.41 20.83 14.08 4.2 16.14 11.14 6.14

U-Value Metric

Mass Floor Mass Floor - Slab

R-Value (IP Units) Mass Roof

Lightweight Construction – High Insulation Lightweight Construction – Typical Cold Climate Insulation Lightweight Construction – Typical Mild Climate Insulation Lightweight Construction – Low Insulation Lightweight Construction – No Insulation/Interior High Mass Construction – High Insulation High Mass Construction – Typical Cold Climate Insulation High Mass Construction – Typical Mild Climate Insulation High Mass Construction – No Insulation/Interior High Insulation - Cool Roof High Insulation - Dark Roof Typical Insulation - Cool Roof Typical Insulation - Dark Roof Low Insulation - Cool Roof Low Insulation - Dark Roof No Insulation - Dark Roof Lightweight Construction – High Insulation Lightweight Construction – Typical Insulation Lightweight Construction – Low Insulation Lightweight Construction – No Insulation/Interior High Mass Construction – Frigid Climate Slab Insulation High Mass Construction – Cold Climate Slab Insulation High Mass Construction – No Insulation

IP Units => Btu/(ft2·oF·h)

Mass Exterior Wall Mass Exterior Wall - Underground Mass Interior Wall

Conceptual Construction

U-Value

Construction Type(s)

SI Units = > R Value Metric W/(m² • °K)

IP Units => ft²-hr ºF/Btu

Table 3: Conceptual construction categories and its related energy parameter

1.09 1.11 0.89 0.56 0.57 0.42 0.35 0.30 0.29 0.22 0.12

6.18 6.32 5.06 3.17 3.24 2.40 1.96 1.68 1.63 1.26 0.66

0.81 0.71 0.28 0.69 0.61 0.19 0.67 0.44 0.27 0.47 0.45

0.880 0.610 0.130 0.780 0.550 0.100 0.720 0.700 0.643 0.640 0.620

In Vasari, users can assign different types of construction as a parameter or parameters to individual mass floors, walls, windows, roofs, and skylights in the model. Users can also assign different space types for each mass zone. Parameters defined for individual faces override the project-wide settings defined in the Energy Settings dialog. As a result, the project utilizes these individual mass surfaces and zone settings to enable varied combinations of glazing size, materials, and shading. From the building science perspective, this function is expected to result in better energy performance configurations. However, there are still some difficulties that H.D.S. Beagle 1.0 has yet to rectify regarding individual surface variations in order to operate smoothly during this phase of the research. This set of difficulties will be explored in greater detail in the technical

30


development section. Table 4 below summarizes the parameters that can be varied in each mass element. Figure 10 provides an example of several mass elements’ property setting dialog boxes. Table 4: Individual modifiable mass element energy setting parameters Mass Element

ID

Mass Exterior Wall

S1-1 S1-2 S1-3 S1-4

Modifiable Energy Parameter Target Percentage Glazing Target Sill Height Shade Depth Conceptual Construction

Type

Range/List (Unit)

Double

[0,1]

Double Double Enumeration

[0,*] (Project Length Unit) [0,*] (Project Length Unit) Lightweight Construction – High Insulation Lightweight Construction – Typical Cold Climate Insulation Lightweight Construction – Typical Mild Climate Insulation Lightweight Construction – Low Insulation Lightweight Construction – No Insulation/Interior High Mass Construction – High Insulation High Mass Construction – Typical Cold Climate Insulation High Mass Construction – Typical Mild Climate Insulation High Mass Construction – No Insulation/Interior Lightweight Construction – No Insulation/Interior High Mass Construction – No Insulation/Interior High Mass Construction – High Insulation High Mass Construction – Typical Cold Climate Insulation High Mass Construction – Typical Mild Climate Insulation High Mass Construction – No Insulation/Interior [0,1]

Mass Interior Wall

S2


Enumeration

Mass Exterior Wall Underground

S3


Enumeration

Mass Roof

S4-1

Target Percentage Skylights Conceptual Construction

Double

S4-2

Enumeration

Mass Floor

S5


Enumeration

Mass Slab

S6


Enumeration

Mass Glazing

S7


Enumeration

Mass Skylight

S8


Enumeration

31

High Insulation - Cool Roof High Insulation - Dark Roof Typical Insulation - Cool Roof Typical Insulation - Dark Roof Low Insulation - Cool Roof Low Insulation - Dark Roof No Insulation - Dark Roof Lightweight Construction – High Insulation Lightweight Construction – Typical Insulation Lightweight Construction – Low Insulation Lightweight Construction – No Insulation/Interior High Mass Construction – Frigid Climate Slab Insulation High Mass Construction – Cold Climate Slab Insulation High Mass Construction – No Insulation Single Pane Clear – No coating Single Pane – Tinted Single Pane – Reflective Double Pane Clear – No coating Double Pane - Tinted Double Pane - Reflective Double Pane Clear – LowE Cold Climate, High SHGC Double Pane Clear – LowE Hot Climate, Low SHGC High Performance Double Pane Clear - High Performance, LowE, High Tvis, Low SHGC Triple Pane - Clear, LowE Hot or Cold Climate Quad Pane - Clear, LowE Hot or Cold Climate Single Pane – Tinted Single Pane – Reflective

USC IDEA STUDIO RESEARCH | Design Optioneering Dr. David Jason Gerber, Shih-Hsin (Eve) Lin, Bei (Penny) Pan Mass Element

Mass Opening

ID

S9

Modifiable Energy Parameter

Conceptual Constructions

Type

Range/List (Unit)

Enumeration

Double Pane Clear – No coating Double Pane - Tinted Double Pane - Reflective Double Pane Clear – LowE Cold Climate, High SHGC Double Pane Clear – LowE Hot Climate, Low SHGC High Performance Double Pane Clear - High Performance, LowE, High Tvis, Low SHGC Triple Pane - Clear, LowE Hot or Cold Climate Quad Pane - Clear, LowE Hot or Cold Climate Air

* Project setting value Note: the conceptual construction’s thermal properties can refer to Table 3.

Figure 10: Mass Opening, Mass Exterior Wall and Mass Glazing individual propert y setting dialog box

Currently, H.D.S. Beagle 1.0 enables extensive user defined parameter variation. This is to ensure that H.D.S Beagle 1.0 has high range of flexibility during the prototype development period. However, the best practices utilized when operating H.D.S. Beagle 1.0 will require further exploration through future research.

32


2.2.1.3 FINANCIAL PRO FORMA PARAMETERS A simplified financial model was established in Excel for testing H.D.S. Beagle 1.0. Figure 11 illustrates the calculation methods employed and the related parameters used. The financial model and parameters used in H.D.S. Beagle can be separated into 4 portions: 1. Construction cost 2. Operation cost 3. Revenue 4. Financial For the construction cost, there are 10 items that were taken into account as part of the estimated construction cost. This utilized the information that was automatically calculated by Vasari when the energy model was formed. COST CATEGORY FINANCIAL PARAM NAME Construction Cost Land Acqusition Structrue Floor Construction Exterior Wall Construction Interior Wall Construction Glazing Construction Roof Construction Skylight Construction Circulation Cost HVAC System Cost Operation Cost Annual Electricity Cost Annual Fuel Cost Annual Operating Cost Revenue Annual Lease Payment FINANCIAL SCORE

𝑻

𝑵𝑷𝑽 = 𝒕=𝟏

FORMULA Unit Land Acqusition Cost*Lot Size Unit Structrue Cost*Gross Volume Unit Floor Construction Type Cost*Mass Floor Area Unit Exterior Wall Construction Cost*Mass Exterior Wall Area Unit Interior Wall Construction Cost*Mass Interior Wall Area Unit Glazing Type Cost*Mass Glazing Area Unit Roof Construction Cost*Mass Roof Area Unit Skylight Construction Cost*Mass Skylight Area Unit Circulation Cost*Gross Floor Area Unit HVAC System Cost*Gross Volume Electricity EUI*Electrical Cost*Gross Floor Area Fuel EUI*Fuel Cost*Gross Floor Area Unit Operation Cost*Gross Floor Area Unit Lease Payment*Gross Floor Area

NOTE Calculated Once Calculated for each mass Calculated for each mass, each surface Calculated for each mass, each surface Calculated for each mass, each surface Calculated for each mass, each surface Calculated for each mass, each surface Calculated for each mass, each surface Calculated for each mass Calculated for each mass Calculated for each mass Calculated for each mass Calculated for each mass Calculated for each mass

𝑪𝒕 − 𝑪𝟎 𝟏+𝒓 𝒕

𝒘𝒉𝒆𝒓𝒆 𝑻 = 𝑰𝒏𝒗𝒆𝒔𝒕𝒎𝒆𝒏𝒕 𝑷𝒆𝒓𝒊𝒐𝒅 𝒓 = 𝑨𝒏𝒏𝒖𝒂𝒍 𝑰𝒏𝒕𝒆𝒓𝒆𝒔𝒕 𝑹𝒂𝒕𝒆 𝑪𝟎 = 𝑪𝒐𝒏𝒔𝒕𝒓𝒖𝒄𝒕𝒊𝒐𝒏 𝑪𝒐𝒔𝒕 𝑪𝒕 = 𝑹𝒆𝒗𝒆𝒏𝒖𝒆 − 𝑶𝒑𝒆𝒓𝒂𝒕𝒊𝒐𝒏 𝑪𝒐𝒔𝒕

Note: Blue - H.D.S. Beagle 1.0 will retrieve the value that user defined in the FinancialParam worksheet. Red - H.D.S. Beagle 1.0 will retrieve from mass model (.rvt). Green - H.D.S. Beagle 1.0 will retrieve from GBS/Vasari analysis result (.gbxml). Lot Size - User input during the runing H.D.S. Beagle 1.0 process * User can insert new formula according to the format provided above.

Figure 11: H.D.S. Beagle 1.0 - financial model

The construction costs are designed to correlate with the geometric model and its conceptual construction type. Therefore, varying construction types can be assigned to individual units and be reflected in the financial model. Regarding the operation cost, aside from taking into consideration the cost estimated from each space type’s gross floor area, the annual energy consumption resulting from the GBS’s energy analysis result was also included. In terms of revenue, this estimated value is determined by the space usage and space type of the geometry in question.

33


The related financial parameters are listed in Table 5. Available as a worksheet in the Excel template, this worksheet is used by H.D.S. Beagle 1.0 to obtain the financial parameters’ values and then calculate the NPV accordingly. Please be advised that the values currently in the template are temporary values and have not yet been calibrated with accurate market values. Each project, according to the construction location, material availability and the market rate, will require individual input of accurate market values in order to assure accuracy in calculated results. As a result, these financial parameter values with require adjustment before a financial performance of each design option can be calculated. Table 5: H.D.S. Beagle 1.0 - financial related parameters FINANCIAL PARAM NAME Unit Land Acqusition Cost Unit Structrue Cost Unit Floor Construction Type Cost

RELEVANT MASS ELEMENT

OPTION

Mass Floor

Unit Exterior Wall Construction Cost

Mass Exterior Wall

Unit Interior Wall Construction Cost

Mass Interior Wall

Unit Glazing Type Cost

Mass Glazing

Unit Roof Construction Cost

Mass Roof

Unit Skylight Construction Cost

Mass Skylight

Lightweight Construction – High Insulation Lightweight Construction – Typical Insulation Lightweight Construction – Low Insulation Lightweight Construction – No Insulation High Mass Construction – Frigid Climate Slab Insulation High Mass Construction – Cold Climate Slab Insulation High Mass Construction – No Insulation Lightweight Construction – High Insulation Lightweight Construction – Typical Cold Climate Insulation Lightweight Construction – Typical Mild Climate Insulation Lightweight Construction – Low Insulation Lightweight Construction – No Insulation High Mass Construction – High Insulation High Mass Construction – Typical Cold Climate Insulation High Mass Construction – Typical Mild Climate Insulation High Mass Construction – No Insulation Lightweight Construction – No Insulation High Mass Construction – No Insulation Single Pane Clear - No Coating Single Pane - Tinted Single Pane - Reflective Double Pane Clear – No Coating Double Pane - Tinted Double Pane - Reflective Double Pane Clear – LowE Cold Climate, High SHGC Double Pane Clear – LowE Hot Climate, Low SHGC Double Pane Clear - High Performance, LowE, High Tvis, Low SHGC Triple Pane Clear - LowE Hot or Cold Climate Quad Pane Clear - LowE Hot or Cold Climate High Insulation - Cool Roof High Insulation - Dark Roof Typical Insulation - Cool Roof Typical Insulation - Dark Roof Low Insulation - Cool Roof Low Insulation - Dark Roof No Insulation - Dark Roof Single Pane Clear - No Coating Single Pane - Tinted Single Pane - Reflective Double Pane Clear – No Coating Double Pane - Tinted Double Pane - Reflective Double Pane Clear – LowE Cold Climate, High SHGC Double Pane Clear – LowE Hot Climate, Low SHGC Double Pane Clear - High Performance, LowE, High Tvis, Low SHGC Triple Pane Clear - LowE Hot or Cold Climate Quad Pane Clear - LowE Hot or Cold Climate

Unit Circulation Cost Unit HVAC System Cost

HVAC System

2-Pipe Fan Coil System, Chiller 5.96 COP, Boilers 84.5 eff 4-Pipe Fan Coil System, Chiller 5.96 COP, Boilers 84.5 eff 11 EER Packaged VAV, 84.5% boiler heating 12 SEER/0.9 AFUE Split/Packaged Gas, 5-11 Ton 12 SEER/7.7 HSPF Split Packaged Heat Pump 12 SEER/8.3 HSPF Packaged Terminal Heat Pump (PTHP) Central VAV, Electric Resistance Heat, Chiller 5.96 COP Central VAV, HW Heat, Chiller 5.96 COP, Boilers 84.5 eff Residential 14 SEER/0.9 AFUE Split/Packaged Gas NH0,SH0,NH0)-TopOfRetail)/HotelFrToFrHeight OfficeLevel#= (if(SH0>NH0,SH0,NH0)-TopOfRetail)/OfficeFrToFrHeight 8.00 minutes

99


Figure 28: Scenario 3 error - inability to form the Mass Zone.

Figure 29: Scenario 3 experiment results

100


4.4 SCENARIO 4 – STACKING BOXES Scenario 4 Description: After understanding the limitations of the geometry that could be handled by the tool, this scenario was created to have a faster run time, which allowed the research team to study the GA algorithm more efficiently. As a result, this scenario contains no curved surface. The detailed parametric design can be found in Table 17. Scenario 4 Experiment Objective: Testing our GA algorithm. Scenario 4 Summary: This scenario was developed in the last two weeks of the research residency period. Before then, most of the research team’s effort was focused on completing the automation loop, especially for the GBS automation. However, in order for the H.D.S. Beagle 1.0 to generate and breed the optimized solution space, the GA algorithm had to be implemented and checked. During the testing of this scenario, the H.D.S. Beagle 1.0 generated continuously improved results according to the algorithm. However, if there is any unpredicted factor that interrupts the process, such as the internet connection, web-service response time, or other hardware issues, the whole process needs to be restarted. As a result, the research team was unable to verify whether or not the algorithm could find the optimal solution space. Figure 30 and Figure 31 illustrate one run setting and its result. Although the current tool cannot guarantee the optimality of the solution space, within a given period of time the offspring generated did present measurable improvement in all three defined objectives.

101


Table 17: Scenario 4 parametric model design

Site Constraints

Program Requirement

Scenario 4 Lot Area = 22,685.92 sqft Max. Floor Area Ratio =6.5 Height Constraint = 180 ft Office Area Requirement=55,000sqft Hotel Area Requirement=50,000sqft Retail Area Requirement=40,000sqft Parking Area Requirement =22,680sqft

Geometry complexity

Modifiable parameters

Design parameters: 29 (Driving Parameters)

Driven Parameter: 11

Average Run time

Total Analyzed Surface Count: ~573 Name Type/Unit Range CutBoxElev_1 Length/ft [0,50] CutBoxElev_2 Length/ft [0,50] CutBoxHeight_1 Length/ft [10,50] CutBoxHeight_2 Length/ft [10,80] CutBoxSetback_1 Length/ft [10,50] CutBoxSetback_2 Length/ft [60,140] CutBoxWidth_1 Length/ft [10,35] CutBoxWidth_2 Length/ft [10,35] Depth_C Length/ft [60,90] FrToFrH_Hotel Length/ft [8,14] FrToFrH_Office Length/ft [8,14] FrToFrH_Parking Length/ft [8,10] FrToFrH_Retail Length/ft [14,20] Height_1 Length/ft [0,100] Height_2 Length/ft [0,100] Height_3 Length/ft [0,100] Height_4 Length/ft [0,100] Level#_Hotel Integer [5,13] Level#_Office Integer [5,13] Level#_Parking Integer [1,4] Level#_Retail Integer [1,2] Setback_C Length/ft [20,60] Setback_E Length/ft [0,30] Setback_N Length/ft [0,30] Setback_S1 Lengthft [5,60] Setback_S2 Length/ft [5,60] Setback_S3 Length/ft [5,60] Setback_S4 Length/ft [5,60] Setback_W Length/ft [10,30] Height_C=TopOfHotel Depth_1=80'-Setback_N Depth_2=115'-Setback_N Depth_3=148'-Setback_N Depth_4=100'-Setback_N TopOfRetail=Level#_Retail*FrToFrH_Retail TopOfOffice=TopOfRetail+Level#_Office*FrToFrH_Office TopOfHotel=TopOfOffice+Level#_Hotel*FrToFrH_Hotel ButtomOfOffice=-TopOfRetail ButtomOfParking=Level#_Parking*FrToFrH_Parking ButtomOfHotel=-TopOfOffice 3.43 minutes

102


Figure 30: Scenario 4 - Run_20110919_1213 setting

Figure 31: Scenario 4 - Run_20110919_1213 result illustration

103


4.5 SCENARIO 5 – TWISTED TOWER 1 Scenario 5 Description: Scenarios 7, 8, 9 and 12 are geometrically similar to Scenario 5 and were used to explore various components that were of interest. The detailed parametric model information of Scenario 5 can be found in Table 18. The curvature parts of scenario 5 were constructed by spline. Table 18: Scenario 5 parametric model design

Site Constraints

Program Requirement

Scenario 5 Lot Area = 22,685.91 sqft Max. Floor Area Ratio =6.5 Height Constraint = 180 ft Office Area Requirement=55,000sqft Hotel Area Requirement=50,000sqft Retail Area Requirement=40,000sqft Parking Area Requirement =22,680sqft

Geometry complexity




Average Run time

Total Analyzed Surface Count: ~10,152 Name Type/Unit Range Canyon_HalfWidth Length/ft [5,15] Corner_Curvature Number [0.1,0.4] d_Width Length/ft [0,10] FrToFrHeight_Hotel Length/ft [10,15] FrToFrHeight_Office Length/ft [10,13] FrToFrHeight_Parking Length/ft [10,10] FrToFrHeight_Retail Length/ft [10,20] Level#Hotel Integer [5,8] Level#Office Integer [5,8] Level#Parking Integer [1,4] Level#Retail Integer [1,2] Offset_E Length/ft [0,20] Offset_N Length/ft [0,20] Offset_S Length/ft [0,20] Offset_W Length/ft [0,20] RotateCenter_D1 Length/ft [90,120] RotateCenter_D2 Length/ft [50,70] Twist_Angle_Global Angle/ ° [0,90] Twist_Angle_Sub Angle/ ° [0,90] Twist_Height Length/ft [10,60] A Angle/ ° [0,0] P1_Width_W= RotateCenter_D1 P1_Width_E=176' 9 17/32"-RotateCenter_D1 P1_Width_N=84' 7 5/8"-RotateCenter_D2 P1_Width_S= RotateCenter_D2 P2_Width=178' 4 21/32"-RotateCenter_D1 P3_Width=P2_Width+0.5*d_Width P4_Width=P2_Width+d_Width TopOfRetail=FrToFrHeight_Retail*Level#Retail TopOfOffice=TopOfRetail+Level#Office*FrToFrHeight_Office TopOfHotel=TopOfOffice+Level#Hotel*FrToFrHeight_Hotel Total_Height=TopOfHotel BottomOfParking=Level#Parking*FrToFrHeight_Parking BottomOfOffice=-TopOfRetail BottomOfHotel=-TopOfOffice A1.5=Twist_Angle_Sub/2 T_mid=1/2*Corner_Curvature 92.98 minutes

104


Scenario 5 Experiment Objectives: - Scenario 5, 7, 8, 9 and 12 were intended to simulate the types of complex geometries that an actual design problem might be interested in exploring. - To explore H.D.S. Beagle 1.0’s applicability to real world design problems. Scenario 5 Summary: Scenario 5 is the first version of the twisted tower. Although Revit and Vasari were able to successfully translate the mass geometry into an energy model, the faced surface number of most of the offspring exceeded GBS’s maximum allowance. As a result, the program was unable to obtain energy analysis results for some of the offspring. Also, because of the huge number of surfaces, the energy analysis took about 1 to 1.5 hours. At this stage, the result had geometry variation but was hardly able to continue breeding the next generation. However, the variations of the geometry, as shown in Figure 32, inspired the team to seek further solutions to explore this type of design.

Figure 32: Scenario 5 variations

105


4.6 SCENARIO 6 – ORTHOGONAL BOX Scenario 6 Description: This scenario was the first scenario after the research residency period. The scenario utilized a simple orthogonal box with a rapid run time in order to verify the algorithm. The parametric model design can be found in Table 19. Table 19: Scenario 6 parametric model design

Site Constraints

Program Requirement

Scenario 6 Lot Area = 21,600 sqft Max. Floor Area Ratio =6.5 Height Constraint = 180 ft Office Area Requirement=55,000sqft Hotel Area Requirement=50,000sqft Retail Area Requirement=40,000sqft Parking Area Requirement =22,680sqft

Geometry complexity



Driven Parameter: 7

Average Run time

Total Analyzed Surface Count: ~142 Name Type/Unit Range Level#Hotel Integer [1,7] Level#Office Integer [1,5] Level#Parking Integer [1,3] Level#Retail Integer [1,2] LevelHeightHotel Length/ft [8,12] LevelHeightOffice Length/ft [8,12] LevelHeightParking Length/ft [8,10] LevelHeightRetail Length/ft [10,15] Setback Length/ft [15,30] Site_W Length/ft [180,180] Site_D Length/ft [120,120] TotalHeight=TopOfHotel TopOfRetail=Level#Retail*LevelHeightRetail TopOfOffice=TopOfRetail+Level#Office*LevelHeightOffice TopOfHotel=TopOfOffice+Level#Hotel*LevelHeightHotel BottomOfParking=Level#Parking*LevelHeightParking BottomOfOffice=-TopOfRetail BottomOfHotel=-TopOfOffice 2.06 (1.65) minutes

Scenario 6 Experiment Objectives: - After identifying limitations of the tools in use, Scenario 6 was created to verify the GA algorithm and refine H.D.S. Beagle 1.0. Scenario 6 Summary: With this simple geometry H.D.S. Beagle 1.0 could generate a maximum of 741 offspring according to the user defined GA settings, with an average speed of 1.5 minutes per result. One of the run settings and resulting illustration can be found in Figure 33 to Figure 35. Although the algorithm can continuously generate better options, some major flaws were discovered while testing this scenario. The first is that our optimal solutions converged to one point instead of forming a Pareto front curve. Secondly, the surface ID disappeared during the GA process. These two flaws will be listed as the current limitation of H.D.S. Beagle 1.0.

106


Figure 33: Scenario 6 – GBS_Run_20110930_1432 settings

Figure 34: Scenario 6 – GBS_Run_20110930_1432 result illustration I 107


Figure 35: Scenario 6 – GBS_Run_20110930_1432 result illustration II

108


4.7 SCENARIO 7 – TOWER WITH NO TWIST AND 4 SPACE TYPES Scenario 7 Description: In the interest of enabling the H.D.S. Beagle 1.0 to generate the solution space of Scenario 5, a simplified version, Scenario 7, removed the twisting parameter to determine the impact of complex geometry on H.D.S Beagle 1.0’s performance capabilities. The detailed parametric model design can be found in Table 20. Table 20: Scenario 7 parametric model design

Site Constraints

Program Requirement

Scenario 7 Lot Area = 22,689.52sqft Max. Floor Area Ratio =6.5 Height Constraint = 180 ft Office Area Requirement=55,000sqft Hotel Area Requirement=50,000sqft Retail Area Requirement=40,000sqft Parking Area Requirement =22,680sqft

Geometry complexity



Driven Parameter: 8

Average Run time

Total Analyzed Surface Count: ~3,056 Name Type/Unit Range Curvature Number [0.1,0.4] d_Width Length/ft [-10,10] GapHalfWidth Length/ft [5,15] Level#Office Integer [2,8] Level#Parking Integer [1,4] Level#Hotel Integer [5,8] Level#Retail Integer [1,2] LevelHeightOffice Length/ft [10,13] LevelHeightParking Length/ft [8,10] LevelHeightHotel Length/ft [10,15] LevelHeightRetail Length/ft [10,15] Setback Length/ft [5,20] RotateCenter_D1 Length/ft [115,115] RotateCenter_D2 Length/ft [65,65] Total_Height=TopOfOffice+Level#Hotel*LevelHeightHotel TopOfOffice=TopOfRetail+Level#Office*LevelHeightOffice TopOfRetail=Level#Retail*LevelHeightRetail BottomOfParking=Level#Parking*LevelHeightParking BottomOfOffice=-TopOfRetail BottomOfHotel=-TopOfOffice P_Width=178' 4 21/32"-RotateCenter_D1 T_mid=1/2*Curvature 39.24 minutes

Scenario 7 Experiment Objectives: - Simplify Scenario 5 in order to better understand the impact of total analyzed surfaces on run time. Scenario 7 Summary: After taking out the twisting parameter, the analyzed surface count decreased from Scenario 5’s 10,152 to Scenario 7’s 3,056. The run time also decreased from Scenario 5’s 1.5 hours to Scenario 7’s 40 minutes.

109


4.8 SCENARIO 8 – TWISTED TOWER WITH 2 SPACE TYPES Scenario 8 Description: For this scenario, the majority of the parametric model was the same as Scenario 5. However, this scenario only had two space types. That meant that while the H.D.S. Beagle 1.0 generated new geometry, it only needed to update two mass families instead of four because each space type was represented by one mass family. The parametric model design can be found in Table 21. Scenario 8 Experiment Objectives: - Explore the impact of space type number on the run time. Scenario 8 Summary: Compared to Scenario 5, decreasing the space type from 4 to 2 did shorten the require run time. However, this might not be true for all cases. (Please see the results of Scenario 7 and Scenario 9.) Table 21: Scenario 8 parametric model design

Site Constraints Program Requirement

Scenario 8 Lot Area = 22,685.92 sqft Max. Floor Area Ratio =6.5 Height Constraint = 180 ft Office Area Requirement=64,000sqft Parking Area Requirement =22,680sqft

Geometry complexity




Average Run time

Total Analyzed Surface Count: ~10,072 Name Type/Unit Range Canyon_HalfWidth Length/ft [5,15] Corner_Curvature Number [0.3,0.45] d_Width Length/ft [-10,10] FrToFrHeight_Office Length/ft [10,15] FrToFrHeight_Parking Length/ft [10,10] Level#Office Integer [10,18] Level#Parking Integer [1,4] Offset_E Length/ft [0,20] Offset_N Length/ft [0,20] Offset_S Length/ft [0,20] Offset_W Length/ft [0,20] RotateCenter_D1 Length/ft [90,120] RotateCenter_D2 Length/ft [50,70] Twist_Angle_Global Angle/ ° [0,90] Twist_Angle_Sub Angle/ ° [0,90] Twist_Height Length/ft [10,60] P1_Width_W= RotateCenter_D1 P1_Width_E=176' 9 17/32"-RotateCenter_D1 P1_Width_N=84' 7 5/8"-RotateCenter_D2 P1_Width_S= RotateCenter_D2 P2_Width=178' 4 21/32"-RotateCenter_D1 P3_Width=P2_Width+0.5*d_Width P4_Width=P2_Width+d_Width TopOfOffice=Level#Office*FrToFrHeight_Office Total_Height=TopOfOffice BottomOfParking=Level#Parking*FrToFrHeight_Parking A1.5=Twist_Angle_Sub/2 T_mid=1/2*Corner_Curvature 62.46 minutes

110


4.9 SCENARIO 9 – TOWER WITH NO TWIST AND 2 SPACE TYPES Scenario 9 Description: For this scenario, the majority of the parametric model is the same as the same as Scenario 7. However, this scenario only has two space types. The parametric model design can be found in Table 22. Scenario 9 Experiment Objectives: - This scenario is to verify the result of Scenario 8 - that is, that decreased space type number can decrease run time. Scenario 9 Summary: Theoretically and based on the run times of Scenario 5 versus Scenario 8, fewer space types should decrease the required run time. However, the previous result was not true for all cases: between Scenario9 and Scenario 7, Scenario 9 seemed to require a longer run time than Scenario 7, even though Scenario 7 had double the number of space types of Scenario 9. This result might be able to overrule the previous conclusion. However, the result of this scenario indicated that there are other unpredicted factors that impact the run time but have not been identified. Besides the runtime analysis, H.D.S. Beagle 1.0 can successfully generate new offspring using this scenario. One of the run settings and its results can be seen from Figure 36 to Figure 38. Table 22: Scenario 9 parametric model design


Scenario 9 Lot Area = 22,689.52sqft Max. Floor Area Ratio =6.5 Height Constraint = 180 ft Office Area Requirement=145,000sqft Parking Area Requirement =22,680sqft

Geometry complexity



Driven Parameter: 4 Average Run time

Total Analyzed Surface Count: ~3,056 Name Type/Unit Range Curvature Number [0.1,0.4] d_Width Length/ft [-10,10] GapHalfWidth Length/ft [5,15] Level#Office Integer [10,18] Level#Parking Integer [1,4] LevelHeightOffice Length/ft [10,13] LevelHeightParking Length/ft [8,10] Setback Length/ft [5,20] RotateCenter_D1 Length/ft [90,120] RotateCenter_D2 Length/ft [50,70] Total_Height=TopOfOffice=Level#Office*LevelHeightOffice BottomOfParking=Level#Parking*LevelHeightParking P_Width=178' 4 21/32"-RotateCenter_D1 T_mid= 1 / 2 * Curvature 80.13 (44.57) minutes

111


Figure 36: Scenario 9 – GBS_Run_20111014_0828 setting

Figure 37: Scenario 9 – GBS_Run_20111014_0828 result illustration I 112


Figure 38: Scenario 9 – GBS_Run_20111014_0828 result illustration II

113


4.10 SCENARIO 10 - OFFICE Scenario 10 Description: Scenario 10 is a more geometrically moderate case study. This only has one space type. The parametric design detail can be found in Table 23 Scenario 10 Experiment Objectives: - This scenario was used to demonstrate the feasibility of H.D.S. Beagle 1.0 in a typical real world scenario. Scenario 10 Summary: Figure 39 and Figure 40 demonstrate one of the results of Scenario 10. This scenario provides a more moderately complex geometric design scenario. This was done to demonstrate the feasibility of using H.D.S. Beagle 1.0 in a typical real world scenario such as designing a commercial office building or mixed-use building. In this case an office program was utilized in order to drive the design. For the third experiment 10 generations were populated at 4.7 minutes per offspring. Within 10 generations there was a measurable improvement over previous generations, resulting in design alternatives with the trending potential for optimization in future generations. It should be noted that for the third test case, 10 was set as the maximum generation number for yielding results; therefore, convergence of optimization for all three categories was not achieved. Table 23: Scenario 10 parametric model design


Scenario 10 Lot Area = 21,600sqft Max. Floor Area Ratio =6.5 Height Constraint = 180ft Office Area Requirement=140,400sqft

Geometry complexity



Driven Parameter:2

Average Run time

Total Analyzed Surface Count: ~480 Name Type/Unit Range H1 Length/ft [20,180] H2 Length/ft [20,180] H3 Length/ft [20,180] H4 Length/ft [20,180] LevelHeightOffice Length/ft [10,15] Level#Office Integer [10,15] Core_W Length/ft [40,60] Core_L Length/ft [40,60] H5= Level#Office * LevelHeightOffice BuildingHeight= if(H5>if(H4>if(H3>if(H1>H2,H1,H2),H3,if(H1>H2,H1,H2)),H4,if (H3>if(H1>H2,H1,H2),H3,if(H1>H2,H1,H2))),H5,if(H4>if(H3>if( H1>H2,H1,H2),H3,if(H1>H2,H1,H2)),H4,if(H3>if(H1>H2,H1,H2 ),H3,if(H1>H2,H1,H2)))) 4.74 minutes

114


Figure 39: Scenario 10 is a geometrically moderate case. The total modifiable parameter number is 6. The result shows the improvement of EUI and NPV when the generation number increases.

115


Figure 40: Scenario 10 - Run_20110919_1213 result illustration

116


4.11 SCENARIO 11 – ADSK NOVI Scenario 11 Description: Scenario 11 is another geometrically moderate case study. This is one of Autodesk’s facilities. It only has one space type. The parametric design detail can be found in Table 24. Scenario 11 Experiment Objectives: - This scenario was used to demonstrate the feasibility of H.D.S. Beagle 1.0 in a typical real world scenario. This scenario was also used to explore the feasibility of H.D.S. Beagle for existing buildings and to explore projects other than the Sunset site. Scenario 11 Summary: In order to run the project in other location, this scenario has to be run by using the Vasari version of H.D.S. Beagle 1.0. (Please refer to Section 3.2.3.3 for more detailed reasons). However, the Vasari version is not very stable. As a result, the scenario was explored in the Sunset site instead. The original intent of running the scenario was to understand the applicability of H.D.S. Beagle 1.0 to existing buildings. However, this will need more financial information and the existing energy consumption of the building to calibrate the model. This intent will be explored later after the information is obtained. Nevertheless, the potential variations of the building were still explored, as illustrated in Figure 41. Table 24: Scenario 11 parametric model design


Scenario 11 Lot Area = 76,800 sqft Max. Floor Area Ratio =1.5 Height Constraint = 70 ft Office Area Requirement=86,000sqft

Geometry complexity



Driven Parameter: 4

Average Run time

Total Analyzed Surface Count: ~212 Name Type/Unit CenterDistance Length/ft d_H Length/ft Level#Office Integer LevelHeightOffice Length/ft R Length/ft Setback_L Length/ft Setback_S Length/ft W=160'-Setback_S-Setback_L TopOfOffice= Level#Office*LevelHeightOffice TopOfCore=TopOfOffice+d_H L2=167'-Setback_L+Setback_S

3.95 (2.74)minutes

117

Range [0,40] [0,30] [1,6] [10,20] [30,60] [20,60] [20,60]


Figure 41: Scenario 11 result illustration

118


4.12 SCENARIO 12 – MODIFIED TWISTED TOWER Scenario 12 Description: Scenario 12 utilized a different modeling technique to decrease the surface count in order to measure the effect of this characteristic on H.D.S. Beagle 1.0’s performance. The parametric model design can be found in Table 25. Scenario 12 Experiment Objective: - Reduce the surface number to explore the geometry of interest. Scenario 12 Summary: With the reduced surface number H.D.S. Beagle 1.0 was able to provide a more complex geometric case study with a successfully reduced run time of up to 1.5 hours per offspring. With this modification, H.D.S. Beagle 1.0 can generate the offspring of interest. Figure 42 demonstrates the variation in geometries. Although the current version of H.D.S. Beagle 1.0 was unable to generate enough data points to realize the Pareto front optimal due to computing capabilities, it was able to generate increasingly improved solutions that were available to influence decision making within the provided timeline. Table 25: Scenario 12 parametric model design


Scenario 12 Lot Area = 22,685.92 sqft Max. Floor Area Ratio =6.5 Height Constraint = 180 ft Office Area Requirement=145,000sqft Parking Area Requirement =22,680sqft

Geometry complexity



Driven Parameter: 7

Average Run time

Total Analyzed Surface Count: ~6492 Name Type/Unit Range R1 Length/ft [5,20] R2 Length/ft [5,20] Gap Length/ft [8,13] SmoothRatio Number [0.2,0.5] TwistAngle Angle/ ° [0,90] RotateHeight Length/ft [35,60] Setback Length/ft [5,10] Level#Parking Integer [1,5] Level#Office Integer [16,18] LevelHeightParking Length/ft [8,10] LevelHeightOffice Length/ft [10,15] W=110'-2*Setback W1=75'-2*Setback W2=75'-2*Setback SmoothHeight=(TopOfBuilding-RotateHeight)*SmoothRatio HalfGap= Gap/2 TopOfBuilding=LevelHeightOffice*Level#Office BottomOfParking=LevelHeightParking*Level#Parking 49.22 minutes

119


Figure 42: Scenario 12 result illustration

120


4.13 SCENARIO 13 – LAUSD PROJECT i Scenario 13 Description: The project used for this case study was provided by the Los Angeles Unified School District, which was interested in a core and shell building that could be used for K-12 programs with approximately 25,000 to 30,000 square feet of usable program space. The intention of this design competition was to generate a flexible and efficient module structure that could be replicated and adapted to multiple sites. The design intent provided by the designer of this project expanded upon the requirements set forth by the client to achieve a net zero energy building configuration for each site using a flexible module created by the designer. The detailed parametric model information can be seen in Table 26. Table 26: Scenario 13 parametric model design


Scenario 13 Lot Area = 21,600 sqft Max. Floor Area Ratio =2 NA

Geometry complexity

Modifiable parameters Design parameters: 5 (Driving Parameters) Driven Parameter: 1

Average Run time

Total Analyzed Surface Count: ~124 Name Type/Unit Range Width Length/ft [200,220] Depth Length/ft [70,80] Orientation Angle/ ° [0,90] LevelHeightSchool Length/ft [10,18] Level#School Integer [2,4] Height = Level#School*LevelHeightSchool

0.93 (0.63)minutes

Scenario 13 Experiment Objectives: - The scenario 13 presented here was an example of a real world design problem adapted to H.D.S. Beagle 1.0 in order to demonstrate the capabilities of the tool, understand its potential to reduce design cycle latency, and support decision making and its impact on design process.

Part of this section material was published in the following paper: David Jason Gerber, Shih-Hsin Eve Lin, and Aslihan Senel Solmaz. 2012. Designing-In Performance in Early Stage Design through Parameterization, Automation, and Evolutionary Algorithms. In CAADRIA 2012 Proceeding. Chennai, India, April 25-28, 2012. i

121


Scenario 13 Summary: During the competition, the design team attempted to incorporate energy analysis results with two different approaches in order to assist with design decision making. One was an in-house analysis; the other was a collaboration with an MEP (Mechanical, Electrical, Plumbing) consultant. For the original in-house analysis approach a configuration of the adaptable module was generated for a specific site in an attempt to maximize the expected efficiency of the design. Once a design was generated, the configuration was built in Autodesk® Revit®. This configuration was then analyzed by defining the energy related parameters, such as space type, occupancy schedule, and HVAC system, in Autodesk® Revit® and exporting the model as a gbXML format energy model to Autodesk® Ecotect® and eQuest for further analysis. During this process, not all of the previously set properties in Revit were carried over in the gbXML file. As a result, the designer still needed to tune the settings in either program to conduct the analysis. Once the analysis was obtained, the design exploration method was manually altered to the original design configuration according to designer experience. The designer then had to go through the same process in order to determine any measurable difference between the designs. However, designers often had multiple new configurations that they were interested in exploring even before obtaining the first analysis result. This trial and error process was unable to provide relevant feedback in a manner timely enough to influence the schematic design phase of this project. This was in part due to interoperability issues between the softwares used. This was also partly due to the fact that even after the analysis was generated using the tools previously mentioned, it lacked the ability to isolate direct causes and effects of design changes to the expected performance of each design. During the design process an MEP engineer was employed to assist in generating a more efficient design configuration using the adaptable module previously mentioned. The intent was that the MEP engineer would be able to provide a more efficient starting point for the design and aid in providing suggestions for optimizing the design configuration’s system efficiency. However, the result was that the MEP engineer was able to provide suggestions for optimizing systems within a single design configuration but was unable to aid in the optimization of the design configuration itself. In addition, the analysis cycle for each design configuration required one week; the resulting time constraints thereby minimized the results of the analysis on the actual configuration. This was in part due to the level of detail of the analysis provided by the MEP engineer for each configuration. While the in-house analysis provided by Autodesk® Ecotect® and eQuest was a preliminary schematic analysis, the MEP engineer analysis was provided at the level necessary for generating final construction documents. Therefore, while the MEP analysis provided was more complete for each configuration, it was, like the in-house approach, also unable to provide relevant feedback in a timely enough manner to influence the schematic design phase of the project. The introduction of the H.D.S. Beagle 1.0 here was used as a test to emulate the design process and determine if a notable improvement in the efficiency feedback loop and the support of decision making could be observed. In order to utilize H.D.S Beagle 1.0 for this project the objective of the design and desired variables required explicit definition at the beginning of the process. At this point the designers defined maximized energy efficiency as the overall objective. The base geometry in this case is fixed; however, the glazing ratio, sill height of glazing, and depth of shading devices is variable for optimizing different sites. The run summaries are provided in Table 27. The Beagle ran 5 times with different site orientations of 0, 22.5, 45, 67.5 and 90 degrees. H.D.S. Beagle 1.0 successfully presented the optimal configurations for each orientation within 11 generations. The total time spent for each run was around 6 hours with 500 configurations analyses each time.

122


Table 27: Scenario 13 analysis result summary H.D.S. Beagle 1.0 Setting Design, Global Energy Setting Individual Surface Setting Exterior_Wall_0~4

Run 1 Fixed Name

Target Percentage Glazing (S1) Target Sill Height (S2) Shade Depth (S3)

Roof Analysis Results Orientation (degree) Exterior Wall_0

Target Percentage Skylight (S4) The value below is from one of the optimal configuration. 0 22.5 45 S1 = 0.290 S1 = 0.100 S1 = 0.100 S2 = 0.789 S2 = 0.000 S2 = 0.000 S3 = 0.474 S3 = 0.000 S3 = 0.000 S1 = 0.200 S1 = 0.100 S1 = 0.100 S2 = 0.000 S2 = 0.000 S2 = 0.000 S3 = 0.000 S3 = 0.000 S3 = 3.000 S1 = 0.200 S1 = 0.280 S1 = 0.820 S2 = 0.000 S2 = 1.846 S2 = 7.179 S3 = 0.000 S3 = 0.692 S3 = 2.692 S1 = 0.290 S1 = 0.860 S1 = 0.160 S2 = 0.789 S2 = 7.950 S2 = 0.615 S3 = 0.474 S3 = 2.846 S3 = 0.231 S4 = 0.000 S4 = 0.000 S4 = 0.000

Exterior Wall_1 Exterior Wall_2 Exterior Wall_3 Roof

Run 2

Run 3

Run 4

Run 5

Type/Unit

Range

Number Length/ft Length/ft

[0.2,0.8] [0,8] [0,3]

Number

[0,0.5]

67.5 S1 = 0.100 S2 = 0.000 S3 = 0.000 S1 = 0.310 S2 = 2.105 S3 = 0.789 S1 = 0.310 S2 = 2.105 S3 = 0.789 S1 = 0.100 S2 = 0.000 S3 = 0.000 S4 = 0.000

90 S1 = 0.100 S2 = 0.00 S3 = 0.00 S1 = 0.140 S2 = 0.421 S3 = 0.158 S1 = 0.100 S2 = 0.000 S3 = 0.000 S1 = 0.100 S2 = 0.000 S3 = 0.000 S4 = 0.000

Orientation: 22.5

Orientation: 0

Orientation: 45

Orientation: 90

The last scenario demonstrates our tool’s ability to reduce design cycle latency and provide energy simulation feedback, as shown in Table 28. There has also been a significant reduction in design latency. H.D.S. Beagle 1.0 allowed the designer to go from analyzing one design per day to over 800 per day. Given the exponential complexity of design problems the benefits from utilizing this type of methodology are substantial. Out of the three processes used during the case study, only H.D.S. Beagle 1.0 was able to provide relevant feedback in a manner timely enough to influence the schematic design phase of this project. Table 28: Scenario 13 energy simulation feedback process comparison Original: In-house Original: MEP consultant H.D.S. Beagle 1.0

Initial Model # 1 for each analysis 1 for each analysis 1 for all analysis

Energy Result 1 result per run 1 result per run >800 results per run

123

Feedback time 1 day per analysis 1 week per analysis 800 per 8 hours


4.14 RUN TIME SUMMARY As the geometry becomes more complex, the analysis time becomes more extended due to an increased number of surfaces that must be included and calculated. The effect of this on the experienced runtime is summarized in Table 29. Table 29: Scenarios’ run time summary Scenario 1

Scenario 2

Scenario 3

Scenario 4

Scenario 5

Scenario 6

Scenario 7

Space Type #

3

4

4

4

4

4

4

Analyzed Surface # * Driving Parameter # Driven Parameter #

216

1,515

2,641

573

10,152

142

3,056

8

20

24

29

21

11

14

4

23

24

11

16

7

8

Run Time (Minutes)

0.65

6.00

8.00

3.43

92.98

2.06 (1.65**)

39.24

Scenario 8

Scenario 9

Scenario 10

Scenario 11

Scenario 12

Scenario 13

Space Type #

2

2

1

1

2

1

Analyzed Surface # * Driving Parameter # Driven Parameter #

10,072

3,056

480

212

6,492

124

16

10

8

7

11

5

12

4

2

4

7

1

Run Time (Minutes)

62.46

80.13 (44.57**)

4.74

3.95 (2.74**)

49.22

0.93 (0.63**)

Images

Images

*The analyzed surface # refers to the surface count of the initial model. During the GA process the surface number will vary according to generated results. **The adjusted run time was excluded for selected extreme runs. During these runs, due to technical issues, an excessive runtime was experience beyond that which was necessary.

124


5 SUMMARY While H.D.S. Beagle 1.0 is still under development, this research has successfully demonstrated improvement in ameliorating the design cycle latency between the design, financing, and energy analysis domains. It does so by automating and integrating the platforms of the design, energy simulation and financial models through parameterization and algorithmic optimization. Also, H.D.S. Beagle 1.0 presents a measurable improvement over conventional design and design analysis methods through the application of a genetic algorithm for defining Pareto optimality. It provides an example of an improved solution space generation and evaluation methodology. It also provides an example of improved design optioneering in early stage design decision making. The purpose of this tool is to provide easily accessible performance analysis in a tightly coupled feedback loop with geometric and financial consideration in order to make early design decisions more EUI conscious. While there are questions of process map simplification given the complexity of translating and parameterizing the design problems necessary to run H.D.S. Beagle 1.0, which potentially require an investment of additional time by designers at the beginning of the process, improving upon this is a key target for the continuation of the research. In so doing the research seeks to further develop, test, and validate a design optioneering method that will allow students and practitioners to capture the design intent more efficiently by integrating parametric modeling with expert analysis domains, which then generates a large number of alternatives from which to choose optimality more easily. Finally, the potential of our design optioneering research to reduce latency, advance domain integration, and enable the quantifiable evaluation of more design alternatives in practice will be furthered through experimenting with high performance computing.

5.1 MAJOR ISSUES ENCOUNTERED Accuracy of the Energy Analysis: One subject of concern is the accuracy of the energy analysis for mixed-use buildings. The current system of architecture is to translate one conceptual mass in order to analyze a single energy result of one “gbXML” file. Therefore assumptions and generalizations are made during the analysis that may compromise the accuracy of the results. The possible solution to this issue is to break down the model into multiple gbXML files, which can then be analyzed separately before being combined again. This might be able to increase the accuracy of the energy analysis and also solve the surface analysis limitation while analyzing larger more complex projects. GBS Automation: Currently, the more stable version of H.D.S. Beagle 1.0 can be considered the GBS version. However, this version relies on the staging server instead of the production server. The staging server only allowed the original research team to test one project site. This limits the direct applicability of the H.D.S. Beagle 1.0 in the future. Revit API – Conceptual Mass Information: In the process of producing this body of research it was discovered that there was an error in how the Revit API was retrieving mass information from the Revit model. For example, it was discovered 125


that when confronted with an automated percentage of glazing, the perceived mass wall was calculated as having twice the presence. This meant that all subsequent calculations were inaccurate. A solution to this issue lies in an adjustment of the code. In addition, there was an inability to verify the shading area, since the components are not found in the schedules generated in the Revit environment. All such errors still require identification and subsequent adjustment of the H.D.S. Beagle code as needed.

126


5.2 CURRENT LIMITATIONS OF H.D.S. BEAGLE 1.0 Project Size & Project Complexity 1. Geometry Complexity: Excessive or extreme curvature will prevent the system from being able to automatically form the energy model and recognize zones. In response to this condition the energy model formed by the system may not be as desired. For example, the system may result in defining a roof element as an exterior wall. Secondly, the energy analysis process is limited to a built in maximum number of surfaces that can contribute to the analysis. 2. Energy Engine Limitation: The selected energy simulation engine can only analyze 8192 exterior surfaces, 8192 interior surfaces, 8192 underground surfaces, 1024 shade surfaces, 8192 openings and 4096 spaces. As a result, if the geometry exceeds any of these limits, the automation loop will be disrupted. In addition, if site shading components are taken into consideration, the surface limitation will be reached even faster due to site components being counted as part of the shade surfaces. 3. Necessary Runtime: As the geometry becomes more complex, the analysis time will become extended due to an increased number of surfaces that must be included and calculated. The effect of this on the experienced runtime is summarized in Table 29. ID Problem: 1. Missing ID: While the research team successfully identified the surface and zone by the combination of Mass Family’s Type Comment and Level Name, the surface ID will disappear during the GA process if the variation range initializes the removal of some existing elements before adding them again. For example, if the glazing area ratio is varied from 10% to 0%, then the originally assigned glazing ID will disappear. As a result, the variation range needs to be set up carefully to prevent this occurrence. 2. Complex workflow: As discussed in Section 2.3, in order to accommodate the current solution to identifying the zone, the designer is required to design the overall building configuration in one Mass Family and then separate it into parts according to different occupancy types. Designers will also need to define the project level according to the Mass Family’s type comments so that H.D.S Beagle 1.0 can recognize the family and assign space types accordingly. Furthermore, during the parameterization process, the level setting parameters need to be considered part the design process. All the above actions cannot be considered as typical for a traditional design process and varies even from previously explored parametric driven design.

127


GA Improvement: 1. GA Continuation: There are several events that will stop the GA process, such as an interruption in the internet connection, no response of web-services, or other software and hardware issues. However, the H.D.S. Beagle 1.0 research team has not had any continuation strategies implemented. As a result, once the GA process is interrupted, the process needs to be restarted from the beginning. This issue prevents current researchers from gathering enough data points to refine the GA algorithm. 2. GA Setting: Future research for H.D.S. Beagle includes the handling of parameters and optimization of the GA for architectural design problems. Currently, design problems require an extensive number of parameters to be defined and explored simultaneously in order to provide a perceived thorough exploration of design alternatives. However, the greater the number of parameters, the greater the time needed for each iteration and analysis. It is possible that there exist parameters with greater impact on the energy and financial performance of the design that could be identified and used as a means of optimizing the GA process in order to provide optimal results in a more efficient manner. In addition, the settings required for the GA to provide said optimal results are in need of further exploration.

128


REFERENCES Autodesk, Inc., 2011. Revit 2012 User’s Guide. Autodesk WikiHelp. Available at: http://wikihelp.autodesk.com/Revit/enu/2012/Help/Revit_User%27s_Guide [Accessed September 12, 2011]. Baker, J., 1987. Reducing Bias and Inefficiency in the Selection Algorithm. In Proceedings of the Second International Conference on Genetic Algorithms on Genetic algorithms and their application. Cambridge, Massachusetts, United States: L. Erlbaum Associates Inc., pp. 14-21. Available at: http://portal.acm.org/citation.cfm?id=42512.42515 [Accessed September 14, 2011]. Beyer, H.-G. & Schwefel, H.-P., 2002. Evolution Strategies – A Comprehensive Introduction. Natural Computing, 1(1), pp.3-52. City of West Hollywood, 2011. City of West Hollywood : West Hollywood Zoning Map. West Hollywood. Available at: http://www.weho.org/index.aspx?page=231 [Accessed September 7, 2011]. City of West Hollywood, 1996. The Sunset Specific Plan (Strike-Through Draft). Available at: http://www.weho.org/index.aspx?page=191 [Accessed September 7, 2011]. Coello, C.A.C., Lamont, G.B. & Veldhuizen, D.A. van, 2007. Evolutionary Algorithms for Solving MultiObjective Problems 2nd ed., Springer. Fonseca, C.M.M. da, Manuel, C. & Fonseca, M., 1995. Multiobjective Genetic Algorithms with Application to Control Engineering Problems. Available at: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.35.9685. Goldberg, D.E., 1989. Genetic Algorithms in Search, Optimization, and Machine Learning 1st ed., Addison-Wesley Professional. Maher, M.L. & Poon, J., 1996. Modeling Design Exploration as Co‐Evolution. Computer‐Aided Civil and Infrastructure Engineering, 11(3), pp.195-209. Miller, B.L. & Goldberg, D.E., 1995. Genetic Algorithms, Tournament Selection, and the Effects of Noise. COMPLEX SYSTEMS, 9, p.193--212. Rudolph, G., 1994. Convergence Analysis of Canonical Genetic Algorithms. IEEE TRANSACTIONS ON NEURAL NETWORKS, 5, p.96--101. Whitley, D., 1994. A Genetic Algorithm Tutorial. Statistics and Computing, 4. Available at: http://www.springerlink.com/content/wh268l221ml68873/ [Accessed October 4, 2011].

129


APPENDIX A APPLICATION USER MANUAL According to H.D.S. Beagle 1.0’s system architecture, the work flow can be separated into three major steps: Part 1: Prepare Model and Constraint File Part 2: Setup H.D.S. Beagle 1.0 Part 3: Execute H.D.S. Beagle 1.0 The overall work flow and steps are illustrated in Figure 19. The following manual will use the example project Sunset Glamour to illustrate step by step instructions on how to utilize H.D.S. Beagle for parametric design, energy analysis, and financial analysis. For project specific information regarding program, site constraints, etc. please refer to section 2.2.2.

Figure 43: Overall H.D.S. Beagle 1.0 workflow

130


A.1 PREPARE MODEL & CONSTRAINT FILE When setting up H.D.S. Beagle 1.0 for any project there is one thing that must be kept in mind from start to finish: one cannot work with what does not exist. In other words, one of the most critical issues when dealing with parameter driven design exploration is the thorough definition and coordination of all parameters between H.D.S. Beagle, Vasari, and Excel. If there is an interest in exploring the impact of an element through a series of parametric values, for example the height of the building, this parameter must be consistently named and defined across all platforms that are being utilized. H.D.S. Beagle cannot explore the impact on varying the height of the building if what is used to determine the height of the building is not defined in Vasari and if the range of values of interest is not defined in Excel. Therefore, careful consideration and time must be taken to lay out what elements are of interest and what parameters are necessary in each platform before proceeding. The following manual uses Sunset Glamour as an example. The first step is to create a new conceptual mass family and set the parameters that are of interest in varying the geometry. The parameters of interest for this project are Site Setbacks, Courtyard Sizing, Total Building Height, and Program Configuration. A.1.1.1 Prepare Parametric Model Define Site Boundaries 1. Open New Conceptual Mass Family

2. Select Mass Template and open 3. Click “Reference” in order to define the site boundary

131


4. Proceed to define the dimensions of the site and then lock said dimension once defined. For this example the site is defined as 120’ x 160’

132


Design Geometry Boundaries Since there is an interest in exploring the impact of different site setbacks, the setbacks must be defined as a parameter. 1. Click “Reference” and Draw a box. This box will represent the location of the building. 2. Dimension the setback between the building location and the site.

3. Under Modify Dimensions  Add Parameter

a. b. c. d. e. f. g.

Set Shared Parameter Create new file Save file Create new group label “Mass” Create new parameter label “Setback” Assign Type of Parameter to “Length” Click OK until returned to the main screen

133


4. Assign “Setback” label to all other setback dimensions

NOTE: In this example a uniform setback condition is being used. If there is an interest in providing more options then separate setback parameters must be define. For example, if the front setback of the site is different from the side setbacks then two setback parameters must be defined to allow for the different conditions.

NOTE: Shared Parameter File: This project provides a start mass family file that contains the most typical shared parameters so that users are not required to reassign them from scratch. However, all parameters can be increased and decreased according to each design scenario’s requirements.

134


Define Courtyard Size 1. Draw another Reference Rectangle inside the previous building line. This will be the outline of the courtyard space.

2. Dimension the distance between the courtyard and building boundary on all sides.

3. Under Modify Dimensions  Label Add Parameter a. Set Shared Parameter b. Create new parameter label “W” (for Building Width around the courtyard space) Assign Type of Parameter to “Length” c. Click OK until returned to the main screen 135


Create Building Form 1. Highlight Building Boundary 2. Create Form  Solid Form

Notice that when the solid form is selected the parameters available can be seen to the left on the screen.

136


3. Positive Offset is the value that will determine the total height of the building. a. Select options for Positive Offset b. Add parameter c. Set Family Parameter d. Enter name of the parameter: “TopOfBuilding” e. Click OK until returned to the main screen

4. The Negative Offset value here will determine the bottom of the building. Since this building will have an underground garage this value will determine how deep the parking garage ventures. a. Select options for Negative Offset b. Add parameter c. Set Family Parameter d. Enter name of the parameter: “BottomOfParking” 137


e. Click OK until returned to the main screen Generate courtyard geometry It is recommended at this stage to switch the view to wireframe in order to facilitate this process. To do this, select Visual Style at the bottom of the screen

Select Wireframe to change view. 1. Select courtyard boundary 2. Create Form  Solid Form TIP: The courtyard will eventually be a void form, but it is easier to set parameters and boundaries for a solid form in Revit than a void form.

a. Select options for Positive Offset b. Assign parameter label “TopOfBuilding” c. Click ok until returned to the main screen 3. The Negative Offset here should be left unassigned in order to maintain it on the ground level. In the case that there is an interest in the possibility of changing the level of the courtyard, like a 3rd story open roof garden, than a parameter setting would be needed. For this example, the courtyard remains on the ground and therefore the Negative Offset does not get a parameter assignment. 4. Change courtyard solid to void form a. Select courtyard form b. Identity Data  Solid/Void  Void

138


In order to verify the process switch the view back to Consistent Color and see if the solid is as desired. Assign Level Parameters For this project there are 4 types of programs: Parking, Office, Retail, and Hotel. For each program there is an interest in the number of levels for each category and level to level heights of each category. Since this number may vary from category to category - for example, there may be more Retail levels than Hotel levels - separate parameters must be generated. As a result, 8 separate parameters will be needed to be defined at this stage. 1. Open Family Type Properties

2. Add Number of Levels Parameters for Each Category a. Add parameter b. Set Shared Parameter c. Create new parameter label “Level#Parking” d. Assign Type of Parameter to “Integer” e. Click OK to return to Family Type Properties f. Repeat for “Level#Office,” “Level#Retail,” and “Level#Hotel”

139


3. Add Level Height Parameter for Each Category a. Add parameter b. Set Shared Parameter c. Create new parameter label “LevelHeightParking” d. Assign Type of Parameter to “Length” e. Click OK to return to Family Type Properties f. Repeat for “LevelHeightOffice,” “LevelHeightRetail,” and “LevelHeightHotel”

4. Add Building Sequence Parameter For this project there is a sequence of spaces that is desired stacked in one geometer. For example, the parking must be located at the bottom of the building, then retail, office, then hotel. These conditions, and subsequent parameters, will vary in other projects. a. b. c. d. e. f.

Add parameter Set Family Parameter Create new parameter label “TopOfParking” Assign Type of Parameter to “Length” Click OK to return to Family Type Properties Repeat for “TopOfOffice,” “TopOfRetail,” “TopOfHotel,” “BottomOfParking,” “BottomOfOffice,” “BottomOfRetail,” and “BottomOfHotel”

140


5. Set Default Values for Level Height and Level # of Each Category a. Open Family Type Properties b. Select “Level#Parking” c. Change value to 1 d. Repeat for “Level#Office,” “Level#Retail,” and “Level#Hotel” e. Select “LevelHeightParking” f. Change value to 10’-0” g. Repeat for “LevelHeightOffice,” “LevelHeightRetail,” and “LevelHeightHotel” 6. Provide formula to calculate the top and bottom of each space. a. Select “BottomOfParking” b. Under “Formula” input “Level#Parking*LevelHeightParking” c. Since the top of parking is at ground level the TopOfParking value is left blank d. Select “Bottom of Retail” e. Under “Formula” input “TopOfParking” – this will put the first level of Retail at ground level f. Select “TopOfRetail” g. Under “Formula” input “Level#Retail*LevelHeightRetail” h. Select “BottomOfOffice” i. Under “Formula” input “-TopOfRetail” 141


j. k. l. m. n. o. p. q.

Select “TopOfOffice” Under “Formula” input “TopOfRetail + Level#Office*LevelHeightOffice” Select “BottomOfHotel” Under “Formula” input “-TopOfOffice” Select “TopOfHotel” Under “Formula” input “TopOfOffice+Level#Hotel*LevelHeightHotel” Select “TopOfBuilding” Under “Formula” input “TopOfHotel”

In order to understand how Revit locates the parameter levels that have been defined here it must be noted that all calculations are with regards to the mass as a single piece. Therefore, in order to define what is considered the element of interest, such as the Office space, the calculation must be approached with regards to the massing piece as a whole. In other words, in order to define what one is interested in, one must also define what one is not interested in. For example, in order to define the volume occupied by the Office space both the top and bottom datum must be located. Intuition would imply that one could use the simple calculation of: Height of Office Space = #of Levels * Level Height

142


This calculation is mirrored in the calculation used for locating the Top of office space within the mass. However, the actual calculation appears as: Top Of Office Space = Top of Retail + #of Office Levels *Office Level Height This is necessary in order to provide a starting point from which to begin calculating the Top of the Office Space. However, this does not provide the means of calculating what is considered the Office Space itself. Instead, this must be approached with regards to the building mass as a whole. In order to define what is considered office space, the elements within the entire mass that are not Office must also be defined. Therefore, the spaces both below and above the desired Office space need to be treated as voids, or negative spaces, which are excluded from the calculation. Office Space = Building Mass – Void Volume Below Office Space – Void Volume Above Office Space This approach to the calculations used in generating the levels enables the ability to separate the levels at a later stage, which is necessary to inform H.D.S. Beagle 1.0 how to vary level.

143


Setting Up Shared Parameter Variation Ranges 1. Open the “Shared Parameter” text file that was generated throughout the previous process. 2. Open “H.D.S. Beagle 1.0 Template.xlsx” Excel file

3. Click “Geometry Param” tab

144


NOTE: The following steps are provided as a means of ensuring accuracy and providing a time saving technique for inputting the necessary information. At this stage the information needed may also be entered manually. If manual input is chosen please skip to step 9. However, if the manual procedure of entering in the necessary information is selected please note that all information is Case Sensitive and must be entered exactly.

4. Select all text as shown; copy text

5. Paste text in Excel file as shown; note that the location does not matter, just make sure the pasted text does not interfere with the template text

145


6. Select Parameter Name and Data Type information; copy cells

7. Paste cell information in corresponding columns. Paste value information only to ensure template formatting.

8. Delete unnecessary information so that only the template information remains.

146


NOTE: Review the shared parameters and confirm that all shared parameters are not driven by formula or other parameters.

9. Determine the minimum and maximum range for each parameter. Note that it is recommended that these be tested in Revit first in order to determine the desired range. NOTE: Test This project provides a start mass family file that contains most typical shared parameters so users are not required to reassign from scratch. However, all parameters can be increased and decreased according to each design scenario. Testing the maximum level number: The maximum number of surfaces that GBS can handle is 8192. If the energy model exceeds this number, the model will not be able to generate a gbXML file for analysis. 2. Setup parameter 3. Test run each parameter in the project to verify if the model can be analyzed in GBS. If not, simplify the geometry. In this step it is advised that designers test the most extreme cases Test the rotate angle Test the maximum level number

147


Separating Massing Elements According to Program

NOTE: The reason individual masses were not individually created is because: 1. All families can have the same set of parameters, even if certain parameters are useless in controlling a specific space. 2. The relationship of each space can be preserved so that when a parameter value is changed, the resulting geometries will not conflict with each other. 3. This is important when we use our program to automatically vary the level number and level to level height because we use mass family’s type comments and the level name to ID the zone. We can then assign proper space for analysis.

In this section the program elements must be separated in order to proceed. The program element to be isolated is parking. 1. Separating Parking a. Open Revit File and “Save As” Rename file to “Parking” b. Select Site Boundary  Create Form  Solid Form c. Set Positive Offset to “TopOfBuilding” d. Set Negative Offset to “0” e. Identity Data  Solid/Void  Change to Void f. Open Family Types Property Window g. Under Identity Data  Type Comments  Value input “Parking”

148


2. Save and close file 3. Open original file 4. Separate Retail a. Open Revit File and “Save As” Rename file to “Retail” b. Select Site Boundary  Create Form  Solid Form i. Set Positive Offset to “0” ii. Set Negative Offset to “BottomOfParking” iii. Identity Data  Solid/Void  Change to Void c. Select Site Boundary  Create Form  Solid Form i. Set Positive Offset to “TopOfBuilding” ii. Set Negative Offset to “BottoOfOffice” iii. Identity Data  Solid/Void  Change to Void NOTE: The volume remaining is the current definition of the Retail Space

149


d. Open Family Types Property Window e. Under Identity Data  Type Comments  Value input “Retail” 5. Save and close file 6. Open original file 7. Separate Office a. Open Revit File and click “Save As”; rename file to “Office” b. Select Site Boundary  Create Form  Solid Form i. Set Positive Offset to “TopOfRetail” ii. Set Negative Offset to “BottomOfParking” iii. Identity Data  Solid/Void  Change to Void c. Select Site Boundary  Create Form  Solid Form i. Set Positive Offset to “TopOfBuilding” ii. Set Negative Offset to “BottomOfHotel” iii. Identity Data  Solid/Void  Change to Void d. Open Family Types Property Window i. Under Identity Data  Type Comments  Value input “Office” 8. Save and close file 9. Open original file 10. Separate Hotel a. Open Revit File and click “Save As”; rename file to “Hotel” b. Select Site Boundary  Create Form  Solid Form i. Set Positive Offset to “TopOfOffice” ii. Set Negative Offset to “BottomOfParking” iii. Identity Data  Solid/Void  Change to Void c. Open Family Types Property Window i. Under Identity Data  Type Comments  Value input “Hotel” 11. Save and close file 150


Set Up Project File 1. Open Revit Architecture  Project  New 2. “Manage” Tab  Project Information Energy Analysis  Energy Settings  Edit 3. Set “Building Type” to “Office” NOTE: This selection should be set to represent the most dominant building space as the overall building type.

4. Set “Location” to Project’s Address  Enter address  Click “search”  Select weather station  Click OK

5. “Insert” Tab  Load Family  Select all Separated Program family files generated previously.

151


6. “Massing & Site”  Place Mass  Select Parking

7. Under “Placement” select “Place on Work Plane”

152


8. 9. 10. 11.

Place on work plane Switch View to South Elevation Select Parking Mass Create 4 Parking Masses with “0” offset using Array Command.

NOTE: This step is to ensure that each mass is aligned with each other.

12. 13. 14. 15.

Ungroup Array Select 1 Parking mass Change mass to “Hotel” Repeat for “Office” and “Retail”

TIP: Place one family first, then array the family in the same location. The array number is equal to the number of space type in the project. Ungroup the array, then change one parking family to office family, one parking family to hotel family, and one parking family to retail family. This way, all the families will remain related since their original form is divided from the same source.

153


NOTE: Massing elements should align perfectly at this stage.

Assign Project Levels NOTE: This step is to assign project level parameters for energy analysis. The parameters that need to be set are project location and level. Here you need to create different level names according to space type because the level is how the H.D.S. Beagle 1.0 identifies the zone and assigns the corresponding space type. When setting levels the maximum level number should be the maximum level range you want to vary. For example, if in the constrain file you set the maximum parking level number as 12, you have to create 12 levels. The naming convention is SpaceType_Level#. The program will then be able to recognize the level, adjust the level to level height, and create mass floor accordingly.

1. Rename “Level 2” to “Retail_Level1” 2. Height of Level should coordinate with default Retail Level Height value 3. “Home” Tab  Datum Level  Pick Line  Input Offset = default Retail Level Height value 4. Create Retail Levels = Maximum # of Retail Levels set in constraint file 5. Select all Retail Levels  Move to height “0” so that Retail_Level1 matches start level of Retail mass.

154


6. Select Retail Mass  Mass Floors  Associate Retail Mass with default number of floors For Example: if Level#Retail = 1 then associate Retail Mass with Retail_Level1 only

Please reference file H.D.S.Beagle1.0_ConstraintTemplate.xlxs

155


In addition to the design parameters, the Excel constraint file also contains finance related parameters and formulas. The user needs to define the level setting. Because level is not like other family parameters, we have to use API to vary the level setting according to design intent. As a result the designer needs to tell the constraint file each space type’s level setting. There are a total of seven worksheets in the constraints template file. Table 30 has the list of worksheets and each sheet’s content. Table 30: Worksheets name and description in the constraints file

Worksheet Name GeometryParam LevelSetting ProjectConstraints

Description This worksheet defines the parameter names and ranges of the modifiable parameters that relate to architectural geometry. This worksheet defines the level setting of each mass geometry. This worksheet defines the project constraints, such as FAR, height, setback, etc. The application will check the model according to the information in this worksheet.

DesignScoreParam

This worksheet defines the parameters information that will be used in the DesignFormula worksheet.

DesignFormula

This worksheet defines the calculation method of the design score. Currently, the project uses the difference between the designed space area and the required space area to rank the design.

FinancialParam

This worksheet defines the parameter information that will be used in the FinancialProForma worksheet.

FinancialProForma

This worksheet defines the calculation method of financial performance. Currently, the project uses Net Present Value (NPV) as the financial score.

A.1.1.2 Prepare Constraints File Sheet1: Geometry Parameter Worksheet (GeometryParam) This worksheet is for users to define the modifiable parameters’ names and variation ranges. The names of the parameters can be copied and pasted from the shared parameter file (.txt). While tuning the variation range, it would be better for users to test the parameter on the original mass family.

156


Sheet 2: Level Setting Worksheet (LevelSetting) This worksheet is for users to define the level setting of each mass geometry. In order allow H.D.S. Beagle 1.0 to read the setting from the constraint file but also update the geometry accordingly, the level category parameters have to be set during the parameterization process. Sheet 3: Project Constraints Worksheet (ProjectConstraints) This worksheet is for users to define the project constraint information. This setting will allow H.D.S. Beagle 1.0 to determine if the offspring is valid or not.

Sheet 4: Design Score Parameter Worksheet (DesignScoreParam)

157


This worksheet is for users to input the parameters and values that will be used to calculate the design score. These numbers will be used to calculate design score.

Sheet 5: Design Formula Worksheet (DesignFormula) This worksheet defines the design score calculation formula. Currently, the H.D.S. Beagle 1.0 can only calculate the design score in this format of formula.

Sheet 6: Financial Parameter Worksheet (FinancialParam) This worksheet is for users to input the financial calculation related parameters. Users will need to adjust the number according to the project location and materials’ unit price for H.D.S. Beagle 1.0 to present more accurate financial estimations. 158


Sheet 7: Financial Pro Forma Worksheet (FinanicalProForma) This worksheet defines the current H.D.S Beagle 1.0 financial model. H.D.S. Beagle 1.0 will read the formula from this worksheet to calculate the NPV value accordingly.

159


A.2 SET UP EXTERNAL TOOL ADD-IN Currently, the H.D.S Beagle 1.0 was developed as a Revit/Vasari Plug-in. It has not been packaged as a *.exe file. As a result, the tool needs to be set up by the following step: 1. Unzip H.D.S. Beagle 1.0 package. 2. Relocate the USCAppletGBSAPI.dll & ICSharpCode.SharpZipLib.dll file to the location where the generated data desired to be stored.

3. Edit the *.addin file. Modify the *.dll file path to the location where the .dll file was placed.

4. Place the *.addin file in the Revit/Vasari Addin folder. For Revit Architecture 2012, the Addin folder is located in the path below: C:\ProgramData\Autodesk\REVIT\Addins\2012 For Project Vasari, the Addin folder is located in the path below: C:\ProgramData\Autodesk\Vasari\Addins\TP2.1

160


5. After the previous step, the user should be able to find the plug-in in Revit’s External Tool dropdown list.

161


A.3 EXECUTE ADD-IN COMMAND: PRODUCT USER INTERFACE GUIDELINES UI 1: Design Parameter Setting UI: You will see the Initial User Defined File Loading dialog as follows (Left):

1. Click the “Browse…” button and choose the user defined Excel file to load. After you choose the correct item, you will see the dialog is updated as above (right).

NOTE: The initial fixed value is the current value from the family *.rfa file. The range is the range defined in the user defined file.

2. Edit the Lot Area in the User Defined Lot Area textbox 3. Users can modify the parameters in the following ways: a. Check/Uncheck the check box to decide whether to fix a particular parameter b. Use the slider control to decide the range/fixed value of a particular parameter c. Edit the value in the textbox to change the range/fixed value of a particular parameter d. Check/Uncheck the “Fixed All” check box to fix/unfix all parameters 4. Click one of the following button to proceed: a. “Next”: go the Energy Setting dialog b. “Cancel”: cancel the current run c. “Finish”: Save the current setting, and start the GA run 162


UI 2: Energy Setting UI: You will see the Initial Dialog as follows:

NOTE: The initial fixed energy setting is the current energy setting from the *.rvt file. The range is the same with the fixed value.

1. Users can log in to the GBS Server to select a project, If this step is skipped, the default project will be the first project in the GBS Server.

163


2. Users can modify the energy setting in the following ways: a. Check the box for a particular energy setting if you want to vary it during the population. The value for the checked settings will change between offspring. b. Uncheck a particular energy setting if you want to fix it as the default value. c. Edit the default value and varied range for each energy setting. d. Check/Uncheck the “Fixed All” check box to fix/unfix all energy settings. e. Click “Load Previous Setting” button to load the previous saved energy settings Excel file. 3. Click one of the following buttons to proceed: a. “Back”: go to the Parameter Setting UI b. “Next”: go the Surface Energy Setting dialog c. “Cancel”: cancel the current run d. “Finish”: save the current setting, and start the GA run UI3: Surface Energy Setting UI: You will see the Initial Dialog as follows:

1. Check/Uncheck the “Same with Energy Settings” box. If the checkbox is checked, go to step proceed to step 7; otherwise continue to step 2. 2. Select the Mass Instance Name. 3. Select Mass Surface Model. 4. Select Mass Face(Surface Material ID). 164


5. Users can modify the surface energy setting in the following ways: a. Check a particular energy setting if you want to vary it during the population. (The value for the checked settings will change between offspring). b. Uncheck a particular energy setting if you want to fix it as the default value. c. Edit the default value and varied range for each energy setting 6. If the settings for one combination of (Name, Model, Face) is finished, users can go back to Step 2 to conduct the surface setting for another combination. If everything is finished, go to step 7. 7.

Click one of the following buttons to proceed: a. “Back”: go to the Global Energy Setting UI b. “Next”: go the Genetic Algorithm Setting dialog c. “Cancel”: cancel the current run d. “Finish”: save the current setting, and start the GA run

UI4: Genetic Algorithm Setting You will see the Initial Dialog as follows:

165


NOTE: The recommend initial offspring is generated according to your modifiable energy setting category number. (For example, if you make HVAC System choose from 8 options, the recommend number is at least 8)

1. Users can modify the Genetic Setting in the following ways: a. Update the Initial Number Of Offspring b. Select Population Method: Random / Full Population Method c. Select Mutation Method: Random Mutation / User defined Mutation d. Edit Cross Over Ratio & Mutation Ratio e. Edit Maximum Iteration Size f. Edit the Selection Size g. Click “Load Previous Setting” button to load the previous saved GA settings Excel file 2. Click one of the following buttons to proceed: a. “Back”: go the Surface Energy Setting dialog b. “Cancel”: cancel the current run c. “Finish”: save the current setting and start the GA run

166


APPENDIX B PREVIOUS DEMO DOCUMENTATION B.1 DEMO DEVELOPMENT ROAD MAP Demo 1 (Jun 20th) • Revit API Testing • Excel Automation

Demo 2 (Jul 6th) • Energy Setting Testing • User Interface flow

Demo 3 (Jul 21)

Demo 4 (Aug 4th)

• Output documentation • Surface Energy Setting

• Green Building Studio Automation connection

Final Product • Genetic Algorithm Result Analysis

Figure 44: H.D.S. Beagle 1.0 technical development road map

Figure 44 shows the road map for the technical development of H.D.S Beagle 1.0 project. The project team considers each meeting with Autodesk Vasari Team as a milestone to demonstrate the tool development progress to them. This road map mainly shows the functionalities implemented for H.D.S Beagle 1.0 project by each milestone. Each demonstration focuses on a different functionality of H.D.S Beagle 1.0. In the early stages, the team focused on the testing of Revit API and Excel API in order to gain a better understanding of how the automation in Revit and Excel worked. This stage was very important because it built a foundation for all the functionalities that were added on top it. By the second stage, the team worked out the variation of energy settings and settled down the user interfaces for H.D.S Beagle 1.0. In the third phase, the team focused on the result output and individual surface energy setting variations. Since the Revit API still has some limitations on surface energy setting processing, this part took the team a great deal of time to figure out the workable strategy. The GBS automation related API was not available to the team until the fourth stage of the development, so the fourth demo mainly focused on testing the prereleased GBS web service API to automate the energy analysis part of H.D.S Beagle 1.0. For the final product, the team focused on testing the performance of Genetic Algorithm. While the components of GA were developed along with the other stages, they were never tested because the whole automation loop was not completed. Therefore, during the last stage the team focused on debugging the whole project according to the results of the genetic algorithm. 167


B.2 DEMO USER INTERFACE IMPROVEMENT In the road map of H.D.S Beagle, the details of the functionality for each demo are recorded in text. This section mainly focuses on the evolution of the user interface of H.D.S Beagle Project. Table 31: Demo 1 user interface description

Interface Image Dialog 1:

Interface Description In the first demo, the functionality includes loading the user-defined file, as well as populating the geometries. In dialog 1,there are three modules: 1. User-Defined Constraint File Loading 2. Project Setting Summary 3. Genetic Algorithm Population Setting In the first module, the “Browse…” button invokes the file selection and copies the selected file path. The user can also type the path in the textbox manually. The “Load” button invokes the load of the excel file and shows the result in module 2. In model 2, when the parameters are shown, the user can click the “Edit” button to invoke dialog 2 to edit the lower/upper bound of the parameters.

Dialog 2:

In model 3, the Genetic Algorithms setting is added, but most of them are not implemented by the code. If the “Apply” button is pressed, the program will starting running using all the settings in dialog 1 and 2. If “Cancel” is pressed, the program will be closed.

168


Table 32: Demo 2 user interface description

Updated Interface Images Dialog 1:

Dialog 3: Energy Setting

Interface Description As described in the road map, the user interface design is one of the focuses for Demo 2. Therefore, a lot of dialogs and interface updates were accomplished in this demo. Major Updates: 1. Separated the genetic algorithm setting into an independent dialog. Dialog 2 in Demo 1 still maintains the same functions in Demo 2, so it is not shown here. 2. Added the “User Defined Lot Area” input in Dialog 1. 3. “Back” and “Next” Buttons are added to allow users to switch between Dialogs 1, 3, and 4 4. The “Apply” button is renamed as the “Finish” button. 5. Added the energy setting interface as shown in Dialog 3. In this dialog, users can select the check box in front of each setting to decide whether to fix this setting or not. If the setting is fixed, user can edit the “Default value settings” to modify the fixed values. If the setting is varied, user can edit the varied range for the value. 6. The “Select All” checkbox allow user to fix/unfix all the energy settings. 7. In Dialog 3, when users click the “Edit…” button, different types of dialogs will pop up for different energy settings. Below are the descriptions: a. In the Varied Range column for the following energy settings: Building Type, Ground Plane, Project Phase, Export Complexity, Building Operating Schedule and HVAC System, the Range Selection Dialog will pop up to allow users to select the corresponding ranges. b. For the default value setting column for conceptual constructions, the Conceptual Construction Selection Dialog will pop up to allow users to select the conceptual constructions for each mass model.

169


Updated Interface Images Dialog 3-a: Range Selection Dialog

Interface Description c. For the Varied Range setting column for conceptual constructions, the Conceptual Construction Range Dialog will pop up to allow users to select the range of conceptual constructions for each mass model 8. Separated the genetic algorithm setting into an independent dialog. Dialog 2 in demo 1 still maintains the same functions in demo 2, so it is not shown here. 9. Added the “User Defined Lot Area” input in Dialog 1. 10. “Back” and “Next” Buttons are added to allow users to switch between Dialogs 1, 3, and 4 11. The “Apply” button is renamed as the “Finish” button. 12. Added the energy setting interface as shown in Dialog 3. In this dialog, users can select the check box in front of each setting to decide whether to fix this setting or not. If the setting is fixed, user can edit the “Default value settings” to modify the fixed values. If the setting is varied, user can edit the varied range for the value. 13. The “Select All” checkbox allow user to fix/unfix all the energy settings. 14. In Dialog 3, when users click the “Edit…” button, different types of dialogs will pop up for different energy settings. Below are the descriptions: a. In the Varied Range column for the following energy settings: Building Type, Ground Plane, Project Phase, Export Complexity, Building Operating Schedule and HVAC System, the Range Selection Dialog will pop up to allow users to select the corresponding ranges. b. For the default value setting column for conceptual constructions, the Conceptual Construction Selection Dialog will pop up to allow users to select the conceptual constructions for each mass model. c. For the Varied Range setting column for conceptual constructions, the Conceptual Construction Range Dialog will pop up to

Dialog 3-b: Conceptual Construction Selection Dialog

Dialog 3-c: Conceptual Construction Range Dialog

170


Updated Interface Images Dialog 3-d: Out Door Air Information Selection/Range Dialog

Interface Description allow users to select the range of conceptual constructions for each mass model. d. For the default value/Varied Range setting column for outdoor air information, the Outdoor Air Information Selection/Range Dialog will pop up.

Dialog 4: GA Setting

171




Dialog 3:

Interface Description In Demo 3, the major changes for the interface include the elimination of the Dialog 2 window in previous demos and the addition of the Surface Energy Setting Dialog. Major updates 1. In Dialog 1, a sliding bar with range is added for each parameter. Users can move the grey sliding bars to adjust the min/max values for the parameters or move the yellow bar in between to set the fixed values. In addition, users can also edit the textbox to set these values. The Edit & Load buttons and the dialog 2 from previous demos are eliminated. 2. In this demo, the energy setting dialog becomes the new Dialog 2. The Surface Energy Setting dialog becomes Dialog 3. 3. In the surface energy setting dialog, users can select whether the surface energy setting is consistent with project energy setting. If not, users can select the surface by providing three pieces of identity information and set its surface energy setting in the same way as in the energy setting dialog. 4. Users need to click “Save” to save the current surface energy setting.

172




Interface Description In Demo 4 and the final product, there are four user interface dialogs. Below are the descriptions of each dialog. 1. Dialog 1 has the same settings as Demo 3. 2. In Dialog 2, the login information of the GBS server is added. Users should first sign in to the GBS server and select the project on GBS server to run H.D.S. Beagle 1.0. 3. In Dialog 2, the “Load from previous setting” button is added to allow user to load previous setting Excel files to avoid having to type in the settings again. 4. Dialog 3 is similar to Demo 3. The only difference is that the “Save” button has been removed. The save action is triggered whenever users select another surface or click the next/back/finish button. 5. Dialog 4 is still for the genetic settings as in previous demos. However, more Genetic Settings have been added, such as selection size etc. 6. In Dialog 4, the “Load from previous setting” button is added to allow user to load previous setting Excel files to avoid having to type in the settings again.

Dialog 2:

173



Interface Description

Dialog 4:

174


APPENDIX C TECHNICAL FAQ C.1 ADN SUBMITTED QUESTIONS Q1. How to make Revit Talk to Excel? I am looking for some sample code that uses Revit API to externally call Microsoft Excel. Could you direct me to some sample codes or guides with that functionality? We have some samples that call Excel, like PointCurveCreation in Samples\Massing\PointCurveCreation\CS. For instance:

Q2. How do I update the type parameter value in Revit 2012? a. Refer to the Revit API Developer Manual 2012, code region 13-12. b. If you have InvalidOperation exception receiving from the LoadFamily(), it was most likely because you are altering the family document and then attempting to load it back you’re your project. According to the following Remarks from RevitAPI.chm file:

175


You need to overload IFamilyLoadOptions. Please refer to the “RFAFileProcessing” sample code for details.

Q3. How do I save family types as a *.txt file? The API does not provide the ability to export the family types as a text file in the format as it would show in the Revit user environment. As such, you can always use Revit API to parse through the symbols (types) in a given family file and then export the content to a text or excel file or any other data store. However, the text output will not be in the same format as what we see when we do a manual export using the UI.

Q4. How do I change conceptual constructions in energy settings through Revit API 2012? a. One issue that was discussed was the ConstructionSetElementId property. This interface is set to be in-house. That might just be an oversight. This variable is not related to CEA; it is the general Building Construction Type used in the detailed energy model output (gbXML and H/C Loads). The corresponding parameter is RBS_CONSTRUCTION_SET_PARAM so you can access the underlying data using the standard generic Revit parameter access. For example: Element e; ElementId id = e.get_Parameter( BuiltInParameter.RBS_CONSTRUCTION_SET_PARAM ).AsElementId();

b. However, there does not seem to be an interface for the Conceptual Constructions for the Mass Energy Model using the EnergyDataSettings class. Some of the related parameters are: · DEFAULT_CONSTRUCTION_MASS_EXTERIOR_WALL · DEFAULT_CONSTRUCTION_MASS_INTERIOR_WALL · DEFAULT_CONSTRUCTION_EXT_WALL_UNDERGROUND · DEFAULT_CONSTRUCTION_MASS_ROOF · DEFAULT_CONSTRUCTION_MASS_FLOOR · DEFAULT_CONSTRUCTION_MASS_SLAB · DEFAULT_CONSTRUCTION_MASS_GLAZING · DEFAULT_CONSTRUCTION_MASS_SKYLIGHT · DEFAULT_CONSTRUCTION_MASS_SHADE · DEFAULT_CONSTRUCTION_MASS_OPENING ADN experts have not yet been able to determine how to get to them or where they live.

c. Each MassSurfaceData and MassLevelData has a conceptual construction type that is either picked up directly from the ES dialog settings based on the type it is (e.g. exterior wall, interior wall, floor roof, glazing and so on) or is specified in the element itself via a property setting. MassZones derive their constructions from the underlying (partially) coincident MassSurfaceData and MassLevelData elements. So if the user specifies the construction per Mass*Data it will be set specifically in that element, but otherwise the various bits of code that need to know will look at in the ES dialog data for the current defaults and use those. ADN may need to develop two APIs:

176


i. ii.

One lets you specify the construction id (or alternatively set it to use the ES dialog defaults) per MassSurfaceData or MassLevelData One lets you set the defaults in the ES dialog for each different analytic surface types i.e. exterior wall, interior wall, floor roof, glazing and so on)

177


C.2 TEAM MEETING QUESTIONS Q1. How do I run Vasari API using Revit API? (Vasari Team Meeting) Just include RevitAPI.dll and RevitAPIUI.dll in the project solution. It should be able to run under Vasari if the used functionality supported by Revit is also supported in Vasari. Q2. Can Vasari support an Excel-based app? (Vasari Team Meeting) Yes. Below is a test result we performed on a Windows 7- 64 bit machine: App.

Excel lib Version

Revit 2012

Vasari 1.1

Vasari 2.0

Sample Code (Samples\Mass ing\PointCurve Creation\)

10.0.4504

Run time exception (Cannot find Office version 7.0.3300.0)

Run Successfully


14.0

Run Successfully


Run half part, run time exception (Excel lib unregistered)

10.0.4504

Run Successfully

Doesn’t run (Nothing happens)


14.0

Run Successfully

Doesn’t run (Nothing happens)


Scenario 1 (Load Excel file and update mass)

Below are more testing results on Demo 1 Code: Computer

Revit 2012

Vasari 2.0

Penny’s IDEA STUDIO Machine

Works fine

Unable to Cast exception(Figure 1)

Eve’s IDEA STUDIO Machine

Works fine

Unable to Cast exception(Figure 1)

Eve’s Laptop

Works fine

Works fine

Arjun’s Dev Machine

Works fine

Works fine

Clean machine Arjun Found

COM class exception (Figure 2)

COM class exception (Figure 2)

178


(Left) Vasari 2.0 Run Time exceptions from Penny; (Right) Revit 2012 + Vasari 2.0 Run Time exceptions from Arjun

Q3. Does Revit API 2012 have functions to Call Green Building Studio? (Vasari Team Meeting) No. It can only generate gbxml files.

Q4. How does Revit interact with GBS? (GBS Team Meeting) Input: Geometry Model (gbxml formatted file), The following is the current method that Revit interacts with Green Building Studio: Options

Revit 2012

Green Building Studio Web Service

Green Building Studio Desktop

Can be Called Manually:

Yes. Users can use Revit 2012 to call GBS Service manually.

Probably not. Didn’t find a way to manually upload a gbxml on the website.

Yes. This is a standalone Windows application. User can use it to call GBS Service manually.

Can be Called Automatically:

No. Revit API cannot Call GBS service. (Verified by ADN)

Not Sure. https://gbs.autodesk.com/gbs/s oap/Service.svc (The web service in this URL has cannot be found error, probably the research team need authorization, but no document says how to get that)

Not Sure. C# can start this app, but probably cannot run the relevant functions inside it.

179


Q5. How do you debug *.dll without restarting Vasari.exe? (Vasari Team Meeting) There are two possible solutions so far: a. Use Revit 2012 Add-in Manager. Set the transaction mode in your application as “manual” and load “*.dll” to run it. After debugging, you can directly use the Add-in Manager to generate *.AddIn file and run it in Vasari 2.0. For more details, please refer to the Add-In Manager help file. In its Revit 2012 incarnation, it is by default installed as "C:\Program Files\Autodesk\Add-In Manager for Autodesk Revit 2012\AddInManagerHelpENU.chm" b. Refer to the method mentioned in the following webpage: (Provided by Matt) http://thebuildingcoder.typepad.com/blog/2011/05/debugging-an-add-in-withoutrestarting-revit.html

180


C.3 BASIC PROGRAMMING QUESTIONS Q1. How to create Revit API .NET Class Library Project? Refer to Revit API Developer Guide 2012 Chapter 2.2.1. The pdf file can be found in the folder: C:\Program Files (x86)\Revit 2012 SDK\ Q2. How to add references in Revit API.NET Project: a. Right click “Reference”, and select “Add Reference”

b. Select .NET tab, add “Microsoft.Office.Interop.Excel ”, and click OK (as shown in the following image)

c. Open Add References again, select the “Browse” tab, and add “RevitAPI.dll” and “RevitAPIUI.dll” from the following path: “C:\Program Files\Autodesk\Revit Architecture 2012\Program\” Click “OK” to finish. d. Repeat the same process if additional libraries are required. 181


Q3. How to generate “*.dll” in Microsoft API .NET project? In the project created in Visual Studio 2010, a. Click “Build” and then “Build Solution”. Wait until the notification bar shows “build succeed”. b. Open My Computer, go to project folder where the .NET project is created. c. The generated *.dll file is in the folder ProjectHome\bin\Debug\. The “ProjectHome” path is the folder where the *.csproj file locates. NOTE: Please note, the generated *.dll file will have the same name as your project name.

Q4. How to Run “*.dll” in Revit 2012 with Add-in Manager installed? a. Install Add-In Manager from the downloaded SDK: “C:\Program Files (x86)\Revit 2012 SDK\Add-In Manager\” b. Create New Project and open “Add-In Manager” in Revit 2012

c. Load the “*.dll” file from the path we generated. d. Select the loaded “*.dll” file as shown in the following dialog and click “Run”

182


e. Check the *.dll and click “Save”; you can save the Addin file directly to the checked *.dll files. Q5. How to make a reference “Copy Local” to false? Using the “RevitAPI” reference as an example: a. Click “RevitAPI” in the reference list (as shown in the following image)

b. Under the list, please find the reference property table. (as shown in the following image)

c. Within the table, find the property named “Copy Local”, and change its value to “False” 183


Q6. Where do I find the returned result files from Green Building Studio? a. In Vasari 2.0, go to the following folder: C:\Users\USC\AppData\Local\Spoon\Sandbox\Autodesk Revit\20110514_1800\MODIFIED\@APPDATA@\Autodesk\Revit\Autodesk Project Vasari\CEA\DB\ b. In Revit 2012, go to the following folder: C:\Users\USC\AppData\Roaming\Autodesk\Revit\Autodesk Revit Architecture 2012\CEA\DB\

184


Q7. How to use RevitLookUp in the Revit Architecture 2012? a. Install Revit 2012 SDK b. Find the RevitLookUp folder under the following path : C:\Program Files (x86)\Revit 2012 SDK\ c. Open the solution & project file under RevitLookUp folder d. Generate the RevitLookUp.dll file under the opened solution in Visual Studio (Refer to Project Manual 1.5 for details) e. Change the assembly attribute in the RevitLookUp.addin file to the path of the generated RevitLookUp.dll. f.

Put the RevitLookUp.addin in the correct folder (Refer Project 1.10 for details)

g. Open Revit 2012 Applications h. Click “Add-in” then “RevitLoopUp” Please go to the word document under the following path for more instructions: C:\Program Files (x86)\Revit 2012 SDK\RevitLookUp\Documentation\ Q8. Where is the correct folder to put the Add-in files? a. For Revit 2012 in Windows 7 machine: C:\ProgramData\Autodesk\Revit\Addins\2012\ b. For Vasari 2.0 in Windows 7 machine: C:\Users\your user name\AppData\Roaming\Autodesk\Vasari\Addins\TP2.0\

185


Q9. How do I run *.dll files? Transaction Mode

In Revit 2012

In Vasari 2.0

Manual

Option 1:  Use the Add-in Manager to load the *dll file (Refer to Project Manual 1.6 )

Option 1:  In Revit 2012, use add-in Manager to store the *.dll file as an Add-in file.  Copy the stored *.addin files to the correct folder (Refer to Project Manual 1.10)

Option 2:  Use the *.addin files (same as Option 1 in Vasari 2.0) Automatic

Option 1:  Use the *.addin files (same as Option 1 in Vasari 2.0)

Option 1:  Temporally change the transaction mode to Manual  Use the *.addin files (same as Option 1 in Vasari 2.0)  Change the mode back to “Automatic”, and regenerate the *.dll file.

After the above settings, open your target software (Revit 2012 or Vasari 2.0); in the header menu list click “Add-in” then ”External Tools” to run it. Q10.How do I add web services as a project reference? Open the project solution in Visual studio 2010 and follow the steps below: a. In Solution Explorer, right-click the name of the project to “Add Service Reference.”

b. Once the Add Service Reference dialog is displayed, click “Advanced.” c. Once the Service Reference Setting dialog is displayed, click Add Web Reference. d. The “Add Web Reference” dialog box is displayed.

186


e. In the URL box, enter the URL (or the *.wsdl file path) of the Web service to use. f.

In the Web services found at this URL box, select the Web service to use.

g. Verify that your project can use the Web service and that any external code provided is trustworthy. h. In the Web reference name field, enter a name that you will use in your code to access the selected Web service. i.

Click Add Reference.

Please refer to http://msdn.microsoft.com/en-us/library/d9w023sx.aspx for more information.

187


C.4 OTHER FAQ Q1. How to get GBS valid user account (not trial account)? a. Register Autodesk Education Community using your university email address. b. Buy Revit Architecture 2011 in the Autodesk Education Community and get the activation code. c. Download and install Revit Architecture 2011, then activate it using the activation code from Autodesk Education Community. d. Register Green Building Studio using the same account in Autodesk Education Community

NOTE: By June 2011, you cannot replace “Revit Architecture 2011” in the above steps with the Revit Architecture 2012 version to get a valid user account.

Q2. How to Set Alternative staging GBS Server for Vasari? a. You need to search the sandbox folder created by Vasari for Revit.ini (I used the Everything Search tool). It is typically in the following location:

C:\Users\username\AppData\Local\Spoon\Sandbox\Autodesk Revit\Vasari Build Number\MODIFIED@PROGRAMFILESX86@\Autodesk\Revit Vasari 2012\Program\UserDataCache

b. Look for the Misc section in the Revit.ini file. (If the Misc section does not exist, create one.) You need to modify both CEAServerAddress and CEASSOServerAddress to point to the right server.

c. If you are using a GBS staging server you must also use the staging SSO server. In Configurations.xml in the program directory, replace the corresponding tags with these to use the SSO staging servers:

188


Q3. How to get/modify construction type for individual mass surface? (Refer to “conceptual construction processing” sample code for more details.) #

Step instructions

API functions

1 Enable Energy Analysis in the project

EnergyDataSettings .SetCreateAnalyticalModel(true);

2 Get the Energy Analysis Model for a selected mass

MassEnergyAnalyticalModel.GetMassEnergyAnalyticalModelIdForMas sInstance( doc, massInstance.Id );

3 Get the mass surface data for the selected mass

MassEnergyAnalyticalModel.GetReferencesToAllFaces();

4 Get surface subcategory ID (The id to distiguish “Mass floor”, “Mass wall”.....)

MassSurfaceData..CategoryIdForConceptualSurfaceType;

5 Use the ID from steps 4 to find which Built-in Category it lies in.

Compare with (int) BuiltInCategory.OST_Mass...

6 Get the conceptual construction ID for mass surface

MassSurfaceData.ConceptualConstructionId;

7 To set the conceptual construction id, we need to first make it not syncronized with the energy model

MassSurfaceData.IsConceptualConstructionByEnergyData = false

8 For each surface, based on its Built-in Category, we need to assign proper construction type. (e.g., for a surface in Mass Wall category, we need to assign ConceptualConstructionWal lType id)

e.g.,MassSurfaceData.ConceptualConstructionId = ConceptualConstructionType.GetWallConstructionType(Document, ConceptualConstructionWallType.HighMassConstructionHighInsulatio n);

189


APPENDIX D SAMPLE CODE D.1 SAMPLE CODE DESCRIPTION D.1.1 RFA FILE PROCESSING Application: RFAFileProcessing Revit Platform: All Revit Version: 2012.0 Programming Language: C# Skill Level: Easy Category: Family File Processing Type: ExternalCommand Subject: Load and write *.rfa file Summary: This sample demonstrates how to load *.rfa files, update the family type parameter and values, and how to write *.rfa files. Classes: Autodesk.Revit.DB Autodesk.Revit.UI Autodesk.Revit.DB.Structure Project Files: RFAFileProcessing.cs It contains two classes: - The class Command implements interface IExternalCommand. It is the entry of this external command. - The class MyFamilyLoadOptions implements interface IFamilyLoadOptions. It includes usage of the IFamilyLoadOptions overload of the LoadFamily() method. Description: This sample demonstrates the following functionalities: - Load the *.rfa file. - Find the first level as the host to place the family instance from the file. - Create a new family type with updated values of type parameters. - Associate the family type with the current family instance. - Store the updated family as a new rfa file. Instructions: 1. Create a new project. 2. Put the “TypeFamily.rfa” file in the same folder with the *.dll file. 3. Run this external command.

190


D.1.2 EXCEL PROCESSING Application: ExcelProcessing Revit Platform: All Revit Version: 2012.0 Programming Language: C# Skill Level: Easy Category: Excel Programming Type: ExternalCommand Subject: Read and write Excel file and update mass shapes Summary: This sample demonstrates how to store the info of shared parameters into an Excel file and load values from the Excel file to update the shape of mass instance. Classes: Autodesk.Revit.DB Autodesk.Revit.UI Microsoft.Office.Interop.Excel System.Windows.Forms System.IO Project Files: GetSharedParameterValues.cs It contains one class: - The class Command implements interface IExternalCommand. It is the entry of this external command. It contains four private functions: - SetAndOpenExternalSharedParamFile: Load shared parameter file. - LoadFromExcel: Load Excel file. - SendToNewExcel: Store the parameters into a newly created Excel file. - ConvertFeetInches2DecimalFeet: Convert the inch-feet presentation into decimal inch presentation. Description: This sample demonstrates the following functionalities: - Find the first mass in the documents. - Load the shared parameter file and display all their current values. - Create a new Excel file “DesignOpt.xslx” and store the updated shared parameter values in it. - Load the values from the created Excel file and update the shape of the mass instance. Instructions: 1. Open the “Project1.rvt” file (in Revit 2012 or Vasari 2.0) 2. Put the “Testing Share.txt” in the same folder with the *.dll file 3. Run this external command.

191


D.1.3 CONCEPTUAL ENERGY ANALYSIS Application: ConceptualAnalysisModel Revit Platform: All Revit Version: 2012.0 Programming Language: C# Skill Level: Easy Category: Conceptual Energy Analysis Type: ExternalCommand Subject: Conduct conceptual analysis and generate the corresponding gbxml file from the first mass instance. Summary: This sample demonstrates how to use Conceptual Analysis related functions and how to create/associate levels with mass instance. Classes: Autodesk.Revit.DB Autodesk.Revit.DB.Analysis Autodesk.Revit.UI Project Files: ConceptualAnalysisModel.cs It contains one class: - The class Command implements interface IExternalCommand. It is the entry of this external command. It contains one private function: - EnableEnergyAnalysis: enables the settings for the energy analysis for the mass. Description: This sample demonstrates the following functionalities: - Find the first mass in the documents. - Associate all the current levels with the mass. - Create a new level, and associate it with the mass. - Use MassEnergyAnalyticalModel to general energy model for the mass and store the model into gbxml formatted file. Instructions: 1. Open the “Project1.rvt” file (in Revit 2012 or Vasari 2.0). 2. Run this external command.

192


D.1.4 CONCETUAL CONSTRUCTION PROCESSING Application: ConceptualConstructionProcessing Revit Platform: All Revit Version: 2012.0 Programming Language: C# Skill Level: Easy Category: Conceptual Construction Processing Type: ExternalCommand Subject: Calculate the total area & update the conceptual construction type for all surfaces with the same subcategory. Summary: This sample demonstrates how to use conceptual construction type related functions and how to use the Built-in category for identification of mass surface subcategory. Classes: Autodesk.Revit.DB Autodesk.Revit.DB.Analysis Autodesk.Revit.UI Project Files: Command.cs It contains one class: - The class Command implements interface IExternalCommand. It is the entry of this external command. It contains five public functions: - GetCalculatedMassValue: Translates the Mass Surface Name to Built-in Category ID and dispatches the calculation. - GetMassArea: Calculates the total area for all mass surfaces with the same input category ID. - SetMassSurfaceConstructionType: Sets the mass surfaces with the same name with some specific conceptual construction type. - GetCategoryId: Translates the Mass Surface Name to Built-in Category ID. - GetConstructionTypeID: Returns one possible construction type that can be assigned to the mass surfaces with the input name. Description: This sample demonstrates the following functionalities: - Get the total area for all mass surfaces within one subcategory. - Modify the construction type for all mass surfaces within one subcategory. Instructions: 1. Open the “Project1.rvt” file (in Revit 2012 or Vasari 2.0). 2. Run this external command.

193


D.1.5 MASS POPULATION Application: MassPopulation Revit Platform: All Revit Version: 2012.0 Programming Language: C# Skill Level: Easy Category: Mass Processing Type: ExternalCommand Subject: Populate mass family types and store them into different project files. Summary: This sample demonstrates how to load family type parameters, update them based on a user-defined value range, and store them as project files. Classes: Autodesk.Revit.DB Autodesk.Revit.UI Autodesk.Revit.DB.Structure Project Files: MassPopulationCommand.cs It contains two classes: - The class Command implements interface IExternalCommand. It is the entry of this external command. - The class MyFamilyLoadOptions implements interface IFamilyLoadOptions. It includes usage of the IFamilyLoadOptions overload of the LoadFamily() method. ConstrainList.cs This file contains the class ConstrainList, which gets parameters from the current building model and accepts UI constraint range and options inputs. GenerationInfo.cs This file contains the class GenerationInfo, which stores the common information shared by all the offspring in the same generation. Offspring.cs This file contains the class Offspring, which stores the parameters and values and other info owned by individual offspring. ConstrainUI.cs This file contains a window form which allows users to do UI input and view population settings. Description: This sample demonstrates the following functionalities: - Load the shared parameter file and launch the UI for users to update the value range for each shared family type parameter, population size, and method. - Based on the user’s option, populate the values of family type parameters based on either a randomization method or even division method with the input size. - Update the mass instance based on each populated set of family type parameters and store each updated mass as a distinct project file. 194


Instructions: 1. Open Project “BasicScenario1.rvt” 2. Put the shared parameter file “IDEA-Studio_USC.txt” in the same folder with the *.dll file. 3. Run this external command.

195


D.2 SAMPLE CODE MANUAL The Excel Processing sample code is taken as an example to illustrate the manual. To test with *.dll file only: 1. Put the shared parameter file “Testing Share.txt” file in the same folder with the Scenario1.dll file. 2. Open Scenario1.addin and change the Assembly attribute to the path where Scenario1.dll locates. 3. Put the Scenario1.Addin file in the correct folder (Refer to Basic Programming Question Q8 for how to). 4. Open “Project1.rvt” file in Vasari 2.0 or Revit 2012. 5. Click Add-in -> External Tools -> GetSharedParameters to run the dll. To test with Microsoft Visual Studio Debugging Environment: 1. Create a Microsoft .NET class library project using the Class1.cs file. 2. Add the following references (refer to Basic Programming Questions Q2 for how to): RevitAPI (C:\Program Files\Autodesk\Revit Architecture 2012\Program\) RevitAPIUI (C:\Program Files\Autodesk\Revit Architecture 2012\Program\) Microsoft.Office.Interop.Excel (Under .NET tab) System.Windows.forms (Under .NET tab) For the “RevitAPI” and “RevitAPIUI” references, change “Copy Local” to false option (refer to Basic Programming Question Q5 for how to). 3. Build *.dll file from the Manu in Visual Studio -> Build -> Build Solution. 4. Open Scenario1.addin and change the Assembly attribute to the path where the generated *.dll locates. (Project folder -> Bin -> Debug) 5. Put the shared parameter file “Testing Share.txt” file into the same folder with the generated *.dll file. 6. Put Scenario1.Addin file in correct folder (refer to Basic Programming Question Q8 for how to). 7. Open “Project1.rvt” file in Vasari 2.0. 8. Click Add-in -> External Tools -> GetSharedParameters to run the dll. 9. Expected result: The shape of the mass is updated according to the values stored in the “DesignOpt.xlsx”. 196