Design Generator

Design generator is a web interface to generate and evaluate design options. See our presentation

Write-up by Amir Rezaei-Bazkiaei

The story begins with the creation of Design Explorer (DE) tool of CORE studio. The goal with DE is to enable designers to exercise the impact of a broad range of design decisions on a range of goals or performance metrics. The tool gives ultimate flexibility to dissect the relationship between inputs and outputs but the design team still needs to go through rigorous modeling efforts to create a dataset to visualize. This has been the central part of an idea in the back of my mind, and as it turns out many other people’s minds present at the Hackathon this year. After the announcement of ideas from multiple people of the group out team set out to design a web tool that can help design teams generate solution spaces with ease and accuracy.

Why is this needed:

To save time at early stages of design! The idea was to create a free, parametrized, online, easy-to-use tool that could be used by professionals to generate an early stage solution space within minutes to spark conversations and ideas. The common practice to answer such questions usually involves days of modeling the detailed geometry, internal inputs and systems to be able to shed light on early stage questions. By the time the sustainability consultant puts all of that together there is a good chance that the design team has moved on with their decisions or decisions are made in silos with limited feedback. In the best-case scenario that a consultant is involved, it usually takes a lot of time to model the geometry, break down the building complexity and run analyses to get key performance metrics out for a large solution space.

Design solution comparisons and selections are usually high level conversations that are commonly overruled by cost or preferences at early stage design meetings. Comparing design options through detailed modeling is an intensive effort that has little ROI on the consulting services provided. In other words, detailed and rigorous modeling, including various QA and fact checking, are better to be reserved for later stages of design where aggressive goals could take advantage of the fees. It is important to remember that the idea of the online tool wasn’t to replace the consulting services but rather to serve as a tool to start basic design conversations such as HVAC system selections and envelope choices.

How can this work:

This project looked at generating a large dataset or a fully parametrized model that can be used for all climate zones and space types to come up with initial key performance metrics (energy, peak loads, daylighting, etc.) that can be used at early stages of design. This tool would enable designers to filter through a large dataset or select a set of inputs representing their buildings (or portions of it) and get instant feedback on key building performance metrics without the need to create a detailed model. A fully parametrize shoebox model was used to represent the geometry.

The underlying assumption to aim at producing such tool is that the energy use of a building is primarily driven by three main factors: 1) building architecture and ambient conditions 2) internal loads, space programming and use profiles and 3) HVAC systems.

Theoretically, for a specific building type, HVAC system, and envelope properties, there should be a relatively linear relationship between the energy use and the size of the building. That is the premise that makes an index like EUI (kBtu/ft2) a useful metric while comparing different buildings. Size in this context is a metric that captures the ratio of exterior exposure to interior volume as well as the average building internal loads accounting for diversity in the space programming. The PassiveHouse standard for example looks at the exposed exterior area of building (A) to the enclosed volume (V) as an initial compactness metric. This needs to be coupled with a similar metric that captures the ratio of different space areas relative to the main building occupancy so that the internal gains can be normalized and scaled with simple building area inputs. The user then only needs to input area information from the actual project.

If the geometry and architectural features can be simplified with mostly area and dimension inputs then a broad range of different thermal properties, climatic conditions and HVAC options can be evaluated with the help of automating scripts. There are many other factors embedded in this simplification that need to be vetted. To name a few:

  • Perimeter to core area ratio representing actual building
  • Window-to-wall ratio
  • Shoebox model boundary condition and scalability
  • OA requirement rates based on areas and delivery method
  • Common HVAC system efficiencies and their dependency on full-size geometry

What are some challenges:

Using a shoebox approach can be beneficial to parametrize the model more easily but can also introduce the potential of missing key architectural and mechanical factors that will be present in a full-scale model. Factors such as the impact of multi-story building boundary conditions and the interactions between HVAC systems in a full-scale model versus a shoebox model come to mind. List of potential challenges:

  • Plant loop implications for HVAC systems in the shoebox model versus full-scale
  • Air mixing at the air loop level between multiple zones is limited in a shoebox model
  • OA flow rates will need to be input separately for perimeter and core areas to represent main building occupancy and other space types
  • Internal load diversity impact on the HVAC energy consumptions may not be easily realized
  • Initial area proportions need to be realistic to represent the programming of the building
  • Architectural elements such as shading devices can be more easily incorporated and parametrized in the shoebox model but will need to be translated to well represent the real-world shading potential

Where things are now and what needs to be done:

The image below shows the conceptual workflow of how the tool works. The team was able to create the web interface, identify the initial list of input and output parameters, and create the analytical backbone in Grasshopper (Honeybee/Energyplus + Ladybug) to generate energy and daylight outputs. The original idea was to create a large database that the user can access but it was concluded that the design space will become too large too fast to cover a reasonable range of inputs for all or even a portion of variables. In my opinion, the tool will ideally host the simulations engines on a server that has a reasonable storage capacity to store the outputs generated for a range of variables that the user enters via the web interface. The automation part that needs to be figured out is how and where to host the simulation engines and outputs, and how to parse the outputs to the design explorer website.

A few informative conversations during the development were centered on the idea that the modeling tools are not necessarily equipped with the engineering design logic and rule of thumb values that designers use in practice. These rules of thumb usually come from the physical limits of particular HVAC equipment at zone level to meet the heating/cooling loads. For this online tool to truly become beneficial, it is required that more HVAC level inputs are exposed at the web interface level. The user should be able to have access to HVAC component inputs such as zone and plant level efficiencies, fan and pump pressure drops, design temperature differentials, etc. and be able to assign different HVAC systems to different orientations of the building.

The “autosizing” functionality of Energyplus, and any other energy modeling software for this matter, can also be misleading and one of the most overlooked inputs in the energy modeling process. It is common practice to design efficient systems like radiant floors or chilled/heated beams for a specific heating/cooling capacity limit which is based on the practical aspects of how these systems can meet perimeter loads. Radiant floors for example operate best for cooling at around peak cooling loads of 15 Btu/hr.ft2 (this number may vary slightly depending who you ask). The autosizing assumption in Energyplus though usually is that the entire floor is covered with in-floor tubes that have maximum water flow rates available to them to meet the loads. In practice, a designer may only design the radiant floor capacity up to 15 Btu/hr.ft2 of the peak and meet the rest of the loads with a supplemental equipment such a fan-coil units (FCU) knowing that a radiant system may not be adequate. What is overlooked if the unlimited radiant floor capacity is assumed is the upfront cost to install and potential additional cost to operate the supplemental FCUs which is typically something an energy modeler will not double check..

This tool also needs to take key architectural and HVAC inputs by orientation so that the shoebox model can be used to answer questions that are dependent on different façade orientation. One possible alternative to speeding up the simulation times is using surrogate models or machine learning algorithms in conjunction with the Energyplus engine runs.

Looking forward to hearing your thoughts.

List of identified inputs:

  1. # of Floors

  2. Total building area

  3. Aspect Ratio

  4. Perimeter Depth

  5. Orientation

  6. Floor to Floor height

  7. Window Wall Ratio (%)

  8. Window Height

  9. Sill Height

  10. Shading overhang depth

  11. Infiltration

  12. Wall Assembly Type (steel framed vs. mass)

  13. Roof Assembly Type (steel framed vs. mass)

  14. Wall R-value

  15. Roof R-value

  16. Glazing U-factor

  17. Glazing SHGC

  18. Glazing VLT

  19. Outside air (Core)

  20. Outside air (Perimeter)

  21. Internal Load (Core)

  22. Internal Load (Perimeter)

  23. Heating Setpoint

  24. Cooling Setpoint

  25. HVAC System

Key performance metrics:

  1. Energy use intensity (EUI)

  2. EUI breakdown

  3. Peak heating and cooling loads for each zone

  4. Plant equipment sizes or loads

  5. Daylight factor

  6. Upfront equipment cost

  7. Operational energy cost

How we built it

The current stack uses three.js, d3.js, Twitter bootstrap, and the google drive API for the interface. We used Rhino + Grasshopper + Honeybee to generate the energy simulation result database.

Challenges we ran into

  • The google drive API is tricky to navigate - we are still sorting how to make this an entirely client-side app without hitting the security restrictions of cross-origin requests.
  • Integrating multiple sliders from Twitter bootstrap with Three.js proved difficult, and still isn't functioning quite right in the app.

What's next for Design Generator

We need to get the interface working, and full link the energy simulation result data. The existing tool is a proof-of-concept, with all the parts built, but not fully linked yet.

Team members

An-lei Huang, Anton Szilasi, Byron Mardas, James McNeill, Leland Curtis, Matt Dahlhausen, Mostapha Sadeghipour Roudsari.

Built With

Share this project:
×

Updates