Building performance analysis (BPA) machine: machine learning for facilitating building energy analysis

Abstract

A method and system generate building operational performance analysis output. A synthetic dataset is generated and includes a set of 3D building conceptualized block geometry. The generating includes identifying geometry types, partitioning the geometry types into classes, and algorithmically generating the block geometry using a generative design using a separate workflow for each class. An analysis model is generated associated with each of the block geometry. Simulation results are generated for each of the analysis models. A surrogate model is trained using machine learning (ML) based on a set of features extracted from the simulation results. The ML iteratively determines the set of features based on a measured accuracy of the surrogate model. A geometry input is received and processed by the surrogate model to generate the building operational performance analysis output, which is then used to inform a designer of an approximate energy use intensity of the geometry input.

Description

[0001] Cross-references to related applications

[0002] This application claims the benefit of the following pending and co-assigned U.S. provisional patent application pursuant to 35 U.SC119(e), which is incorporated herein by reference:

[0003] Provisional application serial number 63 / 113,295, filed on November 13, 2020, is authored by Mohammad RahmaniAsl, Zachary Micah Kron, Varvara Toulkeridou, Michael Travis Floyd, Ian Molloy, Vishal Vaidhyanathan, Graceline R. Amour, and Spyridon Ampanavos, and is titled "Building Performance Analysis (BPA) Machine: Machine Learning to Accelerate Building Energy Analysis". The attorney's application number is 30566.0593USP1. Background of the Invention

[0004] 1. Field of Invention

[0005] This invention relates generally to building analysis, and more specifically, to a method, apparatus, system, and article for using machine learning to facilitate building energy performance analysis in the early design phase.

[0006] 2. Relevant Technical Specifications

[0007] Studies have shown that buildings account for 40% of carbon emissions. By performing simulations of the likely ways a building will consume energy (in an accurate manner), designers are allowed to reduce the energy that the building will consume. Moreover, if such simulations can be performed at early stages, architects and designers can make decisions that can be used to influence subsequent design decisions. Thus, it is desirable to analyze operational building energy performance in an automated manner, including during early design stages. More specifically, it is desirable to utilize generative design to produce synthetic data that can be used to train surrogate models in the right manner at early stages of the design process to automate some form of building performance analysis (i.e., energy). However, building energy analysis is a computationally intensive process whose processing time introduces a lag between the analysis and the design workflow. Thus, while there are various building performance analysis tools (e.g., AUTODESK INSIGHT), such tools are computationally expensive, do not provide real-time energy feedback, do not use generative design, and are not capable of being used during early stages of energy analysis. Accordingly, embodiments of the present invention address the problem of facilitating operational building energy performance analysis (and / or other building data analysis) using machine learning at early design stages. While there are previous studies that discuss the possibility of using machine learning to perform predictive energy analysis, none of them address the actual form or geometry of the building block. This renders it impossible to use the predictive method for real-time impact assessment as a measure of design assistance.

[0008] Prior art systems have attempted to solve the early design stage energy analysis problem using simple data sets, but none of them address the problem of building geometry and its form. Previous studies only work for a given building form and climate zone, whereas embodiments of the present invention can predict energy usage in real-time at early design stages for any given building form and potentially any number of climate zones. This is not addressed in previous studies. Additionally, prior art systems do not provide the capability to analyze other types of building data (e.g., solar, daylighting, thermal comfort, embodied carbon, structural analysis, construction cost, constructability, wind flow analysis (computational fluid dynamics), photovoltaic potential, building program requirements, construction scheduling, construction engineering schedule analysis and prediction, crowd simulation and shortest path finding, fire and smoke migration models, etc.).

[0009] Furthermore, there has not been done and proposed the use of generative design and other automated workflows for producing synthetic data sets, and the architecture of surrogate models that are conditioned to work with and learn from the synthetic data sets. SUMMARY

[0010] Embodiments of the present invention create real-time operational energy prediction services at the early design stage through a synthetic dataset generation method to train custom alternative model architectures, thereby substantially reducing the time and computation of current simulations and facilitating integration of real-time energy / data evaluation in geometry modeling environments (e.g., AUTODESK REVIT application or AUTODESK FORMIT application) and parametric environments (e.g., DYNAMO visual programming environment) to use real-time energy usage (or other data) as a measure of design direction and selection. Embodiments of the present invention also enable real-time energy (or other data) prediction to be used as a target function for generative design studies, thereby allowing users to generate multiple design options (with form or other building parameters) where energy usage (or other data) is a decision metric. BRIEF DESCRIPTION OF DRAWINGS

[0011] Reference will now be made to the drawings wherein like numerals refer to like parts throughout the several figures, and wherein:

[0012] Figure 1A An exemplary 3D geometry mesh is shown in accordance with one or more embodiments of the present invention;

[0013] Figure 1B An associated analysis model for each of the meshes created using default energy settings as a base scenario and compiled in a gbxml file is shown;

[0014] Figure 2 An overall workflow for performing building energy analysis is shown in accordance with one or more embodiments of the present invention;

[0015] Figure 3 Inter-relationships between a given building and mass are shown in accordance with one or more embodiments of the present invention;

[0016] Figure 4 Classification at the gross floor area level is shown in accordance with one or more embodiments of the present invention;

[0017] Figure 5 Classification at the mass level is shown in accordance with one or more embodiments of the present invention;

[0018] Figure 6 A logical flow for generating convex geometry of inscribed polygons of circles is shown in accordance with one or more embodiments of the present invention;

[0019] Figure 7 A logical flow for generating geometry of non-inscribed convex polygons is shown in accordance with one or more embodiments of the present invention;

[0020] Figure 8A logic flow for generating a concave polygon that is orthogonal is shown in accordance with one or more embodiments of the application;

[0021] Figure 9 A logic flow for generating a concave geometry that is not orthogonal is shown in accordance with one or more embodiments of the application;

[0022] Figure 10 A framework for generating synthetic data using a generative design application is shown in accordance with one or more embodiments of the application;

[0023] Figure 11 An exemplary reusable synthetic dataset geometry produced using a random function is shown in accordance with one or more embodiments of the application;

[0024] Figure 12 An exemplary combinatorial analysis / feature search dataset geometry produced using a random cross product function is shown in accordance with one or more embodiments of the application;

[0025] Figure 13 An exemplary form finding / sensitivity analysis dataset geometry produced using an analogies function is shown in accordance with one or more embodiments of the application;

[0026] Figure 14 An exemplary view of a geometry during a general process of one conversion of a volumetric block to an analytical model is shown in accordance with one or more embodiments of the application;

[0027] Figure 15 A logic flow for a general process of conversion of a volumetric block to an analytical model is shown in accordance with one or more embodiments of the application;

[0028] Figure 16 A process for expressing orientation as projected area and ratios is shown in accordance with one or more embodiments of the application;

[0029] Figure 17 A bounding box that defines a building to express orientation is shown in accordance with one or more embodiments of the application;

[0030] Figure 18 An exemplary bounding box is shown in accordance with one or more embodiments of the application, for each of two building levels, respectively;

[0031] FIG. 19 shows a logic flow for an example energy use intensity analysis in accordance with the prior art;

[0032] Figure 20 A logic flow for an example energy use intensity analysis based on a surrogate model in accordance with embodiments of the application is shown;

[0033] Figure 21 Another view for an example energy intensity analysis is shown in accordance with one or more embodiments of the application;

[0034] Figure 22 An example process for compiling a dataset is shown in accordance with one or more embodiments of the application;

[0035] Figure 23 A logic flow for generating and using building operational performance analysis output is shown in accordance with one or more embodiments of the application;

[0036] Figure 24 is a hardware and software environment for implementing one or more embodiments of the application; and

[0037] Figure 25 A typical distributed / cloud-based computer system is shown schematically, which uses a network to connect client computers to server computers. DETAILED DESCRIPTION

[0038] In the following description, reference is made to the accompanying drawings which form a part hereof, and which are shown by way of illustration of several embodiments of the present application. It is understood that other embodiments can be used and structural changes can be made without departing from the scope of the present application.

[0039] SUMMARY

[0040] Embodiments of the present application utilize two (2) stages to achieve correct energy performance analysis: (1) Stage 1 - Synthetic Dataset Generation (i.e., generating data that will support a Machine Learning (ML) model); and (2) Stage 2 - Surrogate / Machine Learning Model Creation. Details of each of these stages will be described below.

[0041] Stage 1

[0042] This stage of the work includes methods and subsequent framework for generating synthetic datasets - geometry data emulating buildings, and its corresponding analysis data (energy usage, energy settings, etc.) - utilizing automated processes such as generative design (e.g., in the AUTODESK REVIT application) and other computational methods. This dataset will be used to train a surrogate model (i.e., in Stage 2) to produce real-time (energy) prediction services, thereby reducing the time and computation of current simulations, and facilitating the integration of building (energy) assessment in the geometry modeling environment.

[0043] Objectives

[0044] The objectives in Phase 1 include one or more of the following:

[0045] - Creation of a comprehensive dataset that is morphologically diverse (and represents an array of volumetric blocks and contains corresponding analytical values) that enables training of machine learning (ML) models to identify any 3D geometry.

[0046] - Creation of an automated workflow framework / process to generate reusable synthetic datasets that can be used for future research (that avoid repetitive geometries and morphological biases).

[0047] - Development of a workflow that is parametric, enabling control and modification of the type and content of the generated datasets.

[0048] - Utilization and demonstration of the capability of generative design to perform such a workflow.

[0049] Requirement analysis / dataset composition

[0050] The initial development phase (to meet the objectives identified above) includes requirement analysis. For a given objective, it is necessary to identify the outputs that the synthetic dataset should include, such that it presents the ability to train surrogate models. Once the required composition is identified, the generative workflow for each of the composition can be identified and developed.

[0051] The above objectives are initially used to identify the kind / type of synthetic datasets to be generated. The identified composition of the dataset is then linked to appropriate data types that will be effective for automatic generation, also easy to parse and process. The data types are also decided based on the nature of the tools or services used to generate them. It is considered that the following can be necessary for building the dataset:

[0052] (1) A diverse collection of 3D conceptual architectural volumetric blocks (meshes) that can represent any conceivable conceptual volumetric block. 3D geometries are generated (e.g., using any conceptual architectural volumetric block generator) and compiled in the form of meshes with *.obj format. Figure 1A An exemplary 3D geometry mesh is shown in accordance with one or more embodiments of the present application.

[0053] (2) Associated energy models (gbxml) of these conceptual architectural volumetric blocks (e.g., using an intrinsic energy model fabricator). Figure 1B An associated analytical model for each of the meshes created using default energy settings as a base scheme is shown compiled in the form of a gbxml file.

[0054] (3) Energy simulation results (i.e., energy usage results) of these energy models (publish full building energy simulation (FBES)) (e.g., using automated simulator and result extractor). In an exemplary embodiment, the analysis model is sent to a simulator (e.g., AUTODESK GREEN BUILDING STUDIO simulator), where simulation results are saved and compiled in a CSV (comma separated value) file.

[0055] Once the requirements are established, the next step is to identify the overall workflow that combines several individual sub-workflows to generate and compile the identified data in the required format. The sub-workflows here are individual methods to generate each of the required data types or interface between different tools / services to do so.

[0056] Workflow development

[0057] Figure 2 An overall workflow for performing building energy analysis according to one or more embodiments of the present application is shown. The overall workflow 200 begins with a mass generation workflow 202 that contains several sub-workflows (as discussed in later sections) to generate a variety of masses. This stage utilizes the capabilities of generative design (e.g., AUTODESK GENERATIVE DESIGN for REVIT, also known as refine / refine learn 203 in REVIT) to generate geometric masses. The generated masses are then converted to (REVIT MASS) family instances 205. Figure 2

[0058] In the analysis model generation workflow 204, the mass family instances 205 are converted to analysis models (i.e., exported as GMXML files 209) with various energy settings 207 (e.g., default energy settings extracted from the REVIT application).

[0059] In the cloud simulation workflow 206, a cloud simulation engine (e.g., AUTODESK GREEN BUILDING STUDIO (GBS) simulator) is used to calculate the energy usage of the generated geometric structures. The analysis models of the masses are pushed to the simulator for energy simulation, and in the workflow 208, the results are retrieved to form a complete synthetic output dataset 210. This process is explained in detail below.

[0060] Considering the future flexibility of the workflow 200, the different parts of the workflow are broken down into modular parts, which in the future can be plugged in with other modules to perform several learnings. This will ensure the flexibility and reusability of the workflow 200 as a whole is broken into parts for future research and learning.​

[0061] Block generation workflow 202

[0062] Block generation workflow 202 includes a systematic approach for generating blocks, the aim of which is to generate an all-encompassing sample set of conceptual blocks. The initial step in developing this workflow 202 is to identify the variety of geometric types to be generated. To perform this step, initial research is done to identify the primary types / details of target geometries for the given problem at hand. Figure 3 The interrelation between a given building and a block is shown in accordance with one or more embodiments of the present application. As shown, any given building 302 has a correlation to a conceptual stage block 304 / associated thermal model of a given intervention stage (early stage design). Any building 302 can be represented as a simple block 304 at its early stage of design and for its thermal model.

[0063] In embodiments of the present application, it can also be necessary to establish how diversity can be maintained to ensure robust training and avoid repetition of geometric forms to ensure a fair training dataset. To achieve this, target geometric forms can be classified into categories on the following two lines: footprint (X and Y axes) and block (Z axis). This classification will make the development of the generator algorithm simpler by the divide and conquer approach.

[0064] In light of the target diversity, the geometries to be generated can be classified at the footprint and block level. Figure 4 Classification at the footprint level is shown in accordance with one or more embodiments of the present application. As shown, the footprint 400 is classified into convex geometries 402 and concave geometries 404. The convex geometries are further classified into circle inscribed polygons 406 and non-circle inscribed polygons 408. The concave geometries 404 are further classified into orthogonal 410 and non-orthogonal 412 geometry types.

[0065] Figure 5 Classification at the block level is shown in accordance with one or more embodiments of the present application. As shown, the block geometry types 500 are classified into convex geometries 502 and concave geometries 504. The convex geometry blocks are further classified into simple extrusions 506 and variable extrusions (towers) 508. The variable extrusions (towers) 508 are further classified into aligned 510 and misaligned 512, which can be consistent 514 or inconsistent 516. The concave geometries 504 can be further classified into simple extrusions 518, or variable extrusions (generic) 520, which can be consistent 522 or inconsistent 524.

[0066] Figure 4 and Figure 5The classification shown in FIG. 6 was developed based on trial and error testing. Additionally, twenty-five (25) random 3D blocks were manually tested and identified that they all fell into one of the above categories. Thus, this presents that any 3D conceptual block can be represented with these categories. Once the category is decided, each of the categories can be algorithmically broken down into a generator sub-workflow. These sub-workflows each generate simple geometric structures related to the specific category.

[0067] Non-circularly inscribed polygon convex geometry sub-workflow

[0068] Figure 6 A logical flow for generating a convex geometry of a circularly inscribed polygon is shown in accordance with one or more embodiments of the application.

[0069] In the first step, an occupancy area guide circle 602 is generated. The radius and position of this circle 602 are parameter variables. These variables in turn determine the position and scale of the overall generated geometry.

[0070] The guide circle 602 is then divided into a number of "separations" 604, which depend on user input. The separations 604 determine the total number of vertices of the geometry - the larger the number, the more vertices the geometry has, which means it can range from a curved geometry to a jagged geometry. The divided circle 606 shows the guide circle 602 with the separations 604.

[0071] A user input value called vertex density 608 determines what percentage of the separations 604 are selected as vertices. A double layer for determining the number of vertices will prevent inconsistencies and monotony in the generated geometry. Just like the separations 604, the vertex density 608 determines the total number of vertices of the geometry - the larger the number, the more vertices the geometry has, which means it can range from a curved geometry to a jagged geometry. In one or more embodiments, the vertex density 608 is a number between 0 and 1, where 0 means no points are selected and 1 means all points are selected. The circle 610 shows the divided circle 606 with vertices 612 having been selected based on the vertex density 608.

[0072] With these vertices 612, the convex hull 614 of these points gives the final output occupancy area for this category. Additionally, it should be noted that the variables (separations 604, vertex density 608) can be randomized (as part of an automated workflow) to generate many different options. Furthermore, the generative seed 616 variable produces a new value (e.g. randomized) for each iteration of generating a circularly inscribed convex geometry / polygon.

[0073] Non-circularly inscribed polygon convex geometry sub-workflow

[0074] Figure 7A logic flow for generating a non-circular inscribed convex polygonal geometry is shown in accordance with one or more embodiments of the application.

[0075] Instead of Figure 6 The point grid 702 is used for this purpose. It has x distance 704 and y distance 706 variables that determine the number of points in the X and Y directions of the grid 702. A grid point gap variable 708 determines the gap between points in the grid 710. These three variables 704-708 together determine the overall scale and aspect ratio of the output volume that is generated.

[0076] A user input value called vertex density 712 determines what percentage of the grid points are selected as vertices 714. In other words, the vertex density 710 determines the total number of vertices of the geometry - the larger the number, the more vertices the geometry has, which means it can range from a curved geometry to a jagged geometry.

[0077] With these vertices 714, the convex hull of these points gives the final output footprint 716 for this category. Similar to Figure 6 As described for the inscribed polygon, the variables (x distance 704, y distance 706, grid point gap 708, and vertex density 712) can be randomized (as part of an automated workflow) to generate many different options. In addition, the generative seed 718 variable produces a new value (e.g., randomized) for each iteration of generating a non-circular inscribed convex geometry / polygon.

[0078] Orthogonal polygon concave geometry sub-workflow

[0079] Figure 8 A logic flow for generating an orthogonal concave polygon is shown in accordance with one or more embodiments of the application.

[0080] The point grid 802 has x size 804 and y size 806 variables that determine the number of points in the X and Y directions of the grid 802. A grid point gap 808 variable determines the gap between points in the grid 802. These three variables 804-808 together determine the overall scale and aspect ratio of the output volume that is generated (as reflected in the full grid 810).

[0081] A user input value called vertex density 812 determines what percentage of the grid points are selected as vertices. Thus, the vertex density 812 determines the total number of vertices of the geometry - the larger the number, the more vertices the geometry has, which means it can range from a curved concave geometry to a jagged concave geometry. The selected vertices (e.g., a new set of vertices can be selected each iteration based on a generative seed 816 that can randomize the variable values) are shown as vertices 814.

[0082] With these vertices 814 in place, the convex hull 818 of the points gives the base convex polygon footprint for the class.

[0083] With the base convex polygon footprint in place, a method called Manhattanization 820 is used to generate the concave polygons. The Manhattanization process 820 is as follows:

[0084] The iterative procedure starts at the first vertex 814 of the base convex geometry and traverses from one vertex 814 to the next.

[0085] The process checks if the next immediate vertex is displaced linearly or obliquely. If it is linear, the process proceeds to the next vertex 814. If not, an additional "Manhattan point" 822 is added, which is the point of intersection of the linear extension of the current point and the next point. This joins the current point with the next point in an orthogonal fashion, rather than an oblique / tilted fashion.

[0086] Once all Manhattan points 822 are added, all points (814 and 820) are joined together with a closed polygonal curve.

[0087] In addition to Manhattanization 820, two additional helper functions (conditional selection 824 and volume selection 826) can be added to ensure that there are no backtracking lines (repeating Manhattan points as two points can have the same Manhattan point 822) and also to ensure that the concave shapes of interest are generated (monotony is avoided by selecting the generated geometries of interest alternatives, and redundant / repetitive geometries [e.g. boxes / rectangles] are avoided).

[0088] As a result of the above steps, the final footprint 828 for the class is generated.

[0089] Non-orthogonal polygonal concave geometry sub-workflow

[0090] Figure 9 A logical flow for generating non-orthogonal concave geometries is shown in accordance with one or more embodiments of the application. Such non-orthogonal concave geometries can be added to enhance the overall geometric diversity of the dataset, as these geometries are complex geometries when they can not look like actual building forms, which will improve the training process of the target surrogate model, and make the geometry dataset healthy and all-inclusive. They can be deleted or modified as needed.

[0091] An occupancy area guide circle 902 is added. The radius and position of this circle 902 are parameter variables. These variables determine the position and scale of the overall generated geometry.

[0092] The guide circle 902 is then divided into a number of "separations" 904 (resulting in divided circles 906) that depend on user input. The separations 904 determine the total number of vertices of the geometry - the greater the number, the more vertices of the geometry, which means it can range from a curved geometry to a jagged geometry.

[0093] A user input value called vertex density 908 determines what percentage of the separations are selected as selected vertices 910. The dual layer for determining the number of selected vertices 910 will prevent the generated geometry from being inconsistent and monotonous. Like the separations 904, the vertex density 908 determines the total number of vertices of the geometry - the greater the number, the more vertices of the geometry, which means it can range from a curved geometry to a jagged geometry.

[0094] Once the selected vertices 910 are randomly selected based on the input vertex density 908 (e.g., based on a randomly generated value per iteration through the generative seed 912), a new user input variable called subpoint density 914 determines what percentage of these selected vertices 910 should extrapolate to subpoints 916. The subpoints 916 are extrapolations of the vertices to the interior of the guide circle 902.

[0095] Once the subpoints / extrapolations 916 are determined, a final variable called subpoint parameter 918 determines how many subpoints 916 to extrapolate from the parent vertex. It is a value ranging from 0 to 1, 0 being the vertex itself, and 1 being the center of the circle 902. The final resulting subpoints / extrapolations 916 in their extrapolated positions are shown in circle 920.

[0096] Through all the vertices 910 and subpoints 916, a polygonal curve is drawn (e.g., via interpolation) to generate the final footprint 922 for that category. As Figure 9 shown, various different footprints 922A and 922B can be interpolated / generated by randomly selecting one footprint 922A as the final footprint 922.

[0097] Generative design versus body block generator interfacing

[0098] In combination with the above, each category has an algorithm for generating the geometry using generator variables (which are used to generate the seed for each iteration) and modifier variables (i.e., which modify the geometry itself). In this way, a synthetic dataset can be made generative (e.g., it intelligently manipulates the variables to satisfy certain objective functions) by using generative design techniques. Thus, generative design products within (e.g., AUTODESK GENERATIVE DESIGN within the REVIT application, in Figure 2Different solvers, also referred to as refiners 203), can be used to produce synthetic datasets for different use cases. In this regard, it is an objective of embodiments of the present application to leverage the power of generative design to generate body blocks and control the types of body blocks that the body blocks generate. To this end, it is important to ensure that the body block generator sub-workflow described above works with the formats that the generative design application accepts. In this way, the body block generator algorithm can work in concert with the powerful capabilities of the generative design application to not only generate random geometry samples, but also have powerful control over them to tailor the generated geometry to specific needs and typologies.

[0099] To provide this capability, the framework shown in FIG. 1 is used. More specifically, Figure 10 Figure 10 A framework for generating synthetic data using a generative design application according to one or more embodiments of the present application is shown. Different variables of the body block generator 1000 sub-workflow are developed in the way they are used for one of the following two functions:

[0100] The modifier 1002

[0101] The generator 1004

[0102] The modifier 1002 is those variables that change the properties and shape of the geometry and set up the "base scheme" for generation (i.e., used by the fitness function 1006 within the generative design application 1008). The generator 1004 is those variables that change the base scheme geometry into different samples and generate new (but same category) geometry 1020 (i.e., can be used to see each iteration 1010 of the category sub-workflow). The generator 1004 can use one of four functions (e.g., randomize 1012, cross product 1014, analog 1016, and optimize 1018) to manipulate, which the generative design application 1006 can provide to control the geometry generation for specific tasks and pipelines. Different functions of the generative design 1006 can be used for different purposes to generate datasets that are tailored to the goals of the functions.

[0103] Figure 11 An exemplary re-usable synthetic dataset geometry structure generated using a random function according to one or more embodiments of the present application is shown. Figure 12 An exemplary combinatorial analysis / feature search dataset geometry structure generated using a random cross product function according to one or more embodiments of the present application is shown. Figure 13 An exemplary form finding / sensitivity analysis dataset geometry structure (i.e., finding / locating geometry similar to a selected geometry 1302) generated using an analog function according to one or more embodiments of the present application is shown.

[0104] Root system model generation​

[0105] With the goal of automating the analytical model generation workflow, it is necessary to understand the general process of conceptual energy analysis using energy analysis applications (e.g., REVIT applications and GREEN BUILDING STUDIO applications). This process can then be scaled and automated (e.g., using DYNAMO visual programming applications). Figure 14 Exemplary views of geometry during the overall process of one conversion of a body block to an analytical model are shown in accordance with one or more embodiments of the application. Figure 15 A logic flow for the overall process of conversion of a body block to an analytical model is shown in accordance with one or more embodiments of the application. Generally, any generated body block 1402 must be converted to a body block family instance 1404, then to an analytical model 1406 (e.g., an energy model based on default energy settings) to run simulations using a simulation application 1502 (e.g., providing the model to the simulation application 1502 via an application API). The simulation application / engine can perform many times in the cloud (e.g., a base run + 247 optional runs). The output from the simulation application / engine provides simulation results 1408 (which can include a combination of gbxml files generated for each run).

[0106] In attempting to create a modular workflow for automating this entire process, embodiments of the application provide the ability to handle a variety of issues including:

[0107] - handling large amounts of data;

[0108] - the need for automated submission of analyses;

[0109] - the need for the analytical model generation workflow to work in a modular fashion and in cooperation with the body block generation workflow;

[0110] - the difficulty of sending multiple analytical models to a simulation application for local simulations from an API (e.g., an API of a REVIT application);

[0111] - the obsoleted API and documentation invalidates the possibility of committing specifics;

[0112] - there is no ability to allow parametric control of energy setting variables; and

[0113] - finding a way to retrieve a large number of results from a simulation application.

[0114] To address these issues, one or more of the following strategies can be utilized:

[0115] Instead of geometry modification by geometry, embodiments of the present application provide for emptying / exporting geometry / volume block generator workflows from one process (e.g., local emptying as a 3D geometry file such as a spatial ACIS model [*.sat] file) for later use and modifying the geometry in another process (e.g., reading and converting to an energy model [gbxml]). In other words, the 3D geometry file is exported for training data sets and as input to the analysis generation workflow. One reason for breaking the volume block generation and analysis model generation workflows apart is the fact that generative design applications (e.g., the REFINERY application) can not support the Computer Aided Design (CAD) application (e.g., the REVIT application) API macros in the background. Therefore, the workflows should have different driving mechanisms. The current workflow reads a spatial ACIS file (*.sat) from a local emptying directory and makes it a solid geometry. To produce an analysis volume block model for simulation, embodiments can require that the solid block be an in-place volume block or volume block family instance 1404. Therefore, embodiments of the present application produce a volume block family instance 1404 from a solid geometry (i.e., a 3D volume block 1402).

[0116] In conjunction with the above, embodiments of the present application can utilize two user inputs: (1) a ground floor; and (2) a floor height, which together reach the overall height of the volume block geometry (e.g., volume block family instance 1404). The workflow can also create stories (height value) with these inputs and create stories through these sequences of height values. With the volume block and stories combined, an analysis model 1406 can be made with various energy settings. The workflow is constructed to then export the locally currently generated analysis model's gbxml file (e.g., to the simulation application 1502). A flow gate can also be set to allow / restrict the export of gbxml so that the workflow can test the workflow without emptying data.

[0117] A simple console application sends a batch of these gbxml files to the simulator 1502 for simulation, where the run ID of each of these exported gbxml files is noted. The console application can mimic the simulator submission process using a simple HTTP Post protocol without using specific APIs (application programming interfaces). This directly materializes the submission process and also allows for parametric control of energy setting variables. The results are directly retrieved from the server bucket by cross-referencing the saved run IDs.

[0118] In addition to the above, embodiments of the invention can be implemented as / considered a node framework, where each sub-workflow flows from one node and can be used in a modular fashion as a combination of several other nodes. In other words, generative design can be used to generate synthetic datasets that resemble real data in an efficient and effective manner. Specifically, the representative diverse geometrical structures can be classified (into several categories) with individual algorithms (per category) that are used to actually generate the geometrical structure data (within each category).

[0119] Low variability in EUI (driven by low variability in geometries)

[0120] Using the above methodology, the variability in the simulated EUI for the phase 1 synthetic geometries can be very small (standard deviation 42 vs. mean 455). Using just the mean EUI of the training set as the predicted EUI in the test (without any predictors) results in just a 4% prediction error (MAPE - mean absolute percentage error). Artificial neural network and random forest models almost perfectly explain this small variability in EUI - their prediction error in terms of MAPE on the test set is just 0.32% and 0.28% respectively. Even linear regression results in just about 1% MAPE (MAPE). While the error rate is computed on the test set (which contains only geometries that were not used in training), a review of the geometries (form, size, height, and other geometrical features ranges and variability) suggests that the synthetic geometries used do not represent a realistic range of office buildings. Thus, while the trained surrogate model gets very small prediction error on the test, it is highly unlikely that it would perform at the same level on a customer's building model that can have vastly different geometrical properties. In other words, the low prediction error is primarily due to the low variability in the simulated EUI (caused by the low variability in the geometries).

[0121] To overcome the low variability in the simulated EUI, a review of office buildings in the United States (mainly in the San Francisco Bay Area) was conducted, form and size ranges were archived, and these archived form and size ranges were used as a guide for generating new cuboids. Based on this review, embodiments of the invention ensure that the new dataset includes buildings with setback distances / cantilevers and different elongations. The new geometries result in greater variability in the simulated EUI (standard deviation 231 vs. mean 673). Using just the mean EUI of the training set as the predicted EUI in the test set results in a much larger MAPE (13.7%). But after including predictors in the model, the prediction error drops substantially. While the prediction error (in terms of MAPE) is larger than the model built on phase 1 data (4.1% vs. 0.3%), the difference between the base model (just the mean) and the full model (model with all predictors) increases significantly.

[0122] Using only Manhattanized geometries

[0123] In generating the new set of synthetic geometries, embodiments of the present invention primarily focus on increasing variability in elongation, size, height of buildings, and including setback distances and overhangs, and unlike other embodiments, no convex non-Manhattanized geometries are initially created. However, approximately 100 convex non-Manhattanized geometries are later created (approximately 15% of the total number of initial geometries) and their simulated EUIs are run in the simulator (base run and 247 optional runs). A series of tests are run to check whether it is necessary to include non-Manhattanized geometries into the training set. Additionally, the model is trained using only Manhattanized geometries, and the model is tested against the Manhattanized, non-Manhattanized, and combined test sets. The model is executed almost equally on the three different sets, suggesting that training the model on only Manhattanized geometries would be sufficient (it is expected that such a model would predict the EUI of non-Manhattanized geometries with the same level of accuracy as for Manhattanized geometries).

[0124] High multicollinearity and feature selection

[0125] In embodiments of the present invention, no explicit feature selection process can be employed in Stage 1, and in fact, all initial features can be included in the surrogate model). However, examining the pairwise correlations and the Variance Inflation Factor (VIF) indicates high multicollinearity among the predictors. More specifically, the pairwise correlations among the geometry features indicate that some features are 100% correlated. While multicollinearity does not affect model performance (prediction accuracy) in neural networks, it can slow down the training process substantially by: (1) making the neural network graph larger (increasing the number of input nodes and thus the number of connecting edges); and (2) requiring a larger number of iterations (epochs), which is needed to minimize the MAPE on the validation set.

[0126] To improve on this problem, embodiments of the present application provide for discarding one feature from each highly correlated pair (about 80%). Features with high VIF values are removed one at a time (stepwise), and the VIF is recalculated until all VIF values are below 5 (5 and 10 are commonly used rules of thumb as indicators of multicollinearity, with 5 being the more conservative choice). Linear regression can then be fit to test the statistical significance of all remaining features. The results demonstrate that all remaining features are originally statistically significant (and thus expected to contribute to model prediction accuracy). Thus, instead of basing feature selection on the p-value of the coefficient estimates from linear regression, embodiments of the present application can utilize a permutation method; that is, the values in a feature are randomly permuted (one feature at a time), the model is trained and tested, and the prediction accuracy (on the test set or on cross-validation test sets) is compared against the full model as a measure of the importance of the feature: a drop in prediction accuracy due to permuting the values in a feature indicates the size of the contribution of the feature to model accuracy. However, for this method, some embodiments cannot use this method due to the computational time that should be considered for training and testing the model for each feature and each of the large number of features.

[0127] Oriented features

[0128] In one or more embodiments, in Stage 1, orientation is captured by wall areas facing eight (8) directions (north, east, south, west, and 45 degree directions between these cardinal directions). This orientation is arbitrary and the values are automatically generated by the simulator. However, these features are limiting in the case of more complex forms, even in simple geometries that are not aligned with these cardinal directions. They also tend to be highly correlated with each other (e.g., in a typical rectangular shape, the north and south wall areas would be the same) and with the total facade area (the south wall area would be larger for larger buildings with larger total surface area). In this way, expressing orientation as wall areas facing a certain direction does not give the model much added information.

[0129] To provide additional information to the model and improve accuracy, embodiments of the present application provide the ability to express orientation as projected areas towards two cardinal directions (south and east) and as a ratio to the total area. Using a ratio to the total eliminates correlation with the total area and expresses orientation purely independent of the size of the building. Thus, even if the building is rotated, embodiments of the present application will still be able to capture relevant information (e.g., if a larger building has a larger area facing south, the projection provides the ability to capture how much of the south / north facing area the building has). In this regard, the ratio of the area facing a certain direction to the total area is used, rather than just using the area facing a certain direction as the total area. With the ratio, the size of the building is not a concern and de-correlation of the features is achieved, improving model accuracy.

[0130] Figure 16 A process for expressing orientation as projected area and ratios is shown, in accordance with one or more embodiments of the application.

[0131] At step 1602, a minimum bounding box is created that is aligned with the north and east directions. Figure 17 A bounding box 1702 is shown that bounds a building 1704.

[0132] At step 1604, the area of the south and east facing surfaces of this bounding box 1702 is calculated:

[0133] East facing projected area = L AB x H

[0134] South facing projected area = L BC x H

[0135] At step 1606, the east facing and south facing indicators are calculated by dividing the above values by the total facade area of the building:

[0136] East facing indicator = L AB x H / Total facade area

[0137] South facing indicator = L BC x H / Total facade area

[0138] This can be extended to the case of a building with varying profiles at different heights, by repeating step 1604 separately for each floor (where H will be the height of the individual floor) and dividing by the total facade area. Figure 18 Exemplary bounding boxes 1802 and 1804 are shown, in accordance with one or more embodiments of the application, for each of two building levels 1806 and 1808, respectively. Step 1606 provides the following calculation of the east facing indicator:

[0139] East facing indicator = (L AB x H1 + L A'B' x H2) / Total facade area

[0140] Estimate EUI vs. Simulate EUIs

[0141] For each base run, the simulator (e.g., the AUTODESK GREEN BUILDING STUDIO simulator) can generate 247 optional runs by changing one setting at a time (e.g., changing only the glass properties or the ratio of windows to walls of the base run). The building performance analysis software (e.g., the AUTODESK INSIGHT application) can generate many random scenarios for each base run by combining multiple simulated optional runs (i.e., scenarios where multiple properties are different from the base run). The performance analysis software can then estimate the EUI for those random combinations based on the simulated EUI of the base and 247 optional runs. The estimation is based only on the energy saved or lost in each optional run and sums the energy losses and savings for each scenario (each scenario is a combination of multiple optional runs, each scenario results in energy savings or losses).

[0142] Ideally, the building performance software's estimated EUI for a combination should be the same as the simulated EUI for that combination. Thus, if the model is trained only on the estimated EUI and tested with simulated data, one would expect the prediction accuracy not to deviate significantly from when both the training and testing are performed on building performance analysis data. However, the testing shows a significant difference between the levels of prediction accuracy in these two cases. Moreover, the reverse testing where the model is trained on simulation results and predicts on analysis software data results in considerable prediction error.

[0143] To overcome this problem, embodiments of the present invention generate random combinations of energy settings and use only the actual simulated EUI.

[0144] Data processing using data frames

[0145] The data processing can constitute a two-step process, where each step is potentially performed in a separate code / function (or via a single code).

[0146] The first step takes three inputs:

[0147] (1) a csv file with the geometric features;

[0148] (2) a csv file from the simulator with all the runs, with the simulated EUI and the run ID (corresponding to the building / geometry) and the run's title (e.g., the name of the optional run); and

[0149] (3) a constant csv file that shows for each optional run (represented by the run's title) which features are changed and provides the new value for that feature for that run; this file is constant across all climate zones.

[0150] The process produces a data frame of 248 rows with valid geometries (those with base run and at least 238 successful runs of EUI), with energy settings and geometry feature values for each case. Base run values are hardcoded (constant) and optional run values come from a constant csv file. This data frame is used to produce the three (3) main outputs of Step 1 : (1) a csv file with all cases with valid EUIs with all features for the model. The names of the geometries and optional runs are also kept in this output as they will be used later during the training and testing phases. This dataset will be used to train the model based on simulated EUIs only; (2) two other csv files that will be used as inputs to the building analysis software; and (3) the final processed geometry features is another csv output that is used in Step 2 and will be joined with the building analysis software output (this is done to avoid repeating the calculation of geometry properties in Step 2).

[0151] The second step gets the building analysis software output (randomized combinations of energy settings with estimated EUIs), finds the cases that were affected by failed optional runs and deletes them, and joins the final geometry features. The resulting output will be used to train the model based on estimated EUIs only.

[0152] Stage 2

[0153] Once the synthetic data has been generated in Stage 1 above, Stage 2 provides the ability to generate an alternative model (based on the synthetic data) that replaces the existing state-of-the-art execution of simulations for proposed designs. The alternative model can then be used to facilitate the process of obtaining a design for a particular geometry. In one or more exemplary embodiments in energy analysis, the alternative model can be used to create a real-time energy prediction service, reducing the time and computation of state-of-the-art simulations, and facilitating the integration of energy evaluation in a geometry modeling environment.

[0154] Alternative model creation

[0155] Described herein are exemplary alternative models for energy use intensity (EUI) analysis. However, embodiments of the invention are not limited to energy use intensity analysis and can be used in various other use cases (see applications / fields described below).

[0156] Figure 19 shows a logical flow for an example energy use intensity analysis according to the prior art. To compute EUI cost 1900, inputs can include building geometry 1902 in a particular location 1904, and values for the following parameters: window-to-wall ratio (WWR) 1906, north-south-east-west shading 1908, north-south-east-west window glazing 1910, wall construction 1912, roof construction 1914, infiltration rate 1916, lighting efficiency 1918, plug load efficiency 1920, occupancy rate 1922, and HVAC system 1924. Computation 1926 then evaluates EUI 1900 based on those inputs 1902-1924. Once the user submits geometry 1902, embodiments of the present invention can use a simulator (e.g., AUTODESK GREEN BUILDING STUDIO (GBS)) to run 248 simulations 1930 with predetermined parameter values 1928. Once the simulations are complete, a statistical regression method 1932 (e.g., using a regression model) can be used to predict EUI 1900 for any parameter values that the user can define.

[0157] The current bottleneck in this process is the set of 248 computationally intensive simulations 1930 that need to be run whenever a new geometry is submitted. This makes it possible to use certain prior art applications for geometry exploration in the early design phase, but it makes it impractical to use for optimal building parameter selection in later design phases.

[0158] Accordingly, embodiments of the present invention develop a surrogate model to replace the computationally expensive simulations 1930, where the focus is on accounting for geometry variability. Figure 20 A logical flow for an example energy use intensity analysis based on a surrogate model 1702 according to embodiments of the present invention is shown. Figure 21 Another view for an example energy use intensity analysis according to one or more embodiments of the present invention is shown. As shown, different climate zones 2102 and building properties 2104 (e.g., which can include the properties described with respect to Figure 19) are combined with building block geometry 2106 to be evaluated by surrogate model 2002.

[0159] Data

[0160] The dataset used to test embodiments of the present invention contains 862 building geometries. In the single-zone subset of the dataset, all buildings are assigned to the same location (i.e., Boston, climate zone 5A). In the multi-zone subset of the dataset, each building is assigned to one of five possible locations (climate zones 1A, 3B, 4B, 5A, 8).

[0161] Figure 22An exemplary process for compiling datasets according to one or more embodiments of the application is shown. A list of 248 variations is generated for buildings 2202 and 2204, and results (EUI) are retrieved (e.g., from a simulation application). For a detailed description of this process, see Stage 1 above. The simulation results exist in two formats: (i) a single.csv file 2202 containing all buildings and all variations (862 buildings * 248 simulation runs) (i.e., parameter information (with variations) and simulation results 2206). The column named "header" indicates what building parameter value was used for each simulation run; and (ii) one.gbxml file 2204 for each of the 248 runs (i.e., with geometry & analysis model information, parameter information, and simulation results 2208).

[0162] As shown, the dataset of 862 base runs 2210 (single zone buildings 2212 [i.e., 1 building volume in 1 location]) is used with the gbxml-extracted geometry-defined feature set (i.e., geometry and analysis model 2214 from the gbxml 2216 generated from the BIM application) to represent the geometry 2218 (i.e., via the mesh 2220).

[0163] The first output of the 248 simulation runs is the base run. If the building parameters are not explicitly defined prior to submitting the geometry 2218 to the simulator (which can occur during the data generation process), the simulator determines the values of these (base run) parameters 2222 based on default settings (i.e., tables with default values 2224). Thus, to determine the values of all building parameters for the base run, two sources can need to be accessed: (1) the building geometry 2218, for identifying WWR 1906 and shading 1908, and (2) the simulator default values 2224, for identifying all other parameters. The default values 2224 can be a function of climate zone, building zone, and number of floors, and can be encoded in various tables.

[0164] To generate the correct parameter set for each of the remaining 247 runs, a dictionary and parsing method that matches the header of the simulation run to the corresponding parameter values can be generated.

[0165] After trial-and-error experimentation, the various embodiments of the application utilize / select fifteen (15) features: • Number of floors (integer value of total number of floors)

[0166] • Envelope area to volume (ratio of envelope area to total volume of the volume)

[0167] • Total floor area to volume (constant, unless floor-to-ceiling height varies)

[0168] • Envelope area to floor area

[0169] • Total roof area

[0170] • Total interior floor area (sum of all floor panel areas)

[0171] • Total slope panel area

[0172] • North wall area (projected area facing north)

[0173] • South wall area (projected area facing south)

[0174] • East wall area (projected area facing east)

[0175] • West wall area (projected area facing west)

[0176] • Northeast wall area (projected area facing northeast)

[0177] • Northwest wall area (projected area facing northwest)

[0178] • Southeast wall area (projected area facing southeast)

[0179] • Southwest wall area (projected area facing southwest)

[0180] Additional features can include:

[0181] • Roof max height (highest Z value of horizontal surfaces, e.g. number of floors * floor height)

[0182] • Total envelope area (total area of all exposed surfaces in the envelope)

[0183] • Envelope area to volume (ratio of envelope area to total volume of the block)

[0184] • Total exterior wall area (excluding windows)

[0185] • Wall area WO windows (total vertical surface area (window area + opaque wall area)

[0186] • Total exposed roof area (total area of exposed horizontal surfaces)

[0187] • Occupiable area (area at the lowest occupiable area - not projected occupiable area)

[0188] • Occupiable area perimeter (area at the lowest occupiable area - note that it is projected occupiable area)

[0189] • Total volume (total volume of the solid block)

[0190] • Total window area (WWR * wall area (total surface area of all window surfaces))

[0191] The python gbxml parsing module is used to extract these features from the generated gbxml file 2204.

[0192] Next, two alternative approaches for surrogate model integration in the energy prediction system are compared. The comparison is made for a single climate zone (5A).

[0193] Referring again to Figure 20 In the first option, the surrogate model 2002 directly replaces the simulator. This means that for every change in geometry, the system will get 248 predictions from the surrogate model and use them together with the statistical analysis / method 1932 (e.g. INSIGHT statistical regression model) to calculate the EUI 1900 with the specified building parameters.

[0194] In the second exemplary embodiment, a surrogate model 2002 is used that can directly predict the EUI 1900 for any combination of parameters. To better train this model, an interpolation model (also referred to as INSIGHT interpolation and / or INSIGHT statistical regression model) can be used that can produce an augmented version of the dataset. The augmented dataset does not contain 248 predetermined parameter variations per building as before. Instead, a required number of random parameter combinations per building can be sampled with the help of this interpolation model.

[0195] The augmented dataset with 1000 samples per geometry is used to train a neural net that achieves an error of 1.4% in EUI prediction. To compare the performance of the two alternative workflows, the final error of the first workflow is calculated by comparing the interpolation model results using 248 EUI ground truth values on the one hand and 248 predicted EUI values for random parameter combinations on the other hand. The final error of the first workflow is calculated to be 1.33%. Finally, the second workflow is mainly chosen for the argument of reducing the computational and complexity of the inference process while adding it during data preparation and model training. Finally, the multi-zone data 862 is augmented with 2000 random parameter combinations and a single neural net that achieves an error of 1.91% for 5 climate zones.

[0196] Prototype

[0197] Prototypes of various embodiments of the invention were implemented and demonstrated real-time EUI prediction in the DYNAMO visual programming application. The HTTP client communicates with a (PYTHON) server where the actual prediction takes place. Alternatively, various embodiments also replace the service with an AWS lambda function. Feature extraction is provided by a first conversion geometry conversion to gbxml format. Alternatively, feature extraction can be performed with another parser that extracts features (wall area, floor area, volume, etc.) directly from the geometry.

[0198] LOGICAL FLOW

[0199] In conjunction with the above, Figure 23 A logical flow for generating and using building operational performance analysis output according to one or more embodiments of the invention is shown.

[0200] At step 2302, a synthetic dataset is generated. The synthetic dataset includes a collection of three-dimensional (3D) building conceptualized block geometry. The generation of the synthetic dataset includes identifying two or more geometry types, partitioning the two or more geometry types into classes at an occupancy area level and at a block level, and algorithmically generating 3D building conceptualized block geometry using a separate workflow for each class (where algorithmically generating utilizes generative design). The identification of the geometry types can include performing correlation learning. Such correlation learning can include utilizing a set of features that substantially includes: number of floors, (roof max height - optional), enclosed area to volume, total floor area to volume, enclosed area to floor area, (total exterior wall area - optional), total roof area, total interior floor area, total slope slab area, north wall area, south wall area, east wall area, west wall area, northeast wall area, northwest wall area, southeast wall area, and southwest wall area.

[0201] Alternatively or in addition to the above, the correlation learning can include utilizing a set of features where the set of features expresses orientation as a ratio of projected area to two directions and as a ratio to total area.

[0202] As described above, the partitioning of the two or more geometry types at an occupancy area level can include partitioning the two or more geometry types into convex geometry and concave geometry, partitioning the convex geometry into circle inscribed polygon and non-circle inscribed polygon, and partitioning the concave geometry into orthogonal polygon and non-orthogonal polygon.

[0203] A workflow for convex geometry circle-inscribed polygons can include generating an area-occupancy guide circle (which determines the location and scale of the convex geometry circle-inscribed polygon), dividing the area-occupancy guide circle into partitions (where the partitions determine the number of vertices of the convex geometry circle-inscribed polygon), determining a vertex density that defines a percentage of the partitions to use as vertices, and generating (based on the partitions and the vertex density) a convex hull that represents the area-occupancy of the convex geometry circle-inscribed polygon.

[0204] A workflow for convex geometry non-circle-inscribed polygons can include generating a point grid (which has a defined number of grid points in an X direction and a Y direction), where the point grid determines the scale and aspect ratio of the convex geometry non-circle-inscribed polygon. Thereafter, a vertex density is determined that defines a percentage of the grid points to use as vertices. Based on the point grid and the vertex density, a convex hull is generated that represents the area-occupancy of the convex geometry non-circle-inscribed polygon.

[0205] A workflow for concave geometry orthogonal polygons can include generating a point grid (which has a defined number of grid points in an X direction and a Y direction), where the point grid determines the scale and aspect ratio of the concave geometry orthogonal polygon. A vertex density is determined that defines a percentage of the grid points to use as vertices. Thereafter, based on the point grid and the vertex density, a convex hull is generated that represents a base area-occupancy of the concave geometry orthogonal polygon. The base area-occupancy is Manhattanized to generate the concave geometry orthogonal polygon. Manhattanization includes an iterative procedure that starts at a first vertex of the vertices in the base area-occupancy and iterates through the vertices. The iterative procedure checks whether a next immediate vertex of the vertices is linearly displaced or obliquely displaced. If linearly displaced, the iterative procedure proceeds to the next vertex. If obliquely displaced, the iterative procedure adds an additional Manhattan point that is an intersection of a linear extension of the current vertex and the next vertex. Once all Manhattan points are added, all points are joined together with a closed polygonal curve that is output as a final area-occupancy of the concave geometry orthogonal polygon.

[0206] A workflow for concave geometry non-orthogonal polygons can include generating an occupancy area guide circle that determines the location and scale of the concave geometry non-orthogonal polygon. The occupancy area guide circle is divided into partitions that determine the number of vertices of the concave geometry non-orthogonal polygon. A vertex density is determined that defines a percentage of the partitions to use as vertices. Thereafter, a sub-vertex density is determined that identifies / determines a percentage of the vertices to use as parent vertices that are extrapolated to the next points as sub-vertices. The sub-vertices include extensions of the parent vertices to the interior of the occupancy area guide circle. A sub-vertex parameter is determined that identifies / determines how far each sub-vertex extends from a parent vertex. Finally, a polygonal curve can be generated by joining the parent vertices and the sub-vertices together. This polygonal curve is used as the final occupancy area for the concave geometry non-orthogonal polygon.

[0207] Dividing two or more geometry types at the block level can include dividing the two or more geometry types into convex geometries and concave geometries, dividing the convex geometries into convex simple extrusions and convex variable extrusions, dividing the convex variable extrusions into aligned and non-aligned, dividing the non-aligned into consistent convex and inconsistent convex, dividing the concave geometries into concave simple extrusions and concave variable extrusions, and dividing the concave variable extrusions into consistent concave and inconsistent concave.

[0208] The individual workflow for each category can be based on one or more modifier variables that change the properties and shapes of the 3D building conceptualized block geometry and define a base scheme, and one or more generator variables that change the base scheme to different samples and generate new geometries in the same category. Further, generative design can create a synthetic dataset that can be reused using a random function, create a synthetic dataset based on a feature search using a cross product function, create a synthetic dataset based on a sensitivity analysis using a likeness function, and generate design alternatives for the synthetic dataset based on input design goals and parameters.

[0209] At step 2304, an analysis model associated with each of the 3D building conceptualized block geometries is generated. The analysis model generation can include exporting the 3D building conceptualized block geometries as 3D geometry files, producing a hierarchy sequence based on inputs where the inputs include a number of floors on the ground and a floor height, and generating the analysis models based on the 3D conceptualized block geometries and the inputs. Additionally, the analysis models can be trained with only Manhattanized geometries.

[0210] At step 2306, simulation results for each of the analysis models are generated by performing simulations based on each of the analysis models.

[0211] At step 2308, a surrogate model is trained using machine learning (ML) based on a set of features extracted from the simulation results. The ML iteratively determines the set of features based on measured accuracy of the surrogate model.

[0212] At step 2310, geometry input is received.

[0213] At step 2312, the geometry input is processed by the surrogate model to generate a building operational performance analysis output.

[0214] At step 2314, the building operational performance analysis output is used to inform designers of the approximate energy usage intensity of their current design. Designers can make model geometry and parameter changes, resubmit for analysis, and quickly see if their changes improve or worsen their design performance.

[0215] HARDWARE ENVIRONMENT

[0216] Figure 24 is an example hardware and software environment 2400 (referred to as a computer- implemented system and / or computer-implemented method) for implementing one or more embodiments of the present application. The hardware and software environment includes a computer 2402 and can include peripherals. The computer 2402 can be a user / client computer, a server computer, or can be a database computer. The computer 2402 includes a hardware processor 2404A and / or a special purpose hardware processor 2404B (hereinafter collectively referred to as processor 2404) and a memory 2406, such as random access memory (RAM). The computer 2402 can be coupled to other devices and / or integrated with other devices, including input / output (I / O) devices, such as a keyboard 2414, a cursor control device 2416, e.g., a mouse, a pointing device, a pen and tablet, a touch screen, a multi-touch device, etc., and a printer 2428. In one or more embodiments, the computer 2402 can be coupled to or can include a portable or media viewing / listening device 2432 (e.g., an MP3 player, an IPOD, a NOOK, a portable digital video player, a cellular device, a personal digital assistant, etc.). In yet another embodiment, the computer 2402 can include a multi-touch device, a mobile phone, a gaming system, an Internet-enabled television, a television set-top box, or other Internet-enabled device executing on various platforms and operating systems.

[0217] In one embodiment, the computer 2402 is operated by a hardware processor 2404A that executes instructions defined by a computer program 2410 (e.g., a computer-aided design [CAD] application) under control of an operating system 2408. The computer program 2410 and / or the operating system 2408 can be stored in the memory 2406 and can interface with a user and / or other devices to accept inputs and commands and to provide outputs and results based on such inputs and commands and the instructions defined by the computer program 2410 and the operating system 2408.

[0218] The outputs / results can be presented on a display 2422 or provided to another device for presentation or further processing or action. In one embodiment, the display 2422 includes a liquid crystal display (LCD) having a plurality of individually addressable liquid crystals. Alternatively, the display 2422 can include a light-emitting diode (LED) display having clusters of red, green, and blue diodes that are driven together to make full color pixels. Each liquid crystal or pixel of the display 2422 changes to an opaque or translucent state to form part of an image on the display in response to data or information generated by the processor 2404 applying the instructions of the computer program 2410 and / or the operating system 2408 to inputs and commands. The image can be provided through a graphical user interface (GUI) module 2418. Although the GUI module 2418 is depicted as a separate module, the instructions to perform the GUI functions can reside in or be distributed among the operating system 2408, the computer program 2410, or implemented with dedicated memory and processors.

[0219] In one or more embodiments, the display 2422 is integrated with / integrated into the computer 2402 and includes a multi-touch device (e.g., a trackpad or touchscreen) having a touch-sensing surface with the ability to recognize the presence of two or more points of contact with the surface. Examples of multi-touch devices include mobile devices (e.g., IPHONE, NEXUS S, DROID devices, etc.) tablet computers (e.g., IPAD, HP TOUCHPAD, SURFACE devices, etc.), portable / handheld gaming / music / video player / console devices (e.g., IPOD TOUCH, MP3 players, NINTENDO SWITCH, PLAYSTATION PORTABLE, etc.), touch tables and walls (e.g., where images are projected through acrylic and / or glass and then backlit with LEDs to illuminate the images).

[0220] Some or all of the operations of the computer 2402 performed in accordance with the computer program 2410 instructions can be implemented in a special purpose processor 2404B. In this implementation, some or all of the computer program 2410 instructions can be implemented via firmware instructions stored in read only memory (ROM), programmable read-only memory (PROM) or flash memory within the special purpose processor 2404B or in memory 2406. The special purpose processor 2404B can also be hardwired with circuitry to perform some or all of the operations to implement the application. Additionally, the special purpose processor 2404B can be a hybrid processor that includes special purpose circuitry for performing a subset of the functions and other circuitry for performing more general functions such as in response to computer program 2410 instructions. In one implementation, the special purpose processor 2404B is an application specific integrated circuit (ASIC).

[0221] The computer 2402 can also implement a compiler 2412 that translates applications or computer programs 2410 written in a language such as C, C++, Assembly, SQL, PYTHON, PROLOG, MATLAB, RUBY, RAILS, HASKELL or other languages into processor 2404 readable code. Alternatively, the compiler 2412 can be an interpreter that directly executes instructions / source code, translates source code into an intermediate representation that is executed or stored pre-compiled code. Such source code can be written in a variety of programming languages such as JAVA, JAVASCRIPT, PERL, BASIC, and the like. Upon completion, the applications or computer programs 2410 use the relationships and logic generated by using the compiler 2412 to access and manipulate data accepted from I / O devices and stored in the memory 2406 of the computer 2402.

[0222] The computer 2402 also optionally includes external communication devices, such as a modem, satellite link, Ethernet card, or other means for accessing and / or communicating with other computers 2402.

[0223] In one embodiment, the instructions implementing the operating system 2408, the computer programs 2410, and the compiler 2412 are tangibly embodied in a non-transitory computer- readable medium, e.g., data storage 2420, which can include one or more fixed or removable data storage devices such as zip drives, floppy disk drives 2424, hard drives, CD-ROM drives, tape drives, etc. Further, the operating system 2408 and the computer programs 2410 include computer program 2410 instructions that, when accessed, read, and executed by computer 2402, cause the computer 2402 to perform steps necessary to implement and / or use the present application, or that load the program instructions into memory 2406, thereby creating a special purpose data structure that

[0224] Of course, those skilled in the art will recognize that any combination of the above components, or any number of different components, peripherals, and other devices, can be used with the computer 2402.

[0225] Figure 25 A typical distributed / cloud-based computer system 2500 is shown schematically, which uses a network 2504 to connect a client computer 2502 to a server computer 2506. A typical combination of resources can include: a network 2504, which includes the Internet, a LAN (local area network), a WAN (wide area network), an SNA (Systems Network Architecture) network, etc.; a client 2502, which is a personal computer or workstation (as described above); and a server 2506, which is a personal computer, workstation, minicomputer, or mainframe computer (as described above). However, it can be noted that different networks, such as a cellular network (e.g., GSM [Global System for Mobile Communications] or other network), a satellite-based network, or any other type of network, can be used to connect the client 2502 and the server 2506 in accordance with embodiments of the present application. Figure 24 Figure 24 It can be noted that the various networks, such as a cellular network (e.g., GSM [Global System for Mobile Communications] or other network), a satellite-based network, or any other type of network, can be used to connect the client 2502 and the server 2506 in accordance with embodiments of the present application.

[0226] ​The network 2504, such as the Internet, connects the client 2502 to the computer 2506. The network 2504 can utilize Ethernet, coaxial cable, wireless communication, radio frequency (RF), etc. to connect and provide communication between the client 2502 and the server 2506. Moreover, in a cloud-based computing system, resources (e.g., storage, processors, applications, memory, infrastructure, etc.) in the client 2502 and server computer 2506 can be shared by users on the client 2502, server computer 2506, and one or more networks. The resources can be shared by multiple users and can be dynamically reallocated according to demand. In this regard, cloud computing can be referred to as a model for enabling on-demand access to a shared pool of configurable computing resources.

[0227] The client 2502 can execute a client application or web browser and communicate with the server computer 2506 that executes the web server 2510. Such web browsers are commonly programs such as MICROSOFT INTERNET EXPLORER / EDGE, MOZILLA FIREFOX, OPERA, APPLE SAFARI, GOOGLE CHROME, etc. The web server 2510 is typically a program such as MICROSOFT'S INTERNET INFORMATION SERVER, etc.

[0228] The web server 2510 can host dynamic server page (ASP) or Internet server application programming interface (ISAPI) applications 2512, which can execute scripts. The scripts invoke objects that perform business logic, known as business objects. The business objects then operate on data in the database 2516 through a database management system (DBMS) 2514. Alternatively, the database 2516 can be part of or directly connected to the client 2502, rather than communicating / obtaining information with the database 2516 over the network 2504. When a developer encapsulates business functionality into objects, the system can be referred to as a component object model (COM) system. Thus, scripts executing on the web server 2510 (and / or applications 2512) invoke COM objects that implement business logic. Further, the server 2506 can utilize MICROSOFT'S TRANSACTION SERVER (MTS) to access desired data stored in the database 2516 via interfaces such as ADO (Active Data Objects), OLE DB (Object Linking and Embedding Database), or ODBC (Open Database Connectivity).

[0229] Generally, these components 2500-2516 include logic and / or data, which is embedded in or retrievable from a device, media, signal, or carrier (e.g., a data storage device, a data communication device, a remote computer or device coupled to a computer via a network or via another data communication device, etc.). Further, the logic and / or data, when read, executed, and / or interpreted, results in steps necessary to practice and / or use the application being executed.

[0230] Although the terms "user computer," "client computer," and / or "server computer" are referenced herein, it should be understood that such computers 2502 and 2506 can be interchangeable and can also include thin client devices with limited or complete processing capabilities, portable devices (such as tablets, notebook computers, pocket computers, multi-touch devices), and / or any other device with suitable processing, communication, and input / output capabilities.

[0231] Of course, those skilled in the art will recognize that any combination of the above components, or any number of different components, peripherals, and other devices, can be used with the computers 2502 and 2506. Embodiments of the application are implemented as software / CAD applications on the client 2502 or server computer 2506. Further, as described above, the client 2502 or server computer 2506 can include a thin client device or portable device with a multi-touch based display.

[0232] CONCLUSION

[0233] This concludes the description of preferred embodiments of the application. Some alternative embodiments for implementing the application are described below. For example, any type of computer (such as a mainframe, mini, or personal computer) or computer configuration (such as a time-sharing mainframe, local area network, or stand-alone personal computer) can be used with the application.

[0234] The embodiments of the application produce the following novel contributions that previous research has not been able to address and implement:

[0235] - A method for generating a diverse 3D geometry form in the form of a grid that is used as an analytical model of gbxml files and associated energy use data to build a comprehensive synthetic dataset that can effectively train a surrogate model.

[0236] - Building an automated process to generate the above dataset without human intervention.

[0237] - Demonstrating that explicit high-level features are good predictors of EUI (Energy Use Intensity) of variable geometry.

[0238] - A method for compiling energy-related data from multiple sources.

[0239] - A surrogate model driven by the synthetic dataset (which can achieve 1.3% error for a single zone and 1.9% error for five (5) climate zones).

[0240] - A DYNAMO environment zero-touch node that provides and demonstrates real-time EUI predictions.

[0241] In addition to the above, the embodiments of the application (e.g., including the use of synthetic data and machine learning) can be used in one or more of the following applications / fields / domains (i.e., to generate and output building operational performance analysis outputs in one or more of the following fields / domains):

[0242] • Solar analysis

[0243] • Daylighting (in particular)

[0244] • Thermal comfort

[0245] • Embodied carbon

[0246] • Structural analysis

[0247] • Construction cost

[0248] • Buildability

[0249] • Wind flow analysis (computational fluid dynamics)

[0250] • Photovoltaic potential

[0251] • Construction project requirements

[0252] • Construction scheduling

[0253] • Construction engineering progress analysis and prediction

[0254] • Crowd simulation and shortest path finding

[0255] • Computational fluid dynamics prediction

[0256] • Fire and smoke migration modeling

[0257] • Numerous other analysis procedures that require extensive computation from geometry and parameters but can be approximated closely to deliver high value and fast results

[0258] The foregoing description of preferred embodiments of the application has been presented for the purposes of illustration and description. It is not intended to be exhaustive or to limit the application to the precise form disclosed. Many modifications and variations are possible in light of the above teaching. It is intended that the scope of the application be limited not with this detailed description, but rather by the claims appended hereto.

Claims

1. A computer-implemented method for generating a building operational performance analysis output, comprising: (a) generating a synthetic dataset comprising a set of three-dimensional building conceptualized block geometry, wherein the generating comprises: (i) identifying two or more geometry types; (ii) partitioning the two or more geometry types into classes at an occupancy area level and at a block level; (iii) algorithmically generating the three-dimensional building conceptualized block geometry using a separate workflow for each class, wherein the algorithmically generating utilizes generative design; (b) generating an analysis model associated with each of the three-dimensional building conceptualized block geometry; (c) generating a simulation result for each of the analysis models by performing a simulation based on each of the analysis models; (d) training a surrogate model using a set of features extracted from the simulation results, wherein the machine learning iteratively determines the set of features based on a measured accuracy of the surrogate model; (e) receiving a geometry input; (f) processing the geometry input through the surrogate model to generate the building operational performance analysis output; and (g) informing a designer of an approximate energy use intensity of the geometry input with the building operational performance analysis output.

2. The computer-implemented method of claim 1, wherein the identifying the two or more geometry types comprises: performing correlation learning.

3. The computer-implemented method of claim 2, wherein the correlation learning comprises utilizing the set of features consisting essentially of: Floor number; envelope area to volume; total floor area to volume; envelope area to floor area; total roof area; total interior floor area; total sloped slab area; north wall area; south wall area; east wall area; west wall area; northeast wall area; northwest wall area; southeast wall area; and southwest wall area.

4. The computer-implemented method of claim 2, wherein the correlation learning comprises utilizing the set of features, wherein the set of features expresses orientation as projected area to two directions and a ratio of the projected area to total area.

5. The computer-implemented method of claim 1, wherein partitioning the two or more geometry types at the occupancy area level comprises: partitioning the two or more geometry types into convex geometry and concave geometry; partitioning the convex geometry into convex geometry circle inscribed polygon and convex geometry non-circle inscribed polygon; and partitioning the concave geometry into concave geometry orthogonal polygon and concave geometry non-orthogonal polygon.

6. The computer-implemented method of claim 5, wherein the workflow for the convex geometry circle inscribed polygon comprises: generating an occupancy area guide circle, wherein the occupancy area guide circle determines a location and scale of a convex geometry circle inscribed polygon; ​ partitioning the footprint guide circle into partitions, wherein the partitions determine a number of vertices of the convex geometry circle-inscribed polygon; determining a vertex density that defines a percentage of the partitions to use as vertices; and generating a convex hull representing a footprint of the convex geometry circle-inscribed polygon based on the partitions and the vertex density.

7. The computer-implemented method of claim 5, wherein the workflow for the convex geometry non-circle-inscribed polygon comprises: generating a point grid, wherein the point grid has a defined number of grid points in an X direction and a Y direction, and wherein the point grid determines a scale and an aspect ratio of a convex geometry non-circle-inscribed polygon; determining a vertex density that defines a percentage of the grid points to use as vertices; and generating a convex hull representing a footprint of the convex geometry non-circle-inscribed polygon based on the point grid and the vertex density.

8. The computer-implemented method of claim 5, wherein the workflow for the concave geometry orthogonal polygon comprises: generating a point grid, wherein the point grid has a defined number of grid points in an X direction and a Y direction, and wherein the point grid determines a scale and an aspect ratio of a concave geometry orthogonal polygon; determining a vertex density that defines a percentage of the grid points to use as vertices; generating a convex hull representing a base footprint of the concave geometry orthogonal polygon based on the point grid and the vertex density; manhattanizing the base footprint to generate the concave geometry orthogonal polygon, wherein the manhattanizing comprises: an iteration procedure starts with a first vertex of the vertices in the base footprint and traverses the vertices; the iteration procedure checks whether a next immediate vertex of the vertices is linearly displaced or obliquely displaced, wherein: if linearly displaced, the iteration procedure proceeds to the next vertex; and if obliquely displaced, the iteration procedure adds an additional manhattan point that is an intersection of a linear extension of the current vertex and the next vertex; and once all the manhattan points are added, joining all the points together with a closed polygonal curve that is output as a final footprint of the concave geometry orthogonal polygon.

9. The computer-implemented method of claim 5, wherein the workflow for the concave geometry non-orthogonal polygon comprises: generating a footprint guide circle, wherein the footprint guide circle determines a location and a scale of a concave geometry non-orthogonal polygon; partitioning the footprint guide circle into partitions, wherein the partitions determine a number of vertices of the concave geometry non-orthogonal polygon; determining a vertex density that defines a percentage of the partitions to use as vertices; and determining a sub-vertex density that determines a percentage of the vertices to use as parent vertices extrapolated to next points as sub-vertices, wherein the sub-vertices comprise extensions of parent vertices to an interior of the footprint guide circle; determining a sub-vertex parameter that determines how far each sub-vertex extends from the parent vertex; and generating a polygonal curve by joining together the parent vertex and the child vertex, wherein the polygonal curve serves as a final footprint of the concave geometric structure non-orthogonal polygon.

10. The computer-implemented method of claim 1, wherein partitioning the two or more geometric structure types at the block level comprises: partitioning the two or more geometric structure types into convex geometric structures and concave geometric structures; partitioning the convex geometric structures into convex simple extrusions and convex variable extrusions; partitioning the convex variable extrusions into aligned and non-aligned; partitioning the non-aligned into consistent extrusions and inconsistent extrusions; partitioning the concave geometric structures into concave simple extrusions and concave variable extrusions; partitioning the concave variable extrusions into consistent indentations and inconsistent indentations.

11. The computer-implemented method of claim 1, wherein the separate workflow for each category is based on: one or more modifier variables that vary properties and shapes of the three-dimensional building conceptual block geometry and define a base scheme; and one or more generator variables that vary the base scheme into different samples and generate new geometric structures in the same category.

12. The computer-implemented method of claim 1, wherein the generative design: creates the synthetic dataset of reusable using a random function; creates the synthetic dataset based on a feature search using a cross-product function; creates the synthetic dataset based on a sensitivity analysis using an analog function; and generates design alternatives for the synthetic dataset based on input design goals and parameters.

13. The computer-implemented method of claim 1, wherein the generating the analysis model comprises: deriving the three-dimensional building conceptual block geometry as a three-dimensional geometry file; generating a hierarchy sequence based on input, wherein the input includes a number of floors on the ground and a floor height; and generating the analysis model based on the three-dimensional building conceptual block geometry and the input.

14. The computer-implemented method of claim 1, wherein the analysis model is trained using only Manhattanized geometry.

15. A computer-implemented system for generating building operational performance analysis output, comprising: (a) a computer having a memory; (b) a processor executing on the computer; (c) the memory storing a set of instructions, wherein the set of instructions, when executed by the processor, cause the processor to perform operations comprising: (i) generating a synthetic dataset comprising a set of three-dimensional building conceptual block geometries, wherein the generating comprises: (1) identifying two or more geometric structure types; (2) partitioning the two or more geometric structure types into categories at a footprint level and at a block level; (3) generating the three-dimensional building conceptual block geometries algorithmically using a separate workflow for each category, wherein the generating algorithmically utilizes generative design; (ii) generating an analysis model associated with each of the three-dimensional building conceptual block geometries; (iii) generating a building operational performance analysis output based on the analysis model. (iii) generating simulation results for each of the analysis models by performing simulations based on each of the analysis models; (iv) training a surrogate model using machine learning based on a set of features extracted from the simulation results, wherein the machine learning iteratively determines the set of features based on measured accuracy of the surrogate model; (v) receiving geometry inputs; (vi) processing the geometry inputs through the surrogate model to generate the building operational performance analysis outputs; and (vii) informing a designer of an approximate energy usage intensity of the geometry inputs with the building operational performance analysis outputs.

16. The computer-implemented system of claim 15, wherein the identifying the two or more geometry types comprises: performing correlation learning.

17. The computer-implemented system of claim 16, wherein the correlation learning comprises utilizing the set of features consisting essentially of: Floor number; envelope area to volume; total floor area to volume; envelope area to floor area; total roof area; total interior floor area; total sloped panel area; north-facing wall area; south-facing wall area; east-facing wall area; west-facing wall area; northeast-facing wall area; northwest-facing wall area; southeast-facing wall area; and southwest-facing wall area.

18. The computer-implemented system of claim 16, wherein the correlation learning comprises utilizing the set of features, wherein the set of features expresses orientation as projected area to two directions and a ratio of the projected area to total area.

19. The computer-implemented system of claim 15, wherein the dividing the two or more geometry types at the occupancy area level comprises: dividing the two or more geometry types into convex geometry types and concave geometry types; dividing the convex geometry types into convex geometry circle-inscribed polygons and convex geometry non-circle-inscribed polygons; and dividing the concave geometry types into concave geometry orthogonal polygons and concave geometry non-orthogonal polygons.

20. The computer-implemented system of claim 19, wherein the workflow for the convex geometry circle-inscribed polygons comprises: generating an occupancy area guide circle, wherein the occupancy area guide circle determines a location and a scale of a convex geometry circle-inscribed polygon; dividing the occupancy area guide circle into partitions, wherein the partitions determine a number of vertices of the convex geometry circle-inscribed polygon; determining a vertex density that defines a percentage of the partitions to use as vertices; and generating a convex hull representing an occupancy area of the convex geometry circle-inscribed polygon based on the partitions and the vertex density.

21. The computer-implemented system of claim 19, wherein the workflow for the convex geometry non-circle-inscribed polygons comprises: generating a point grid, wherein the point grid has a defined number of grid points in an X direction and a Y direction, and wherein the point grid determines a scale and an aspect ratio of a convex geometry non-circle-inscribed polygon; determining a vertex density that defines a percentage of the grid points to use as vertices; and generating a convex hull representing a footprint of a non-circular inscribed polygon of the convex geometry based on the point grid and the vertex density.

22. The computer-implemented system of claim 19, wherein the workflow for the concave geometry orthogonal polygon includes: generating a point grid, wherein the point grid has a defined number of grid points in an X direction and a Y direction, and wherein the point grid determines a scale and an aspect ratio of a concave geometry orthogonal polygon; determining a vertex density that defines a percentage of the grid points to use as vertices; generating a convex hull representing a base footprint of the concave geometry orthogonal polygon based on the point grid and the vertex density; manhattanizing the base footprint to generate the concave geometry orthogonal polygon, wherein the manhattanizing includes: an iteration procedure that starts with a first vertex of the vertices in the base footprint and traverses the vertices; the iteration procedure checks whether a next immediate vertex of the vertices is linearly displaced or obliquely displaced, wherein: if linearly displaced, the iteration procedure proceeds to the next vertex; and if obliquely displaced, the iteration procedure adds an additional manhattan point that is an intersection of a linear extension of the current vertex and the next vertex; and once all the manhattan points are added, joining all the points together with a closed polygonal curve that is output as a final footprint of the concave geometry orthogonal polygon.

23. The computer-implemented system of claim 19, wherein the workflow for the concave geometry non-orthogonal polygon includes: generating a footprint guide circle, wherein the footprint guide circle determines a location and a scale of a concave geometry non-orthogonal polygon; dividing the footprint guide circle into partitions, wherein the partitions determine a number of vertices of the concave geometry non-orthogonal polygon; determining a vertex density that defines a percentage of the partitions to use as vertices; and determining a sub-vertex density that determines a percentage of the vertices to use as parent vertices extrapolated to next points as sub-vertices, wherein the sub-vertices include extensions of parent vertices to an interior of the footprint guide circle; determining a sub-vertex parameter that determines how far each sub-vertex extends from the parent vertices; and generating a polygonal curve by joining the parent vertices and the sub-vertices together, wherein the polygonal curve serves as a final footprint of the concave geometry non-orthogonal polygon.

24. The computer-implemented system of claim 15, wherein dividing the two or more geometry types at the block level includes: dividing the two or more geometry types into convex geometries and concave geometries; dividing the convex geometries into convex simple extrusions and convex variable extrusions; dividing the convex variable extrusions into aligned and non-aligned; dividing the non-aligned into consistent convex and inconsistent convex; dividing the concave geometries into concave simple extrusions and concave variable extrusions; ​ The concave variable extrusion is divided into consistent concave and inconsistent concave.

25. The computer-implemented system of claim 15, wherein the separate workflow for each category is based on: one or more modifier variables that change properties and shapes of the three- dimensional building conceptual block geometry and define a base scheme; and one or more generator variables that change the base scheme to different samples and generate new geometries in the same category.

26. The computer-implemented system of claim 15, wherein the generative design: creates the synthetic dataset reusable using a random function; creates the synthetic dataset based on a feature search using a cross-product function; creates the synthetic dataset based on a sensitivity analysis using an analog function; and generates design alternatives for the synthetic dataset based on input design goals and parameters.

27. The computer-implemented system of claim 15, wherein the generating the analysis model comprises: deriving the three-dimensional building conceptual block geometry as a three- dimensional geometry file; generating a hierarchy sequence based on input, wherein the input includes a number of floors on the ground and a floor height; and generating the analysis model based on the three-dimensional building conceptual block geometry and the input.

28. The computer-implemented system of claim 15, wherein the analysis model is trained using only Manhattanized geometry. ​

Images