WO2014144720A1 - Systeme et procede pour evaluer la consommation d'energie de multiples configurations de masse de batiment differentes - Google Patents

Systeme et procede pour evaluer la consommation d'energie de multiples configurations de masse de batiment differentes Download PDF

Info

Publication number
WO2014144720A1
WO2014144720A1 PCT/US2014/029250 US2014029250W WO2014144720A1 WO 2014144720 A1 WO2014144720 A1 WO 2014144720A1 US 2014029250 W US2014029250 W US 2014029250W WO 2014144720 A1 WO2014144720 A1 WO 2014144720A1
Authority
WO
WIPO (PCT)
Prior art keywords
building
energy use
shape
multiple different
footprint
Prior art date
Application number
PCT/US2014/029250
Other languages
English (en)
Inventor
Sungmin Kim
Deepak Aatresh
Robert Yu
Original Assignee
Aditazz, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US13/833,386 external-priority patent/US10452790B2/en
Application filed by Aditazz, Inc. filed Critical Aditazz, Inc.
Priority to CN201480028039.2A priority Critical patent/CN105210066A/zh
Priority to EP14765767.0A priority patent/EP2973077A4/fr
Publication of WO2014144720A1 publication Critical patent/WO2014144720A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00—Computer-aided design [CAD]
    • G06F30/10—Geometric CAD
    • G06F30/13—Architectural design, e.g. computer-aided architectural design [CAAD] related to design of buildings, bridges, landscapes, production plants or roads
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00—Computer-aided design [CAD]
    • G06F30/20—Design optimisation, verification or simulation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2111/00—Details relating to CAD techniques
    • G06F2111/10—Numerical modelling

Definitions

  • the invention relates generally to buildings, and, more specifically to computer-based techniques for evaluating the energy demand of different building massing options.
  • Buildings come in all different shapes and sizes and the complexity of buildings varies depending on their use. For example, from many different perspectives, a healthcare building such as a hospital is much more complex than an empty warehouse building. The complexity of a building becomes apparent when one tries to mathematically describe, model, simulate, optimize, and verify a building design such as the design of a hospital. In particular, the mathematical description, modeling, simulation, optimization, and verification are each a complex combination of three dimensional (3D) space and temporal operations. Characteristics of the 3D space include, for example, specifics of the building shell and core, the size and layout and function of the rooms, and routing of the building infrastructure.
  • Characteristics of the temporal operations include, for example, the services provided within the building, load on the building (e.g., volume of patients), and dynamic environmental conditions (e.g., internal/external temperature, light, energy cost, etc).
  • a computer based method for characterizing the energy use of multiple different building massing configurations involves specifying a set of parameters for a building massing configuration, calculating a normalized energy use index for multiple different building massing configurations that meet the specified set of parameters, wherein the normalized energy use index for each of the multiple different building massing configurations is normalized against a reference energy use index of a reference building, ranking the multiple different building massing configurations by the respective normalized energy use indexes, and selecting at least one of the different massing configurations for display on a graphical user interface according to the ranking.
  • Fig. 1 illustrates a holistic building management system that utilizes high performance and high productivity computing resources to implement a building realization platform that takes a building project from inception to building operation.
  • FIG. 2 depicts an embodiment of a high-productivity high-performance computer architecture in which a building realization platform can be implemented.
  • Fig. 3 illustrates an embodiment of a parallel hierarchical design technique that is implemented using the building realization platform.
  • Fig. 4 depicts an embodiment of a user interface of the building realization platform that includes selectable tabs for activating realization engines of the building realization platform.
  • Fig. 5 depicts an embodiment of a user interface from the business model domain of the building realization platform.
  • Fig. 6 depicts another embodiment of a user interface from the business model domain of the building realization platform.
  • Fig. 7 depicts an embodiment of a user interface from the form and shell tab in the spatial arrangement domain of the building realization platform.
  • Fig. 8 depicts an embodiment of a user interface from the block and stack tab of the spatial arrangement domain of the building realization platform.
  • Figs. 9 and 10 depict user interfaces from the room placement tab of the spatial arrangement domain of the building realization platform.
  • Fig. 11 illustrates an example of a unified data model that is used by the building realization platform.
  • Fig. 12 is a process flow diagram of a computer-based technique for generating a systems integration design from a set of customer needs.
  • Fig. 13 illustrates system elements and a corresponding process flow for generating a spatial arrangement from a business model using the building realization platform.
  • Fig. 14 illustrates an embodiment of the architecture of an embodiment of the building realization platform.
  • Fig. 15 illustrates the execution of a service that is provided by one of the realization engines.
  • Fig. 16 is a process flow diagram of a method for realizing a complex building system.
  • Fig. 17 is a process flow diagram of a method for realizing a building system within which healthcare services will be provided to patients.
  • Fig. 18 depicts a computer that includes a processor, memory, and a communications interface.
  • Figs. 19a - 19h depict nine different predefined building footprint shapes.
  • Fig. 20 depicts the footprint shape of a reference building.
  • Fig. 21 illustrates an embodiment of a process for calculating the energy use index, EUI, of the reference building.
  • Fig. 22 illustrates an embodiment of a process for generating normalized energy use indexes, nEUIs, for buildings having the footprint shape R.
  • Fig. 23 illustrates an embodiment of a process for generating normalized energy use indexes for buildings having the footprint shape L.
  • Fig. 24 illustrates an embodiment of a normalized energy use index derivation operation, which includes shape-specific nEUI databases, a normalized energy use index formula derivation engine, and shape-specific nEUI formula databases.
  • Fig. 25 illustrates an embodiment of a process for using shape-specific formulas to characterize the energy use of multiple different building massing configurations early on in the building design process.
  • Figs. 26 - 28 depict graphical user interfaces related to a technique for characterizing the energy use of multiple different building massing configurations using the massing configuration evaluator of Fig. 25.
  • Fig. 29 illustrates a process for generating building massing
  • Fig. 30 depicts a graphical user interface that graphically displays building massing configurations for a rectangle footprint shape.
  • Fig. 31 depicts a graphical user interface of entries in a building alphabet database that is generated using the shape grammar as described with reference to Fig. 29.
  • Fig. 32 depicts a graphical user interface of a search window that allows certain parameters of a search to be specified.
  • Fig. 33 illustrates the application of shape grammar to the building alphabet to form more complex building massing configurations.
  • Fig. 34 depicts a graphical user interface that graphically displays building words that are formed by combining different primitives of the building alphabet.
  • Fig. 35 depicts a graphical user interface of different building massing configurations that are formed by a combination of the building letters.
  • Fig. 36 illustrates the application of shape grammar to a set of building words to generate building sentences.
  • Fig. 37 depicts an embodiment of a system for implementing the building massing configuration generation and management techniques as described above.
  • Some characteristics that add complexity to a building system are: the system components do not necessarily have mathematically similar structures and may involve different scales in time or space; the number of components may be large, sometimes enormous; components can be connected in a variety of different ways, most often nonlinearly and/or via a network; local and system wide phenomena may depend on each other in complicated ways; the behavior of the overall system can be difficult to predict from the behavior of individual components; and the overall system behavior may evolve along qualitatively different pathways that may display great sensitivity to small perturbations at any stage. Because of the complexity of such building systems, it is difficult if not impossible to comprehensively design, model, simulate, or optimize such building systems on a PC-based computer platform in a manner that will provide significant advances beyond the conventional techniques.
  • a holistic approach to a complex building system involves using high-productivity high-performance (HP2) computing resources to manage a complex building system from building inception through to building operation.
  • HP2 computing resources are used to translate a set of customer needs to a complete virtual building design that can be used to construct a building.
  • the information generated during the design of a virtual building can be used as the basis of information that is later used to fabricate, commission, and operate a built version of the virtual building. Because HP2 computing resources are used, modeling, optimization, simulation, and verification can be performed from a single platform on a scale which heretofore has not been applied to complex building systems.
  • the holistic approach to complex building systems involves using a centralized database to manage all of the information related to a building system.
  • the centralized database concept is in contrast to the conventional approach where each different discipline (e.g., architects, structural engineers, electrical engineers, etc.) maintains its own proprietary database of discipline-specific information.
  • Fig. 1 illustrates a holistic building management system 100 that utilizes HP2 computing resources to implement a Building Realization Platform (BRP) 102 that takes a building project from inception (e.g., customer needs) to building operation.
  • BRP Building Realization Platform
  • the BRP is a central hub of building information that can be maintained from the initial specification of customer needs through building operation.
  • the BRP includes realization engines 104 and a building database 106.
  • the realization engines include the logic to drive the design, modeling, simulation, optimization, and verification operations related to a building system and the building database includes stored data related to the building system (virtual and/or real) that is designed, modeled, simulated, optimized, and verified by the realization engine.
  • the BRP 102 supports a series of hierarchical domains that run in a process flow from more abstract to less abstract.
  • the hierarchical domains shown in Fig. 1 are, from more abstract to less abstract, customer needs 110, business model 112, spatial arrangement 114, systems integration 116, fabrication 118, assembly 120, commissioning 122, and operation 124.
  • each of the domains is dependent on the data associated with the previous domains.
  • Fig. 1 also illustrates a temporal relationship between the different domains in that certain details of a preceding domain must be specified before the process can move to the next domain. Additionally, the dependencies between domains are tracked to correspond to the requirements of the previous domain.
  • the customer needs 110 domain relates to the desired building system from an owner perspective, that is, what is the use of the building system (e.g., healthcare, hospitality, etc.), where the building system will be located, and what are the metrics and their importance to rate the quality of the design.
  • the business model domain 112 relates to the types and volumes of services that will be provided to satisfy the customer needs.
  • the business model may also support behavioral modeling of the building system, and functional and space programs of the building system.
  • the spatial arrangement domain 114 relates to the building system as a set of building structures implementing a desired architectural parti, with relative placed rooms.
  • the systems integration domain 1 16 relates to a fully detailed facility including defined 3D spaces and building infrastructure from which detailed construction documents can be derived.
  • the fabrication domain 118 relates to how and how many basic elements (i.e., building blocks) need to be fabricated to construct the building system (e.g., a list of building components).
  • the assembly domain 120 relates to how and in which order the basic elements need to be assembled to construct the building system.
  • the commissioning domain 122 relates to the physical building system and its behavior. The commissioning domain may contain information that is similar to the information held in the systems integration domain but also accounts for deviations that might have occurred during the fabrication and assembly of the building system.
  • the operation domain 124 relates to the building system while in operation. In the operation domain, a virtual model of the building system can be used in real time to optimize processes such as room, staff, and patient scheduling, and to evaluate and adapt to unscheduled events.
  • each complex building system is designed, modeled, simulated, optimized, and verified from building inception using a pre-defined set of physical building components.
  • the pre-defined set of physical building components may include, for example, structural components, deck components, and wall components.
  • Each of the pre-defined physical building components has a set of known characteristics (e.g., dimensions, materials of construction, structural performance, thermal performance) that can be utilized in the various domains of the BPvP to produce more rapid and accurate results.
  • the use of pre-defined physical building components allows for the development and reuse of mathematical models that enable design, modeling, simulation, optimization, and validation of complex building systems.
  • the pre-defined set of physical building components can be taken into consideration early on in the building design process, for example, within the business model domain, the spatial arrangement domain, and the systems integration domain.
  • Performing the processes described with reference to the BRP 102 requires computing resources well beyond what can be provided by typical PC-based computer systems.
  • the BRP utilizes HP2 computing resources throughout the life cycle of a complex building system.
  • Fig. 2 depicts an embodiment of an HP2 computer architecture 140 in which the BRP can be implemented.
  • the HP2 computer architecture includes a high capacity networked storage system 142, a large scale processing system 144, and user interface devices 146, e.g., client machines.
  • load balancers 148 and flow servers 150 may be provisioned from the large-scale processing system.
  • the user interface devices 146 may be client machines, typically desktop computers, laptop computers, or tablet computers, on which a session can be opened to control the design flow and to view the performance results of a particular building system design.
  • the user interface devices allow a user to provide design intent and invoke design and analysis steps. Results come in to the user interface devices as they become available.
  • the user interface devices are used to access a browser-based user interface of the BRP 102 via an access network 152.
  • the high capacity networked storage system 142 includes memory for storing the software code that is used to implement the realization engine and for storing data related to multiple different complex building systems that are managed using the BRP.
  • the high-capacity network storage system includes a networked combination of storage servers 154 that provide storage capacity on the order of Terabits of data.
  • the computer architecture depicted in Fig. 2 includes a central repository for data that spans multiple different disciplines related to a complex building system.
  • the data for a specific building may include data related to the customer needs, the business model, spatial arrangement, systems integration, fabrication, assembly, commissioning, and operation. This may include information that crosses many of the disciplines that are conventionally involved in the life cycle of a building.
  • the large-capacity storage system 142 includes one or more storage servers that store the building database 106 information and one or more servers that store the computer instructions to implement the realization engines 104.
  • the database servers 154 store design information organized as follows: a construction data base, an analysis database, a library of process knowledge, and a library of design rules.
  • the construction database may contain various system descriptions that are independent from how the systems were constructed.
  • the analysis database may contain performance and quality results, obtained through various analyses and simulations of the systems contained in the construction database.
  • the library of process knowledge may contain information related to processes, people patterns, department patterns, building patterns, and mechanical, electrical, and plumbing (MEP) routing patterns.
  • the library of design rules may contain building codes, such as egress, fire and accessibility requirements, and industry best practices (note that there can be different sets of design rules stored to comply with local variations of building rules).
  • the large-scale processing system 144 performs the computer processing that is necessary to implement the BRP.
  • the large-scale processing system performs high- volume mathematical computations to implement the design, modeling, simulation, optimization, and verification of the BRP.
  • the large scale processing system includes multiple servers 158 (i.e., a server farm or compute farm) that each have many high-speed processors (e.g., on the order of thousands and up), where the individual servers are connected to each other by high-speed network links such as Gigabit Ethernet.
  • servers 158 i.e., a server farm or compute farm
  • high-speed processors e.g., on the order of thousands and up
  • TFlops Tera- (10 ) to Peta- (10 ) floating point operations per second (Flops), referred to as TFlops and PFlops, respectively.
  • the flow servers 150 which can be virtual, one per user interface device 146 and design, may be compute engines borrowed from the large scale processing system 144 (e.g., server farm), which execute the instructions that implement the BRP design flow.
  • the flow servers hold the design state of each unique design. That is, the flow servers know the phase of the design cycle for a particular design. Typically, the flow servers hold just enough of the design in memory to allow efficient transfer of design intent, results, and job submission. For
  • the flow servers submit processing jobs (i.e., computational tasks) to the load balancer 148 and the load balancer distributes the computational tasks based on project, user, and task priorities.
  • processing jobs i.e., computational tasks
  • Compute servers 158 of the large-scale processing system 144 are used by the flow servers 150 to perform computational intensive tasks using, for example, map reduced or "MapReduce” techniques for parallel processing.
  • the compute servers are pooled among flow servers by the load balancer 148.
  • the compute servers can pull large amounts of design information directly from the database servers 154 of the high capacity network storage system 142 and save raw results back to the storage system.
  • some or all of the computing resources are provided as a "cloud service.”
  • the HP2 computing resources of Fig. 2 are provided as a cloud service within a network cloud 160. That is, the computing resources are not owned by the owner or user of the BRP, but are instead utilized and paid for by the owner or user of the BRP on an as needed basis.
  • cloud services such as those provided by Amazon Web Services (AWS) may be utilized to implement the BRP 102.
  • AWS Amazon Web Services
  • the HP2 computing architecture 140 depicted in Fig. 2 differs from conventional industry practices in many ways.
  • the functions of control and presentation are isolated in thin client user interface devices 146, while all compute tasks are performed in a well controlled and high performance cloud service containing both the compute and database servers.
  • the compute machines are not allocated per type of task or discipline (architects, construction engineer, mechanical engineer, operations analyst), but are pooled to serve as flow servers and compute engines. This centralized approach optimizes efficiency in that the flow servers are drawn out of the compute pool as a design session starts and the flow servers coordinate all tasks for that design session.
  • the database servers are not organized per discipline, that is, they are not organized separately for each discipline, e.g., one database server each for the architect, the construction engineer, the mechanical engineer, and the operations analyst.
  • high bandwidth/high volume data transactions occur only between the database servers 154 and the compute servers 158.
  • Fig. 3 illustrates an embodiment of a parallel hierarchical design technique that starts at the customer needs, e.g., building inception, and runs through to a multitude of fully defined systems integrations.
  • HP2 computing resources many different options can be realized and vetted in parallel within each domain from business modeling, to spatial arrangement, to systems integration.
  • instance-specific data can be stored and maintained for use in subsequent design analysis and/or modification.
  • a database of customer needs 170 is used to generate a set of different business models, business models databases 172.
  • the database of each different business model is used to generate a set of spatial arrangements, which are stored as spatial arrangement databases 174.
  • the database of each different spatial arrangement is used to generate a set of systems integration designs, which are stored as systems integration design databases 176.
  • Fig. 4 depicts an embodiment of a user interface of the BRP 102 that includes selectable tabs or icons 180 for activating operations in the customer needs domain 110, the business model domain 112, the spatial arrangement domain 114, the systems integration domain 116, and the fabrication domain 118 of the BRP.
  • customer needs are specified.
  • customer needs are presented in a web-based user interface at a client device as a formal description of customer needs.
  • the formal description of customer needs is a formal description of information, as known in computer science, which correctly, precisely, and unambiguously represents certain concepts so that the customer needs can be acted upon.
  • customer needs are input to the BRP 102 via a client device by an entity that is looking to build a building for a particular use, such as a healthcare facility.
  • the entity or "customer" may specify that it wants to provide enough acute healthcare services to residents within a specific ZIP code to meet anticipated demand.
  • customer needs may reflect a project location, service objectives, business objectives, and/or a prioritization of customer needs.
  • the customer needs may specify the types of services that will be provided in the building, the volume of services that will be provided in the building, capital investment limitations, return on investment (ROI) requirements, and/or metrics to rate the quality of various design alternatives.
  • ROI return on investment
  • customer needs related to a healthcare building system include a desired location for the building system, a model of care for the building system, and values of the customer.
  • the user interface may allow the user to rate, on a sliding scale, how the user values concepts such as innovation, sustainability, life cycle cost, healthcare improvement, efficiency, and flexibility.
  • the customer needs domain can provide the user with outputs such as a map of the desired building system location, census data for the desired location, and public health information, such as Centers for Disease Control (CDC) information.
  • the map may include pointers or "pins" that identify related facilities, e.g., other healthcare facilities, doctors, labs, etc., which are located in the vicinity of the desired location.
  • the information related to the customer needs can then be stored in the customer needs database 170 of the BRP 102.
  • the project is given a name and the project information including the location, model of care, value ratings, map information, census information, and CDC information is all stored in the BRP's database under the project name.
  • Different projects can be established with different project names and any of the user specific criteria in the customer needs domain can be changed.
  • a business model defines the "program" of the building needed to meet the specified customer needs.
  • the business model specifies what types of services will be provided in the building and at what volume the services will be provided.
  • the business model may also specify an initial shell of the building. Therefore, the business model may include both space dimensions and time dimensions.
  • the generation of business models includes a computationally intensive process of design, simulation, optimization, and validation that is able to generate and evaluate a large number of different designs in parallel. For example, it is possible to design, simulate, optimize, and validate on the order of hundreds to thousands of different iterations related to the business models in tens of minutes (e.g., less than one hour) from a single set of customer needs.
  • one computationally intensive operation performed in the business model domain 112 involves behavioral simulation to determine the types and volumes of services that should be provided by a particular building.
  • Behavioral simulations are well suited for the study of the processes that underlie formulation and implementation of a business model. For example, behavioral simulations may involve measuring variables at multiple levels, controlling or measuring the context, dealing with historical facts, capturing process differences across issues, and linking processes to outcomes. The behavioral simulations performed in the business model domain are logically linked to the resulting design, construction, and operation of the building.
  • the BRP 102 tracks dependencies back to the customer needs so that there is a direct relationship between the customer needs and the business models that are generated to meet the customer needs.
  • a change in the customer needs can be propagated to the business model domain and changes can be made to the business model as needed to meet customer needs.
  • already generated business models can be evaluated in light of changes to the customer needs.
  • each instance of each different business model is uniquely stored in the database so that each instance can be independently accessed and modified. Unique storage of each instance of a business model allows individual business models to be accessed, evaluated, and/or modified without affecting other business models that correspond to the same set of customer needs.
  • the business model identifies the service lines (e.g., emergency care, well care, imaging, laboratory) and/or departments that are to be provided by the building system, the patient load on the building system, and the room and staff needs (e.g., the number and types of rooms and the number and types of staff ).
  • the outputs of the business model can be provided to a user via a user interface of the BRP 102.
  • Fig. 5 depicts an embodiment of a user interface from the business model domain 112 of the BRP 102.
  • the user interface displays information about the business model such as number of medical doctors (MDs), number of medical assistants (MAs), number of registered nurses (RNs), number of triage areas, number of trauma rooms, number of acute-care exam rooms, number of exam rooms, number of observation beds, number of imaging rooms, number of surgery rooms, and number of beds.
  • MDs number of medical doctors
  • MAs medical assistants
  • RNs number of registered nurses
  • the behavior of the building system can be simulated based on the criteria of the building model and various workflow logic that is incorporated into the BRP.
  • the user interface of the BRP also enables certain parameters of the business model to be modified for use in simulation. For example, the user interface enables the user to adjust parameters related to any of the business models, such as the number of acute-care exam rooms, the number of exam rooms, the number of observation rooms, the number of trauma rooms, the number of medical doctors, and the number of registered
  • Fig. 6 depicts an embodiment of a user interface from the business model domain 112 that shows simulation results generated within the business model domain. For example, the results relate to the length of stay of patients given a certain set of input parameters.
  • event driven simulations are implemented and the different simulations are set up to use specific HP2 computing resources. For example, each computational operation is mapped to a specific set of processing hardware in the large-scale processing system using MapReduce techniques.
  • the parallel hierarchical process can move to the spatial arrangement domain, where business models are used as input and multiple different spatial arrangements are provided as an output.
  • at least three different spatial arrangements are generated for each business model.
  • spatial arrangements SA11, SA12, and SA13 are generated from BM1
  • spatial arrangements SA21, SA22, and SA23 are generated from BM2
  • spatial arrangements SA31, SA32, and SA33 are generated from BM3.
  • three different spatial arrangements are generated from each business module, it should be understood that many more different spatial arrangements could be generated from the same set of business models.
  • a spatial arrangement defines a building system as a 3D space that includes the basic structure of the building and the placement of rooms.
  • the spatial arrangement defines the approximate square footage of the building, the number of floors in the building, and the number, types, locations, square footage, and functionality of the rooms within the building.
  • the spatial arrangements are generated in parallel using the computational resources of the large scale processing system.
  • the computing resources of the large scale processing system are used to design, model, simulate, optimize, and verify the different spatial arrangements.
  • processing in the spatial arrangement domain 114 involves the computer assisted placement of departments and/or rooms based on adjacency criteria and behavioral simulation performance.
  • many different spatial arrangements can be modeled, simulated, optimized, and verified in a relatively short period of time.
  • an energy efficiency simulation of the building system may involve one thousand separate computational tasks or jobs that each require one hour to complete.
  • HP2 computing resources the one thousand separate computational tasks can be processed in parallel by separate processors (e.g., separate physical hardware devices), reducing the time required to complete the entire task by roughly one thousand fold.
  • the BRP 102 tracks dependencies back to the corresponding business models so that there is a direct relationship between the spatial arrangements, the building models, and ultimately the customer needs.
  • a change in the customer needs or business model domains can be propagated to the spatial arrangement domain and changes can be made to the spatial arrangements as necessary.
  • each instance of each different spatial arrangement can be uniquely stored in the database so that each instance can be independently accessed and manipulated. Because the business models and spatial arrangements are maintained in hierarchical order, only changes that affect a particular hierarchical chain need to be propagated to the spatial arrangements.
  • the change can be propagated to the spatial arrangements, SA11, SA12, and SA13 only, while the spatial arrangements that are linked to BM2 and BM3 (e.g., SA21, SA22, SA23, and SA31, SA32, SA33, respectively) are not affected.
  • a spatial arrangement specifies aspects of the building system related to "form and shell,” “block and stack,” and "room
  • the form and shell within the spatial arrangement domain 114 specifies parameters such as the shape (e.g., architectural pattern or architectural parti) and dimensions of the building system.
  • the form and shell may also specify the orientation and location of the building on the site specified in the customer needs.
  • various models, simulations, and/or optimizations can be performed using the HP2 computing resources.
  • energy efficiency simulations and optimization operations can be performed on a scale that heretofore has not been possible.
  • Fig. 7 depicts an embodiment of a user interface from the form and shell tab in the spatial arrangement domain that shows adjustable parameters of an energy efficiency simulation that is implemented at the form and shell level. Adjustable parameters for the simulation include the time of year (e.g., month), the orientation of the building, and glazing-to-opacity ratios in different directions, e.g., east, west, north, south.
  • block and stack within the spatial arrangement domain 114 specifies how departmental blocks and circulation elements are placed within the specified form and shell of the building system.
  • the block and stack defines how departmental blocks are configured relative to each other in the horizontal direction and how departmental blocks are configured, or "stacked," relative to each other in the vertical direction (e.g., between different floors of a multistory building).
  • various models, simulations, and/or optimizations can be performed using the HP2 computing resources.
  • operations may include interactive departmental distance exploration, behavioral simulation with department distances, and generation of individual departmental blocks.
  • Fig. 8 depicts an embodiment of a user interface from the block and stack tab of the spatial arrangement domain that shows the output of a simulation to determine travel distances and times between certain departments given a particular block and stack.
  • room placement within the spatial arrangement domain 114 specifies the locations of specific rooms within a building system having a specific block and stack arrangement. From the specified room placement, various models, simulations, and/or optimizations can be performed using the HP2 computing resources. For example, operations may include interactive room distance
  • Figs. 9 and 10 depict user interfaces from the room placement tab of the spatial arrangement domain.
  • Fig. 9 depicts certain adjustable criteria for room placement
  • Fig. 10 depicts different room placement designs that are generated based on a given set of criteria.
  • a systems integration design defines the 3D spaces of a building and the infrastructure of the building.
  • the systems integration design for a building defines the locations in three dimensions (i.e., "3D spaces) of the infrastructure elements of the building system.
  • the building infrastructure specified in the systems integration design may include, for example, the location and specifications of mechanical, electrical, and plumbing (MEP) systems, information technology (IT), safety and security elements, and lighting.
  • the locations of the building may include, for example, the location and specifications of mechanical, electrical, and plumbing (MEP) systems, information technology (IT), safety and security elements, and lighting.
  • systems integration designs are generated in parallel using the computational resources of the large scale processing system to design, model, simulate, optimize, and verify the different systems integration designs.
  • systems integration designs SI111, SI112, SI113 are generated for spatial arrangement SA11
  • systems integration designs SI121, SI122, and SI123 are generated for spatial arrangement SA12
  • systems integration designs SI131 , SI132, and SI133 are generated for spatial arrangement SA13, and so on for a total of twenty-seven different systems integration designs.
  • Fig. 11 illustrates an example of a unified data model 190 that is used by the BRP in the design, modeling, simulation, optimization, and verification of a computer building system.
  • the unified data model includes a behavioral hierarchy 192, a spatial hierarchy 194, and a physical hierarchy 196.
  • the behavioral hierarchy 192 defines the operational and business processes from single activities by individuals in dedicated rooms using specific equipment, to processes in departments, processes in service lines or business units to a building-wide operational model.
  • the behavioral description can have various degrees of abstraction. For example, a department can be described as a single activity incurring costs and producing revenue, towards an activity handling patients, taking time, incurring costs and producing revenue, or an activity of staff handling patients, requiring specific equipment.
  • a department can be described as a single activity incurring costs and producing revenue, towards an activity handling patients, taking time, incurring costs and producing revenue, or an activity of staff handling patients, requiring specific equipment.
  • non-human elements such as, for example, energy, light, and water.
  • the behavioral hierarchy ranges from activity, to process, to service, to building operations, with each level in the behavioral hierarchy being more abstract than its predecessor.
  • the spatial hierarchy 194 describes how the volume of a building is organized. For example, a building has stories, each story has departmental blocks and corridors, departmental blocks have rooms, hallways and circulation spaces, rooms contain furniture/fixtures/equipment (FFE) elements.
  • FFE furniture/fixtures/equipment
  • Spatial descriptions can have various degrees of abstraction.
  • a building can be described from a vague buildable volume, a volume dictated by the site, physical constraints, legal constraints, and owner desires, towards the concept of an architectural parti describing a building configuration, e.g., an atrium versus a spine, towards a description of the major horizontal and vertical circulation areas, towards a global allocation of departments into various sections of the building, towards the exact location of every room and corridor in the building.
  • the spatial hierarchy ranges from room layout, to department layout, to block and stack layout, to building layout, with each level in the spatial hierarchy being more abstract than its predecessor.
  • the physical hierarchy 196 describes how the physical building will be composed from a list of predefined building components.
  • the physical hierarchy ranges from material, to elements, to systems, to buildings, with each level in the physical hierarchy being more abstract than its predecessor.
  • the building elements may include a set of predefined physical components such as interior walls, exterior walls, floor panels, roof panels, bathroom pods, aggregate equipment wall floor modules, equipment components and pods, utility frames, rebar cages for concrete structures, metal and concrete floor assemblies, structural steel, and utility systems.
  • certain aspects of the building components such as dimensions, performance characteristics, aesthetic ratings, environmental concerns, cost, product life, etc., are known in advance and used as desired in the different domains of the BRP 102.
  • predefined building components each with known characteristics, allows for the development and reuse of mathematical models to design, model, simulate, optimize, and verify complex building systems.
  • each of the data hierarchies and at each hierarchical level there is both an abstract description and one or more structural descriptions. That is, within the unified data model, an object is described as consisting of a set of connected instances of objects of a lower level. For example, a process of a patient coming in for a regular exam could be described as a connected graph of individual activities involving different people and occurring at different locations.
  • the unified data model may be used by the BRP in the design, simulation, optimization, and/or verification operations.
  • FIG. 12 is a process flow diagram of a computer-based technique for generating a systems integration design from a set of customer needs.
  • the technique utilizes a highly iterative computer-based process loop 200 that relies on computationally intensive simulation, optimization, and verification operations performed by HP2 computing resources to implement a design process that heretofore has not been envisioned and could not have been accomplished using a conventional PC-based computer system and conventional building design processes, including discipline-specific proprietary databases.
  • customer needs are specified.
  • the customer needs are specified through a user interface that queries a user to input customer needs according to a specific functional description. Examples of information processed at the customer needs domain have been described above.
  • additional information such as information related to best practices, including building and/or operational flow, and building codes may be entered as part of the customer needs. For example, there may be location-specific and/or customer-specific best practices and building codes that should be
  • At block 204 at least one business model is generated in response to the customer needs.
  • the business model specifies what services the building is to offer and at what volume the services are to be offered.
  • the business model may define the type and volume of acute healthcare services that should be provided to meet anticipated demand.
  • the behavior of one or more of the business models is simulated.
  • a behavioral simulation uses workflow modeling to simulate how the specified services could be provided. For example, a simulation could compare people and process workflow patterns with space patterns to determine how a proposed business model would perform.
  • the results of the behavioral simulations can be output in the form of performance metrics, for example, as graphs or ratings of such parameters as patient wait times, machine utilization, number of staff required, staff utilization, space utilization, energy efficiency, etc.
  • Various different parameters can be used to evaluate the desirability of business models based on the behavioral simulation.
  • the results of the behavioral simulations can be evaluated to see if the customer needs have been met. This can be a manual process, which includes direct human interaction, an automatic process (no human interaction), which is based on preprogrammed criteria, or a combination thereof.
  • the business model can be put through a computer-based optimization process. For example, the computer-based optimization process can run through a large number of design alternatives to optimize certain aspects of the building design.
  • an optimization process attempts to optimize areas of importance that are specified in the customer needs. For example, if the customer needs place a high value on worker convenience, then designs that minimize worker walking distances may be favored. Likewise, if the customer needs place a high value on energy efficiency, then designs that minimize the need for artificial light and HVAC may be favored. Other criteria for
  • optimization may include Return on Investment (ROI), capital expense operating expense, patient wait time, or any combination thereof.
  • ROI Return on Investment
  • the optimized business model is put through a validation process.
  • the validation process checks to see if a particular business model meets particular design rules (e.g., design rule checking) and/or to see if the business module meets the specified customer needs.
  • design rules e.g., design rule checking
  • the process of generating a new business model (or modifying an already existing business model), behaviorally simulating the new business model, optimizing the new business model, and validating the new business model, can be run through multiple iterations before the design moves to the spatial arrangement domain.
  • each validated business model can be used as input to generate one or more spatial arrangements. As described above, a spatial
  • the spatial arrangement may specify the form and shell of a building system, the block and stack arrangement of the building system, and the room placement.
  • the spatial arrangement may be simulated and/or optimized as described using the HP2 computing resources.
  • the spatial arrangement can be processed through an iterative process of verification and modification.
  • the verification operation may involve design rule checking and the modification may involve adjusting one or more parameters of the spatial arrangement.
  • each verified spatial arrangement can be used as input to generate one or more systems integration designs.
  • the systems integration design may specify the 3D spaces and infrastructure of the building system.
  • the systems integration design may be simulated and optimized as desired using the HP2 computing resources.
  • the spatial integration design can be processed through an iterative process of verification and modification.
  • the verification operation may involve design rule checking and the modification may involve adjusting one or more parameters of the systems integration design.
  • the output of the systems integration design can be used to implement operations in the manufacturing, assembly, commissioning, and operation domains as represented by blocks 228, 230, 232, and 234, respectively.
  • Fig. 13 illustrates system elements and a corresponding process flow for generating a spatial arrangement from a business model using the BRP 102.
  • the system elements include at least one of the business model databases 170, at least one of the spatial arrangement databases 174, an analysis database 240, a building design knowledge base 242, synthesis tools 244, analysis tools 246 (e.g., simulation and/or validation), and optimization tools 248.
  • a codes and rules element 250 includes building codes and building design rules
  • a patterns element 252 includes a pre-established set of design patterns (e.g., architectural patterns or architectural partis)
  • a healthcare (HC) processes element 254 includes healthcare process workflow rules
  • a rooms library 256 includes a pre-established set of rooms that have certain physical and/or operational
  • the information from the business model is processed by the synthesis tools to generate one or more spatial arrangements.
  • the synthesis tools use information from the building design knowledge base and design intent 258 (e.g., design criteria) to generate a spatial arrangement.
  • the spatial arrangement can then be analyzed (e.g., simulated and/or validated) as desired and the results of the analysis are stored in the analysis database.
  • the optimization tool can be used to change parameters of the design intent (e.g., the orientation of the building (see Fig. 7) or the number of rooms per wing or the nurse ratio (see Fig. 9)), which are then propagated through the synthesis tools to generate optimized spatial arrangements.
  • a building system may include one or more buildings that can be detached from each other, partially attached to each other, or fully attached to each other.
  • a building system may be a building or a set of buildings that are located at the same physical site/location and that are intended to fulfill a set of customer needs.
  • Fig. 14 illustrates an embodiment of the architecture of an embodiment of the BRP relative to a user interface device 146 on a client side of a network and a cloud service from which the BRP 102 is implemented.
  • the BRP includes a BRP application 300, realization engines 302, an application programming interface (API) 304, a middleware connector 306, and a database 308.
  • the realization engines provide the design, modeling, simulation, optimization, and verification services of the BRP and the BRP application provides the logic that allows the user of the client device to communicate with and control, via a user interface, the services that are provided by the realization engines.
  • the API provides the logic to enable the realization engines to obtain data from and provide data to the database.
  • the middleware connector provides an abstraction layer between the realization engines and the database.
  • the database stores data related to the design, modeling, simulation, optimization, and verification of building systems.
  • the database includes a construction database 310, an analysis database 312, a library of process knowledge 314, and a library of design rules 316 although the data in the database can be organized in other ways.
  • the computer readable instructions necessary to implement the BRP application, the realization engines, the API, and the middleware connector and the data in the database are stored in servers of the cloud service. When called upon for execution, the instructions and corresponding data are processed by processors of the cloud service as described above.
  • Fig. 15 illustrates the execution of a service that is provided by one of the realization engines 302.
  • the service is a simulation that involves distributing a set of computational tasks amongst a large number of physically distinct processors or separate processing cores. As shown in Fig. 15, N different
  • processors 350 are distributed amongst N different processors 350, where N is, for example, in the range of 100 - 1,000.
  • N is, for example, in the range of 100 - 1,000.
  • the processors may be provided through a cloud service and used only on an as needed basis.
  • the BRP 102 allows the generation and optimization of a virtual building based on user needs and a comprehensive set of rules including building codes and best practices in the corresponding industries.
  • Users create virtual buildings using a design flow that morphs the design gradually from a very abstract description (for example, serve an area defined by a set of ZIP codes with enough acute care capacity to satisfy demand) to a fully detailed description containing architectural intent, engineering details, and construction details that leave no ambiguity as to how the building should be built and how the building system will perform.
  • a virtual building is complete within the BRP, detailed operation and construction documents can be generated by the BRP in various industry standard formats.
  • a virtual building system maintained by the BRP contains detailed information about the building and all its subsystems, and about its use and its performance along many dimensions such as operating costs, construction costs, thermal comfort level, daylight usage, sustainability, operational efficiency, patient experience.
  • the virtual building system maintained by the BRP is detailed and accurate enough that it can be used to unambiguously generate detailed construction documents for the construction of a real building system having a performance that matches the performance of the virtual building system.
  • the virtual building system that is maintained by the BRP can be used to predict the implications of changes during the lifetime of the building.
  • the virtual building system includes descriptions of: the building structure; the processes and service lines, the mechanical, electrical, plumbing (MEP) subsystems; the information technology (IT) subsystem; the thermal/energy behavior; the seismic behavior; the light behavior; and the sound behavior.
  • the virtual building system maintained in the BRP differs from current practices in the following ways: Besides the description of the physical building, the virtual building system also includes the description of the purpose and operation of the building as both the building and the processes need to be designed and measured together. The information about the building is partitioned differently.
  • Fig. 16 is a process flow diagram of a method for realizing a complex building system.
  • input related to customer needs for a building system is received, the input being received through a user interface at a remote client device and being expressed in a formal description language.
  • multiple different business models are generated from the customer needs input, wherein the business models define, in a functional language, types and volumes of services that will be provided within the building system to satisfy the customer needs.
  • multiple different spatial arrangements are generated from at least one of the business models, wherein the spatial arrangements define a form and shell of the building system, a block and stack of the building system, and room locations within the building system.
  • multiple different systems integration designs are generated from at least one of the spatial arrangements, wherein the systems integration designs define three dimensional spaces of infrastructure of the building system.
  • dependencies are tracked between the customer needs, the business models, the spatial arrangements, and the systems integration designs.
  • Fig. 17 is a process flow diagram of a method for realizing a building system within which healthcare services will be provided to patients.
  • input related to customer needs for a building system is received, the input being received through a user interface at a remote client device and being expressed in a formal description language, the input including an indication of a location at which the building system is to be built.
  • at least one business model is generated from the customer needs input, wherein the business model defines, in a functional language, types and volumes of healthcare services that will be provided via the building system.
  • an aspect of the business model is simulated.
  • an aspect of the business model is optimized.
  • At block 428 at least one spatial arrangement of the building system is generated from the at least one business model, wherein the spatial arrangement of the building system defines a form and shell of the building system, a block and stack of the building system, and a placement of rooms of the building system.
  • an aspect of the spatial arrangement of the building system is simulated.
  • the computationally intensive operations of simulation and optimization are distributed over multiple different processors of a large scale processing system.
  • an embodiment of a computer program product includes a computer useable storage medium to store a computer readable program that, when executed on a computer, causes the computer to perform operations, as described herein.
  • embodiments of at least portions of the invention can take the form of a computer program product accessible from a computer-usable or non- transitory computer-readable medium providing computer executable instructions, or program code, for use by or in connection with a computer or any instruction execution system.
  • a non-transitory computer- usable or computer readable medium can be any apparatus that can contain or store the program for use by or in connection with the instruction execution system, apparatus, or device.
  • the computer-useable or computer-readable medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device).
  • Examples of a computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk, and an optical disk.
  • Current examples of optical disks include a compact disk with read only memory (CD-ROM), a compact disk with read/write (CD-R/W), and a digital video disk (DVD).
  • Fig. 18 depicts a computer 500 that includes a processor 502, memory 504, and a
  • the processor may include a multifunction processor and/or an application-specific processor. Examples of processors include the PowerPCTM family of processors by IBM and the x86 family of processors by Intel such as the XeonTM family of processors and the Intel X5650 processor.
  • the memory within the computer may include, for example, storage medium such as read only memory (ROM), flash memory, RAM, and a large capacity permanent storage device such as a hard disk drive.
  • the communications interface enables communications with other computers via, for example, the Internet Protocol (IP).
  • IP Internet Protocol
  • the computer executes computer readable instructions stored in the storage medium to implement various tasks as described above.
  • the business model (BM) domain produces certain outputs, such as the building square footage needed to provide the desired services, which are used within the spatial arrangement (SA) domain to define certain aspects of the building system.
  • SA spatial arrangement
  • certain physical aspects of the building system are defined, including the building “form and shell,” the building “block and stack,” and the room placement.
  • the building system "form and shell” can also be referred to as the "building massing configuration.” As used herein, the building massing
  • configuration is at least partially defined by the footprint shape of the building system, the footprint dimensions, and the number of floors of the building.
  • the energy use of a building can be characterized by running an energy use simulation.
  • Various computer-based energy use simulation programs are available, including for example, Building Loads Analysis and System
  • EnergyPlus simulation program takes into consideration a large list of parameters to simulate the energy use of a building.
  • Parameters considered in an EnergyPlus simulation may include, for example, information about the building site, climate information, building construction specifics, building operating schedules, operating loads, and building massing configuration.
  • Some specific examples of simulation parameters include location coordinates, climate information, operating schedules, surface construction elements, thermal zone description/geometry, advanced surface concepts, detailed ground heat transfer, room air modules, internal gains (people, lights, other internal zone equipment), daylighting, exterior energy use equipment, and airflow.
  • a detailed description of EnergyPlus input and output data can be found in the document "Input Output Reference: The Encyclopedic Reference to EnergyPlus Input and Output," October 6, 2012, which is incorporated by reference herein.
  • an EnergyPlus simulation of a four-story 250,000 square foot building of average complexity can take a single processor computer on the order of 2 - 8 hours to complete, e.g., model, setup, and run time.
  • the computing power and time required to run EnergyPlus simulations can make it impractical to evaluate a large number, e.g., 10,000 - 30,000, of different building massing configurations early on in the building design process. Without a way to efficiently evaluate the energy use of a large number of building massing configurations, some desirable massing configurations may never come to the fore in the design process.
  • formulas are derived in advance for calculating the energy use of different building massing configurations so that a large number of different building massing configurations can be quickly evaluated for energy efficiency early on in the building design process.
  • the formulas are a function of a limited set of parameters that are directly related to the building massing configuration.
  • the formulas are a function of the shape of the building footprint, the dimensions of the building, and the number of stories of the building. Because the formulas are a function of a limited set of parameters, the energy use of a large number of building massing configurations can be quickly calculated for energy use evaluation early on in the design process.
  • the formulas are normalized to a reference building such that the energy use of each different building massing configuration is compared to the same standard, e.g., the reference building.
  • the predefined and normalized formulas are used in, for example, the Building Realization Platform (BRP) to calculate the energy use of multiple different building massing
  • a technique for characterizing the energy use of multiple different building massing configurations is based on building dimensions that are a function of a fixed size bay, where a bay defines at least a floor portion of the building.
  • each fixed size bay is a 30' x 30' square. Although a 30' x 30' square bay is described, other shapes and dimensions of a fixed size bay are possible. Given 30' x 30' fixed size bays, the footprint shape of each story of a building is a function of the 30' x 30' bays and can only be changed by 30' increments.
  • Figs. 19a - 19h depict nine different predefined footprint shapes, including footprint shape R (Fig. 19a), footprint shape L (Fig. 19b), footprint shape Z (Fig. 19c), footprint shape K (Fig. 19d), footprint shape X (Fig. 19e), footprint shape T (Fig. 19f), footprint shape U (Fig. 19g), footprint shape H (Fig.
  • each footprint shape has been given a "shape name" for identification purposes.
  • the set of shape names defines a shape alphabet, which is represented as: R, L, Z, K, X, T, U, H, O.
  • dimensions of the footprint shapes are identified as Bx, By, W, and H, where:
  • the bounding box dimensions represent the dimensions of a box defined by the maximum x-axis and y-axis dimensions, and the void area dimensions W and H are specific to each footprint shape.
  • a technique for characterizing the energy use of multiple different building massing configurations is now described in terms of the fixed size bay and the predefined set of footprint shapes.
  • a first step involves modeling the energy use of a reference building.
  • the building massing configuration of the reference building is defined as a square building that has a 2-bay x 2-bay footprint and three stories.
  • Fig. 20 depicts the footprint shape 602 of the reference building and the building massing configuration of the reference building is defined as:
  • Ns 3, where Ns is the number of stories.
  • the reference building is a 60' x 60' square that is three stories high.
  • the energy use of the reference building is calculated.
  • the energy use of the reference building is calculated on an energy use per annum, per square foot basis, which is referred to herein as the energy use index (EUI).
  • EUI energy use index
  • a process for calculating the energy use index, EUI, of the reference building is described with reference to Fig. 21.
  • the process uses the EnergyPlus simulation program to calculate the total energy use of the reference building per annum and then divides the total energy use by the total square footage of the reference building to come up with an energy use index for the reference building, EUI-RB.
  • a modeling input 604 is generated for the reference building.
  • the modeling input includes building massing configuration information and other information as required by the EnergyPlus program.
  • the modeling input may be presented in an EnergyPlus input file (IDF) that also defines the simulation parameters.
  • IDF EnergyPlus input file
  • a number of tools are available to create EnergyPlus input files. These include, for example, Easy EnergyPlus, ECOTECT, EnergyPlugged, EP-GEO & EP-SYS, EP-QUICK, ESP-r, jEPlus, and EP-Launch. Other techniques may also be used to create EnergyPlus input files.
  • One technique for creating simulation input filed, e.g., EnergyPlus input files, is described below.
  • EnergyPlus simulator 606 which runs an EnergyPlus simulation to determine the total energy use 608 of the reference building. For example, the total energy use is calculated on in a per annum basis and it may be in the range of 20 - 40 GWh/annum for a 250,000 square foot building that delivers healthcare services. The total energy use is then provided to an index er 610 to calculate the energy use index of the reference building, EUI-RB, 612.
  • the energy use index of the reference building, EUI-RB can be expressed as:
  • EUI-RB total energy use per annum/gross square footage
  • the energy use index of the reference building is used as described below to normalize the simulation results for multiple different building massing
  • energy use is characterized with respect to a predefined set of footprint shapes.
  • a next step in the process involves modeling the energy use of buildings that utilize each of the different pre-defined footprint shapes, referred to herein as shape-specific modeling.
  • shape-specific modeling the energy use of multiple different building massing configurations is simulated for each different footprint shape and the results are used to generate a normalized energy use index, nEUI, for each different building massing configuration.
  • a process for generating normalized energy use indexes, nEUIs, for buildings having the footprint shape R is described with reference to Fig. 22.
  • a first step in the process involves establishing the modeling input 620 for an EnergyPlus simulation.
  • the modeling input includes a set of building massing configurations in which each instance of a configuration has a different combination of configuration parameters, e.g., Bx, By, and Ns, but the same footprint shape.
  • each different shape-specific building massing configuration has a unique identifier, e.g., Ri, R 2 ,...R n .
  • the number of different shape-specific building massing configurations (e.g., where a shape-specific building massing configuration is defined by a unique set of Bx, By, W, H, and Ns) that are established as inputs is on the order of thousands, e.g., 1,000 - 5,000 per footprint shape.
  • the number of different shape-specific building massing configurations is a function of the range of possible values for Bx, By, W, H, and Ns, where the range of possible values for Bx, By, W, H, and Ns is selected to reflect the possible range of building massing configurations that are to be evaluated.
  • the total number of different shape-specific building massing configurations can be expressed as:
  • sets of building massing configurations are pre-generated for each footprint shape and stored in a building massing configuration library, or "massing library.”
  • the massing library includes building massing configurations, also referred to as design patterns, architectural patterns, or architectural partis, as described with reference to Fig. 13 and patterns element 252.
  • the modeling input 620 includes the building massing configuration and other information that is required by the EnergyPlus simulator.
  • the modeling input may be provided in an IDF file that defines the EnergyPlus simulation parameters.
  • EnergyPlus simulations are run for each different building massing configuration.
  • the EnergyPlus simulations can be run, for example, in series on a single processor machine, in parallel on a multiprocessor machine, or in parallel using HPHP computing resources as described above with reference to Fig. 2.
  • HPHP computing resources as described above with reference to Fig. 2.
  • the total energy use is calculated on, for example, a per annum basis and may be in the range of 1 - 2 GWh/annum.
  • the total energy use 622 for each building massing configuration e.g., Ri
  • the indexer 610 to calculate the corresponding energy use index, e.g., EUI-Ri, 624.
  • the energy use index of the building massing configuration is then provided to a normalizer 626, which normalizes the energy use index by dividing the shape-specific energy use index by the energy use index of the reference building.
  • the operations of energy use simulation, indexing, and normalizing are performed for each of the different shape-specific building massing configurations, e.g., Ri, R 2 ,...R n to produce shape-specific normalized energy use indexes nEUI-Ri, nEUI-R 2 ,...nEUI-R n , 628.
  • the nEUI data is stored in a shape-specific database for further processing as described below.
  • Fig. 23 illustrates an embodiment of the process for generating normalized energy use indexes for buildings having the footprint shape L.
  • the number of different L-shaped building massing configurations is on the order of thousands, e.g., 1,000 - 5,000, as described above.
  • the modeling input 630 includes the building massing configuration and other information that is required by the EnergyPlus simulator.
  • EnergyPlus simulations are run for each different building massing configuration to calculate the total energy use 632 on, for example, a per annum basis.
  • the total energy use for each building massing configuration e.g., L ls is provided to the indexer 610 to calculate the corresponding energy use index, e.g., EUI-Li, 634.
  • the energy use index of the building massing configuration is then provided to a normalizer 624, which normalizes the energy use index by dividing the shape-specific energy use index by the energy use index of the reference building.
  • the operations of energy use simulation, indexing, and normalizing are performed for each of the different L-shape building massing configurations, e.g., L ls L 2 ,...L n to produce shape-specific normalized energy use indexes nEUI-Li, nEUI-L 2 ,...nEUI-L n , 638.
  • the nEUI data is stored in a shape-specific database for further processing as described below.
  • shape-specific formulas are derived from the normalized energy use index data.
  • formulas are derived that define the normalized energy use index, nEUI, as a function of a limited set of variables related to the building massing configuration.
  • the formulas define the shape-specific normalized energy use indexes, nEUI, as a function of the parameters; Bx, By, W, H, Ns, and in some cases ⁇ , where ⁇ is the angular orientation of the building, e.g., relative to magnetic north.
  • Fig. 24 illustrates an embodiment of the normalized energy use index derivation operation, which includes shape-specific nEUI databases 650, a normalized energy use index formula derivation engine 652, and shape-specific nEUI formula databases 654.
  • the shape-specific nEUI databases 650 include a database for each different footprint shape
  • the shape-specific nEUI formula databases 654 include a database for each different footprint shape.
  • the nEUI formula derivation engine 652 includes a shape-specific nEUI formula derivation engine 656, a nEUI base formula derivation engine 658, and a shape-specific correction factor derivation engine 660.
  • the shape-specific normalized energy use index data is used by the shape-specific nEUI formula derivation engine 656 to derive shape- specific formulas that best fit the corresponding data as a function of a limited set of variables, e.g., Bx, By, W, L, Ns, and ⁇ .
  • a limited set of variables e.g., Bx, By, W, L, Ns, and ⁇ .
  • a formula to represent nEUI for each footprint shape may be derived by: 1) plotting all of the nEUIs that were calculated during the shape-specific simulations, 2) observing trends (e.g., energy demand trends) with respect to each of the shape definition parameters (e.g., Bx, By, W, H, Ns, 3, and ratio of perimeter length to footprint area), 3) finding a parameter (e.g., Bx, By, W, H, Ns, ⁇ , and ratio of perimeter length to footprint area) that primarily affects a general trend (e.g., an energy demand trend) of the plotted curve, 4) finding the best formula as a function of the primary parameter to describe the general trend (e.g., energy demand trends) by using polynomial curve-fitting or by applying knowledge of curve patterns that can be described with other means of mathematical functions, 5) finding secondary, tertiary, and so on parameters (e.g., Bx, By, W, H, Ns, ⁇ , and ratio of perimeter
  • the formula derivation involves identifying key contributing factors (e.g., Bx, By, W, H, Ns, ⁇ , and ratio of perimeter length to footprint area) that effect the energy demand of a building massing configuration.
  • the operation of the shape- specific nEUI formula derivation engine 656 is repeated for each shape-specific database.
  • the nEUI base formula derivation engine 658 derives a base formula, which is common to all of the footprint shapes, from the previously derived shape-specific formulas.
  • a nEUI base formula, which is common to all of the footprint shapes may be derived by: 1) finding the most common form of formula among all the formulas derived for each footprint shape, 2) determining a new pattern of formula (base formula) that generally describes the nEUIs of all footprint shapes, and 3) re-establishing formulas for each footprint shape using the base formula to describe nEUI trends of each footprint shape.
  • the shape-specific correction factor derivation engine 660 derives a correction factor for each footprint shape to calibrate the base normalized energy use index formula.
  • the correction factor corrects for variations related to the number of stories of the buildings, the void area dimensions, and in at least one case the orientation of the building in degrees, ⁇ , relative to, for example, true north.
  • the nEUI formulas for each footprint shape may be further improved by: 1) plotting and comparing a calculated nEUI curve with a simulated result curve, 2) finding parameters (e.g., Bx, By, W, H, Ns, S, and ratio of perimeter length to footprint area) that can make the calculated nEUI curve closer to the simulated result curve, and 3) introducing correction terms that are functions of those parameters to reduce the error percentage to within an acceptable range, e.g., within 5% of the actual values.
  • parameters e.g., Bx, By, W, H, Ns, S, and ratio of perimeter length to footprint area
  • the base formula and/or correction factor may include intermediary factors and or coefficients. Examples of intermediary factors include:
  • Bfp total number of bays in the footprint
  • Examples of shape-specific formulas that have been derived for calculating the normalized energy use indexes, nEUIs, are provided in the Appendix.
  • the examples include formulas for single-storey, two-storey, and three-plus storey buildings having footprint shapes R, L, Z, K, X, T, U, H, and O.
  • the Appendix also includes alternate formulas that have been derived for buildings having more than two stories.
  • the shape-specific formulas including corresponding coefficients, for calculating the normalized energy use indexes, nEUIs, are stored in the shape-specific nEUI formula databases 654 for use in the Building Realization Platform (BRP) as described below. It should be noted that, in an embodiment, the operations described with reference to Figs. 19a - 24 are preliminary operations that are performed in advance of the use of the building realization program in the BRP. [00145] Use of the shape-specific formulas to characterize the energy use of multiple different building massing configurations early on in the building design process is now described with reference to Fig. 25. When utilized within the Building Realization Platform (BRP) described above with reference to Figs.
  • different building massing configurations are provided to a massing configuration evaluator 670.
  • the different building massing configurations are provided to the massing configuration evaluator as a set of parameters that can be defined as specific finite values or value ranges.
  • the set of parameters may include: 1) a listing of the preferable footprint shapes;
  • the energy massing configuration evaluator uses the predefined shape-specific formulas to calculate normalized energy use indexes, nEUIs, for each building massing configuration and to output the normalized energy use indexes as desired by the user.
  • nEUIs the magnitude of the calculated normalized energy use indexes, is an indication of the energy efficiency of a particular building massing configuration relative to the reference building. Therefore, a relatively large nEUI indicates that the particular building massing configuration is less energy efficient, e.g., a building with the massing configuration would require more energy to operate, and a relatively small nEUI indicates that the particular building massing configuration is more energy efficient, e.g., a building with the massing configuration would require less energy to operate.
  • nEUIs energy use indexes
  • nEUIs normalized energy use indexes
  • range of footprint bounding box area 1 ⁇ Bx ⁇ 7 and 1 ⁇ By ⁇ 6;
  • the massing configuration evaluator 670 calculates normalized energy use indexes, nEUIs, for 24,693 different building massing configurations.
  • all of the normalized energy use indexes, nEUIs were calculated in less than one minute using the predefined formulas.
  • the time frame of minutes is orders of magnitude less than the days, weeks, or months that would be required to run a different EnergyPlus simulation for each one of the different building massing configurations.
  • Fig. 26 depicts an embodiment of a user interface that displays the normalized energy use indexes, nEUIs, of 32 of the 24,693 different building massing configurations.
  • Fig. 26 depicts a scrollable window of building massing configurations 1 - 100 of 24,693 (highlighted box 672), in which the building massing configurations all have the footprint shape, R.
  • Fields shown in Fig. 26 include: id - a unique identification number of the building massing configuration;
  • the massing configuration evaluator is configured to allow the set of normalized energy use indexes, e.g., all 24,693 nEUIs, to be searched, sorted, and/or manipulated in various ways to allow the data to be presented in a manner that is useful to the user. For example, the user may request a ranking of the 10 building massing configurations with the lowest normalized energy use index.
  • normalized energy use indexes e.g., all 24,693 nEUIs
  • Fig. 27 depicts an embodiment of the user interface of Fig. 26 in which a search menu 674 is overlaid on the data from Fig. 26.
  • the search menu includes fields that match the columns of the data in Fig. 26, and the search menu is populated with four search parameters.
  • the four search parameters are indicated in highlighted boxes 676 and 678:
  • Fig. 28 depicts an embodiment of the user interface of Fig. 26 in which the displayed data is limited to building massing configurations that meet the criteria described with reference to Fig. 27. As illustrated in Fig. 28 (highlighted box 680), 403 of the original 24,693 different building massing configurations meet the search criteria and the building massing configurations are ordered by nEUI.
  • sets of building massing configurations are generated using a shape grammar approach.
  • an initial set of building massing configuration primitives is generated from a base solid mass 702 and the application of at least one void object 704.
  • the base solid is a three-dimensional rectangular mass having nonzero x, y, and z axis dimensions.
  • a set of rectangular masses can be generated by varying the x, y, and z axis dimensions (e.g., parametrically in one bay increments where a bay is a fixed size, e.g., 30' x 30', and in one floor increments where a floor is a fixed size, e.g., 15').
  • Other building massing configuration primitives can be generated by applying a set of rules, referred to as a shape grammar, to the
  • the set of rules involves applying at least one three-dimensional void object to the rectangular mass, in this case, a rectangular void object although void object with other shapes are possible.
  • multiple different void objects can be applied to a rectangular mass.
  • void objects are applied to a rectangular mass to form a set of building massing primitives. For example, one, two, three, or four voids can be applied to a mass to form different building massing configurations.
  • the shape grammar is applied in a manner that generates building massing configurations 706 having the footprint shapes as described above with reference to figures 19a - 19i.
  • the building massing configuration shape primitives which are referred to herein as "building letters" of a "building alphabet” include the shapes R (not shown), H, K, L, O, R, T, U, X, and Z.
  • applying values to the x, y, and z dimensions of the rectangular mass and to the void object(s) that correspond to realistic building sizes can result in thousands of different building massing configurations, e.g., 20,000 to 30,000 different building massing configurations.
  • a building alphabet with a particular set of footprint shapes e.g., the "letters" of the alphabet
  • other shapes may be included in the building alphabet and the shape geometry can be modified by changing the shape grammar.
  • Fig. 30 depicts a graphical user interface (GUI) 710 that graphically displays building massing configurations 712 for a rectangle footprint shape.
  • the graphical user interface of Fig. 30 helps to illustrate the scale of the number of different building massing configurations that can be generated for a single footprint shape.
  • the generated set of building massing configurations can be stored in a database for fast and flexible access by the BRP.
  • Fig. 31 depicts a graphical user interface 720 of entries in a building alphabet database that is generated using the shape grammar as described with reference to Fig. 29.
  • the building alphabet database includes 24,693 different building massing configurations, with configurations 1 - 33 being currently displayed.
  • the information in the graphical user interface is similar to that described above with reference to Fig. 26.
  • the building alphabet database is searchable by any of the column fields. For example, a search can be run to find only those shapes that will fit on a particular building site having specific x and y dimensions. Such a search, or "pre-filtering,” can be performed by specifying the limits of the bounding box dimensions, Bx and By. Other criteria (e.g., area, volume, aspect ratio, nEUI) can be used to pre-filter the building massing configurations. Fig.
  • a graphical user interface 724 that includes a search window 726 that allows certain parameters of a search to be specified.
  • the search window allows any of the column parameters of a building massing database to be specified and searched according to the specification.
  • the search criteria specifies alphabet letters "L" and "O", area between 100,000 and 150,000 sq. ft., and having an nEUI of less than 0.6.
  • a pre-filtered set of building massing configurations is used to populate a building massing library for a specific building project.
  • the building massing library can be unfiltered such that the entire set of generated building massing configurations is available for evaluation in the context of the building design.
  • Fig. 33 illustrates the application of shape grammar to the building alphabet to form more complex building massing configurations 730, referred to herein as "building words.” As illustrated across the top row of Fig. 33, applying a rule of "H+L” results in the building word depicted in the upper right corner of Fig. 32. Rows 2 - 5 of Fig. 33 illustrate other rules in the shape grammar, e.g., "H+L+R,"
  • the shape grammar is parametrically applied to form multiple building massing configurations of the same building word.
  • the shape grammar is applied to a pre-filtered set of building alphabet elements.
  • a pre-filtered set of "H” building elements may include 10 different building massing configurations and a pre-filtered set of "L” building elements may include 20 different building massing configurations.
  • the shape grammar is configured to require certain dimensions of two different building shapes to match, or to be within a certain range of each other.
  • the shape grammar may require that a particular dimension or dimensions of the "H” and "L” elements match so that the different stories of the building massing configuration have at least a portion of their respective footprints that are in common.
  • the shape grammar may be modified, updated, etc., as desired to trigger the generation of different building massing configurations.
  • Fig. 34 depicts a graphical user interface 736 that graphically displays building words 730 that are formed by combining different primitives (i.e., letters) of the building alphabet.
  • Fig. 34 depicts building words that include a "U” primitive stacked on top of an "R” primitive, a "T” primitive stacked on top of an "R” primitive, and a "Z” primitive stacked on top of an "R” primitive.
  • the x and y dimensions of the R primitives are fixed and the U, T, and Z primitives are applied to the R primitive in different dimensions, e.g., parametrically varied dimensions.
  • Fig. 35 depicts a graphical user interface 740 of different building massing configurations that are formed by a combination of the building letters.
  • the database includes 139 different building massing configurations having a particular combination of building letters, of which building massing configurations 1 - 35 are displayed.
  • Building massing configurations 1 - 35 include "RU" (R+U) building words and "RT" (R+T) building words.
  • the graphical user interface includes an id column, a name column, an alphabet column, an area column, and an EUI column.
  • the id column associates the building word with a unique identifier
  • the name column associates the building word with a unique building name
  • the alphabet column indicates which primitives from the building alphabet were used to form the building word
  • the area column is the total area in terms of floor space of the building word (e.g., assuming each letter represents a different floor)
  • the word EUI represents the combined normalized EUI, nEUI, of the building word, where the word EUI is calculated on a proportional basis, e.g., relative to footprint area using the nEUIs from the corresponding building primitives.
  • building massing configurations can be generated and referred to as building letters of a building alphabet or building words.
  • a particular building massing configuration is one contiguous mass, e.g., a single contiguous building.
  • a shape grammar can be applied to the building alphabet and/or to building words to generate multi-building configurations in which the buildings are not physically connected to each other.
  • Fig. 36 illustrates the application of shape grammar to a set of building words 730 to generate building sentences 744, e.g., HL+HL. As illustrated across the top row of Fig. 36, two HL (H+L) building words are associated with each other to form a building sentence.
  • the two HL building words are associated with each other in that the buildings are understood to be located together at the same physical site at a known spacing and in the orientation as shown.
  • Building sentences can also be generated from a building letter and a building word or from a building letter and another building letter, e.g., R+U.
  • Fig. 37 depicts an embodiment of a system 3702 for implementing the building massing configuration generation and management techniques as described above.
  • the system of Fig. 37 includes a shape grammar database 3704, a building massing library 3706 that includes a building alphabet database 3708, a building word database 3710, and a building sentence database 3712, a building massing generation engine 3714, and a query engine 3716.
  • the shape grammar database includes rules for generating the building alphabet, the building words, and/or the building sentences.
  • the building alphabet database stores a set or sets of building letters, or primitives, as described, for example with reference to Figs. 29 and 30.
  • the building word database stores a set, or sets, of building words as described for example with reference to Figs. 33 and 34.
  • the building sentence database stores a set, or sets, of building sentences as described, for example, with reference to Fig. 36.
  • the building mass generation engine applies the appropriate shape grammar, e.g., mass generation rules, to the appropriate shape database to form additional building massing configurations.
  • the query engine enables the various shape databases to be searched and managed to generate a set of building massing configurations that may be desirable for evaluation in a particular building project. For example, the query engine enables the building massing library to be searched according to a parameter, or set of parameters, to reduce the set of different building massing configurations to set of building massing configurations that is a subset of the original set.
  • the building massing library is searched to find only those building massing configurations that meet certain project requirements, e.g., bounding box size, total square footage, number of floors, architectural parti, and/or energy efficiency.
  • the reduced set of building massing configurations is then used to evaluate an aspect of a building design.
  • the building massing generation system is a component of the Building Realization Program (BRP), which is implemented through a combination of software and hardware, such as computer executable instructions stored in memory and executed by the computer 500 of Fig. 18.
  • BRP Building Realization Program
  • the generated building massing configurations are stored in the building massing library and can be used to support other functions in the Building Realization Program (BRP).
  • the building massing configurations in the building massing library can be used for energy analysis (as described in detail above), structural sizing (e.g., ETABS), structural detailing (e.g., Telka), block and stack, and facade generation.
  • N s Number of stories
  • EUI n Energy Use Index normalized with respect to the EUI of 2x2 bay 3 story building.
  • Formulations derived in this document are based on approximately 30,000 Energy Plus runs of a typical hospital environment. In order to determine the relative energy use index, nEUI, of various building massing options, the following parameters are varied but all others are fixed.
  • Each bay is set to 30'x30' for the EnergyPlus runs.
  • N s -2 e 0 for R s ⁇ 1.25 forR s ⁇ 1.25
  • B e 2 X ( B x + By) + 2x(B y -H)
  • B fp B x x By- (B x -2W)x(B y -
  • B e 2 X ( B x + By) + 2x(B y -H)
  • B fp B x x By- (B x -2W)x(B y -
  • V r B r - 2W

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Geometry (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Physics & Mathematics (AREA)
  • Evolutionary Computation (AREA)
  • General Engineering & Computer Science (AREA)
  • Architecture (AREA)
  • Civil Engineering (AREA)
  • Structural Engineering (AREA)
  • Computational Mathematics (AREA)
  • Mathematical Analysis (AREA)
  • Mathematical Optimization (AREA)
  • Pure & Applied Mathematics (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

L'invention concerne des procédés et des systèmes informatiques destiné à caractériser la consommation d'énergie de multiples configurations de masse de bâtiment différentes. Dans un mode de réalisation, un procédé informatique consiste à spécifier un ensemble de paramètres pour une configuration de masse de bâtiment, à calculer un indice de consommation d'énergie normalisé pour de multiples configurations de masse de bâtiment différentes qui satisfont l'ensemble spécifié de paramètres, l'indice de consommation d'énergie normalisé pour chacune des multiples configurations de masse de bâtiment différentes étant normalisé par rapport à un indice de consommation d'énergie de référence d'un bâtiment de référence, à classer les multiples configurations de masse de bâtiment différentes par les indices de consommation d'énergie normalisés respectifs, et à sélectionner au moins l'une des différentes configurations de masse pour un affichage sur une interface utilisateur graphique, selon le classement.
PCT/US2014/029250 2013-03-15 2014-03-14 Systeme et procede pour evaluer la consommation d'energie de multiples configurations de masse de batiment differentes WO2014144720A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN201480028039.2A CN105210066A (zh) 2013-03-15 2014-03-14 用于评估多个不同建筑体量配置的能量使用的系统和方法
EP14765767.0A EP2973077A4 (fr) 2013-03-15 2014-03-14 Systeme et procede pour evaluer la consommation d'energie de multiples configurations de masse de batiment differentes

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US13/833,386 US10452790B2 (en) 2011-03-17 2013-03-15 System and method for evaluating the energy use of multiple different building massing configurations
US13/833,386 2013-03-15

Publications (1)

Publication Number Publication Date
WO2014144720A1 true WO2014144720A1 (fr) 2014-09-18

Family

ID=51537770

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2014/029250 WO2014144720A1 (fr) 2013-03-15 2014-03-14 Systeme et procede pour evaluer la consommation d'energie de multiples configurations de masse de batiment differentes

Country Status (3)

Country Link
EP (1) EP2973077A4 (fr)
CN (1) CN105210066A (fr)
WO (1) WO2014144720A1 (fr)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10969127B2 (en) 2016-08-18 2021-04-06 Ademco Inc. Residential energy efficiency rating system
CN110781537B (zh) * 2019-09-20 2023-08-18 江苏绿瓴数字城市与智能建造研究院有限公司 建筑建模方法、装置、计算机设备及可读存储介质
CN111666284A (zh) * 2020-05-18 2020-09-15 天津科技大学 基于SQLite的建筑能耗不确定性数据库的建立方法及应用方法

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040113945A1 (en) * 2002-12-12 2004-06-17 Herman Miller, Inc. Graphical user interface and method for interfacing with a configuration system for highly configurable products
US7496487B2 (en) * 2000-03-03 2009-02-24 Beck Technology, Ltd. Computer-implemented building design and modeling and project cost estimation and scheduling system
US20110191069A1 (en) * 2008-06-30 2011-08-04 Tripod Components Pty Ltd System and method for designing a building
US20110257942A1 (en) * 2008-02-06 2011-10-20 Ankory Ran Apparatus and method for evaluation of design
US20120239353A1 (en) 2011-03-17 2012-09-20 Aditazz, Inc. System and method for realizing a building system

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101894183B (zh) * 2010-07-02 2012-05-02 重庆星能建筑节能技术发展有限公司 一种绿色建筑的分析与设计方法
CN102156463B (zh) * 2011-03-25 2013-05-08 浙江汉爵科技有限公司 建筑物能源计划管理控制系统

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7496487B2 (en) * 2000-03-03 2009-02-24 Beck Technology, Ltd. Computer-implemented building design and modeling and project cost estimation and scheduling system
US20040113945A1 (en) * 2002-12-12 2004-06-17 Herman Miller, Inc. Graphical user interface and method for interfacing with a configuration system for highly configurable products
US20110257942A1 (en) * 2008-02-06 2011-10-20 Ankory Ran Apparatus and method for evaluation of design
US20110191069A1 (en) * 2008-06-30 2011-08-04 Tripod Components Pty Ltd System and method for designing a building
US20120239353A1 (en) 2011-03-17 2012-09-20 Aditazz, Inc. System and method for realizing a building system

Non-Patent Citations (7)

* Cited by examiner, † Cited by third party
Title
GELETKA ET AL., SHAPE OF BUILDINGS AND ENERGY CONSUMPTION
GELETKA ET AL.: "Shape of Buildings and Energy Consumption.", 2012, XP055280959, Retrieved from the Internet <URL:http://suw.biblos.pk.edu.pl/resources/i1/i4/i4/i8/i8/r14488/GeletkaV_ShapeBuildings.pdf> *
LUISA G CALDAS ET AL., GENERATION OF ENERGY-EFFICIENT PATIO HOUSES WITH GENE ARCH COMBINING AN EVOLUTIONARY GENERATIVE DESIGN SYSTEM WITH A SHAPE GRAMMAR
N LONG ET AL., OBJECT-ORIENTED DATABASE FOR MANAGING BUILDING MODELING COMPONENTS AND METADATA: PREPRINT
See also references of EP2973077A4 *
SINGH ET AL.: "Comparison of Two Different Simulation Programs while Calibrating the Same Building.", 1 August 2012 (2012-08-01), XP055280961, Retrieved from the Internet <URL:hftp://www.ibpsa.us/simbuild2012/Papers/SB12_TS02b_4_Singh.pdf> *
YU: "Mining Hidden Knowledge from Measured Data for Improving Building Energy Performance.", January 2012 (2012-01-01), XP055280956, Retrieved from the Internet <URL:http://spectrum.library.concordia.ca/973713/l/Yu_PhD_S2012.pdf> *

Also Published As

Publication number Publication date
EP2973077A1 (fr) 2016-01-20
EP2973077A4 (fr) 2016-11-16
CN105210066A (zh) 2015-12-30

Similar Documents

Publication Publication Date Title
US10452790B2 (en) System and method for evaluating the energy use of multiple different building massing configurations
US9507885B2 (en) System and method for realizing a building using automated building massing configuration generation
US9607110B2 (en) System and method for realizing a building system
US9721046B2 (en) System and method for realizing a building system that involves computer based matching of form to function
EP2973075A1 (fr) Système et procédé destinés à mettre en uvre un système de construction impliquant un appariement informatisé d&#39;une forme et d&#39;une fonction
US10891405B2 (en) Method, computer program product and apparatus for providing a building options configurator
US11328102B2 (en) Digital design tools for building construction
Mattern et al. BIM-based modeling and management of design options at early planning phases
US20120203806A1 (en) Building information management system
Staub-French et al. Linear scheduling and 4D visualization
WO2019173284A1 (fr) Procédé et système de création paramétrique d&#39;une structure de construction tridimensionnelle optimale
Janssen Dexen: A scalable and extensible platform for experimenting with population-based design exploration algorithms
EP2973077A1 (fr) Systeme et procede pour evaluer la consommation d&#39;energie de multiples configurations de masse de batiment differentes
Lin Designing-in performance: energy simulation feedback for early stage design decision making
EP2973073A1 (fr) Système et procédé pour réaliser un bâtiment par génération de configurations d&#39;agglomération de bâtiments automatisée
Muthumanickam et al. Multidisciplinary concurrent optimization framework for multi-phase building design process
Kwon et al. Integrated exploration of building shapes based on structural performance
Mishra et al. S4W: a problem‐solving environment for wireless system design
Chun et al. Automatic simulation and carbon analysis for architecture design
de Vasconcelos Feist A-BIM: Algorithmic-based Building Information Modelling
Chun HUANG et al. Automatic Simulation And Carbon Analysis For Architecture Design

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14765767

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2014765767

Country of ref document: EP