HVAC System Selection with Generative Design

SEAN FRUIN: Hi everybody. Welcome to Generative Design for HVAC System Selection. So this all comes around this big challenge that I had at the beginning of the year when I joined this startup called iBuilt. They are a modular construction company-- or were a modular construction company-- and we had a really ambitious CEO. And it was all about standards, and repeatability, and stuff like that, kind of typical.

So what this meant for us is we got this straight line now. So procurement first. So let's know what fans we're buying. Let's know what pumps we're buying. Easy installation was a big thing that we're worried about. We want these modules to be able to connect really quickly out in the field. So we're looking at quick connections and all this ambitious stuff.

We want it to be really cheap, a developer mindset. We want a one size fits all solution. And that's almost impossible. And then, of course, we want it to be beautiful.

So a lot of these things are kind of contradictory. Add on top of that, I was assigned the universal of alternatives for HVAC system selection. Now this was a phrase they used all the time. And what it meant was we need to find all the possibility of alternatives. No rules of thumbs. We actually need to calculate cost. And we need to calculate the space requirements.

So this is a pretty overwhelming task. If you're familiar with HVAC, you'll know that there's so many different combinations of equipment. We could use radiators for bedrooms for heating, could just use diffusers with a furnace and an MEP closet, could use VRF systems.

Could use electric baseboard heaters. For exhaust fans, right, we could exhaust directly out. Granted that won't be that beautiful. Or you can exhaust all the way out to the ceiling. That won't be that cheap.

There's a whole bunch of different ways you can arrange stuff inside of a cubby, in each unit. Or you can go with these big central plants and have area down in the basement and infrastructure, more infrastructure running through the structure, and maybe up to the ceiling, to condensing units, et cetera.

So many options. On top of that, all of these different systems come with a different infrastructure alternatives, which all come with a different cost, different labor cost, material cost. And then even then, we can go deeper. And then for each type of pipe or duct, there's different types of fittings.

Are we going to use braised fittings? Or we use these expensive quick connect fittings? Make sure you take in account special things for VRF systems. And again, all these take different time to install, different upfront cost, a lot. So I was completely overwhelmed trying to do this.

After all, we were a startup. And I was also the only engineer. So this was all on my shoulders. Literally I could not comprehend all the data, overwhelmed by all the calculations that would need to be done. My brain hurt thinking about all the different configurations and how to organize the data.

I didn't have enough knowledge. And I definitely don't have enough time. We were trying to move quick. I literally actually took a week of leave off because I was going crazy. I felt like my brain ran out of RAM. If you use Dynamo a lot, you'll know what that means. So in that week I thought about it, collected my thoughts.

And I realized, hey stick with what you're good at, what you've been working on for four years. And that's what you can use, right? So this idea of generative design, computational design, using data, algorithmic thinking, using this we can organize everything in a really clear way.

We can articulate trade offs now that we have a system. We'll get into that. And then I can express concerns that I had with proof. In other words, I wasn't just using rules of thumb now. I actually had this system to show these things.

So that's what we're going to talk about today, my kind of journey of building this and formulating this idea of using HVAC, generative design for HVAC selection. So first we're going to get kind of understand what generative design is, the foundational concepts. We're then going to identify how to define rules for a successful generative design analysis.

Then we're going to explore running Generative Design inside Dynamo and Revit. Then we're going to take all this and we're going to apply it to MEP System design.

So Generative Design 101. So really generative design, it's a buzz word and it's getting bad rap. So you could probably summon what is algorithmic design? What is computational design? What is programming, probably many more. But here's my definition of generative design.

Last year I gave it to Ryan from TestFit. This year I'm going to take a stab at the simple definition. Generative design is the combination of data, some type of algorithmic logic, that encompasses our design ideas. Then by combining all these, we deliver a method for optimization of our design problems.

This isn't something that you can just go get off the shelf. Typically, there are some examples. And many startups are trying to get in this space. But really the framework that Autodesk has built is to start with data, right? This could be out of Revit. This could be of Excel, cvs files, JPEG images, json files, and the list goes on.

Then we have to build-- take that data and build a computational design system, a series of instructions, right, combinations of rules, and algorithms, and data, and geometry that hopefully produces more than just one solution. So then we start getting up there. And this where the Generative Design-- used to be Project Fractal right, comes in.

That's where we can start to move all these sliders and explore the design space. Then from last year, I added a section to this pyramid. And it is the optimization section. So this is really what the Generative Design in Revit is all about. Not just single optimization, but a way to really understand multi objective optimization. And you have a whole bunch of contradicting constraints. And you want to outweigh and see the contrast and comparison.

All right, so let's build this thing up. So I always go to food, used to cook, makes sense to me. So it's just like cooking, right? So if you're making a meal, you really want to start off with what do I want to cook? And that's your starting point, right? What's our goals? We need to go to the store and then get those ingredients. Do I even go off the recipe or make up our own recipe? So there's variables there, right?

What's our temperatures of things? How much are we measuring out? How long is stuff in the oven? All these are variables that could change the outcome. And then usually these ingredients go through a process of dicing, cooking, rolling out, straining. And out of it, we get this delicious meal that can then be evaluated for things like-- how's it taste? How's the presentation? Is there a variety of flavors?

And then with that feedback, right, you could go back in this feedback loop and make this recipe better, and better, and better. So that's really the idea-- is we build out this algorithm, this process. And we can make it better, explore design ideas.

So let's formulate the goals. So usually you start off with these vague, more vague ideas. You want to ask questions about are there any competing characteristics in my design constraints? Am I looking to maximize or minimize anything? Now we need to figure out a way to take those goals, or those ideas, and then evaluate them using a mathematical means.

Once we've established our valuations and our goals-- again, starting with the end-- I like to go back and get my ingredients, or get my static data inputs. What data goes into this recipe?

So once we've done that, we can then start to think about the geometry system. What levers can I pull and stretch to make different options change, and distort, and explore a bigger space. So once that's done, then we really get into the Generative Design part, which is where we can start to analyze, visualize this information.

Then we can really rely on the Generative Design in Revit tools to evaluate it and give it a feedback loop to where now we're using genetic algorithms which will help guide it to optimal solutions.

So I always think it's helpful to start off with a good simple example. So I hope we can all relate to this one at least a little bit. So when I was doing some research on multiple objective problems, a car kept on coming in. So then I thought, hey, I need a data set. Hey Mario Kart.

So if you've played any of the newer Mario Karts recently, you have to pick a character. Then you collect a kart. Then you collect wheels. And then you pick a guider. And all that shifts, right? So your speed might go up, but with cost to your acceleration, or cost to your weight. So there's an optimal that you're trying to find.

So when I found this data-- and this kind of brings up some conversation, right? So when I found this data online, I looked into the chats and I found some interesting comments that I think perfectly describe the whole why we're doing this optimization process. So if you don't want to read all of them, we have SegaBlueSky. To sum it up he says, there's too much data to understand. There's too many combinations.

Zyrac says the balance set is key. We've got to have balance. Therefore you're ready for everything. Then finally you have-- you always lose one, you always gain one. So just it is what it is. So I question, are these assumptions true? And how would you disprove or prove this?

So let's take that framework again. So we're playing Mario Kart. What is our goal? Do we just want to win? And that might be a little bit too simple, right? So you want to ask questions to start to get a better understanding, right? So does the track have a lot of turns that might affect my handling? Can I fall off the track? If I can fall off, maybe I want my weight to be really high. Can I stay on the track? Am I a beginner, or am I a pro?

So some of this is given. But now let's go to the data collection. So I always like to say, if you can get it into Excel, you can get it into Dynamo. So I hopped on like I said to a quick Google search. And I found all the stats that I needed to build this geometry system, to measure and optimize all the possible combinations of characters, karts, wheels, gliders, and tires.

Simply getting that information into Excel, and then using some Dynamo. And we can get this into the Data Remember Node. And so now we have all this information to build our thing. Data Remember Node, by the way, is really cool. So it doesn't have to be connected. It actually caches the information. And so that's a way that you can use it, not only for Generative Design but a way to hold on to information and share information. So I recommend you look into that.

So then built in to Mario Kart is already these evaluators and variables. So again we're looking at speed, how fast are we going. Acceleration, how fast do I accelerate when I get hit by a shell or when I go off the edge? Do I speed up quickly? What's my weight? Am I able to get knocked over off the edge?

How is my handling? Is it hard to make turns? How's my traction if I can't stay on the road in dirt and ice. So these are all the evaluators that come out of our selection of variables. So we have 16 different characters, 40 different karts, 21 different tires, and 14 different gliders. So when you add-- when you put this all together, the different options I think it's 100,300 and something, if I remember. So it's a lot, right?

So maybe it is too much data to really wrap your head around. But again, that's right where computation comes in. So let's build this system. So here we took that data. And now you can see by just running through these sliders, we can start to visually see what's going on. We have a little geometry system there to make the cart. And we have this nice spider graph to see the give and take of all these variables.

And then of course Luigi is our output, Baby Peach, the clown Koopa car, the sports Koopa car, so all these different options.

So now let's take this idea and into Generative Design. So for this first one, I'm going to say let's just maximize speed-- so single optimization. And very quickly you'll see it's going to go through, so only 10 different sets. And there we have the fastest possible combination in Mario Kart for speed.

But look how low you are on other things. Maybe not an ideal solution. So that's where this multi objective-- and really the Holy Grail of Generative Design-- a way to check all the different solutions.

So in this one, I did a cross product. And you can see there's 100,000 different solutions. I didn't grab quite all of them, but almost all of them. And so it's just a lot, right?

So we can start to use different tools to navigate it. We have the parallel coordinates down there. We have all the different things, images that come out Dynamo that we can use. And then we have this, right, tabulated form. We can just maximize and minimize. Again, there's our really high speed but a really low acceleration.

What about turbo speed? I read somewhere that that's-- you want to maximize turbo speed-- in this very important research. And then maybe the best one, you have the plot down here. So here we have speed on the y-axis and then acceleration on the z-axis. And this lets us start looking and comparing to different combinations, right?

And so if you'll notice too, the ones I'm clicking on right there-- those are the good solutions. The ones below that are really bad solutions. Why would you do that? If I can have a kart that's just as fast but has less acceleration, why would I pick that? So you really only want the solutions that are on top there.

And you can mess around with this with the relationship. Notice that the data is really clean. It's just how it's structured in the game. All right, we can get a good idea.

So now let's go back to our lovely conversation on the internet. So remember we had SegaBlueSky-- too much data to understand. I'm going to say that's false. Using Generative Design with Revit, we have all these different ways to take all this information and make sense out of it.

Balance set up is the key in all situations. So he's saying, right, you want to be right in the middle there. Again, I'm going to say this is false. We can analyze the data. We can find combinations that are better for a beginner, someone that is going to find themselves off the road often and needs really good handling to get around turns.

And on the opposite end of the spectrum, we're going to have to find the optimal for the pro guy, the guy that's going to stay on the road, drift those turns. And it's not just the performer, right, it's the track too. Are you going to be on a track that's straight? Are you going to be on a track with a lot of turns? As you see, we can start to make sense out of this.

And of course, the last one. You always lose one and gain one. And that is absolutely false, right? So we really again only want the green solutions. All the red solutions, they are trash. Why would I pick that? Again why would I want a car that has the same accelerations on the y-axis, higher acceleration but lower speed, when I can get one with higher acceleration and higher speed?

So this is really the power of Generative Design-- trying to make sense out of large data sets, big design spaces.

So now let's take this and look at it for HVAC system selection and see if we can solve the problem that I had with the universal alternatives. So I joined iBuilt because I was really excited, right, with their foundation of automation.

We can eliminate data drops. So we had this system, right, configurator for apartments combined with standardized layouts for apartments. I could get to that information really quick, no need to look at architects' space naming. I knew what the namings were going to be.

No need to ask questions about their families. No need to ask about thermal properties. Again, no data drops, amazing. The standard buying process. Again big ones. This let us really constrain an algorithm enough to be able to do it. So we're going to run through the corridors. We're going to run through these MEP holes.

Really help constrain the algorithm. Procurement first, another huge benefit, right? So we're actually designing for very specific equipment. So if I have a whole bunch of equipment, I can go in there and find the best one and pull it out. And then I have all my data right away, whether it's for energy analysis, whether it's for calculating the weight, the volumes, right?

I know all that up front. Therefore I'm able to calculate some of those requirements, like area. So all of this leads to automation.

This is why I think modular construction is a huge deal. This is why I think standardization is a big deal. These things lead to automation and where we're headed.

So let's look at the evaluators. So again if you go back-- remember some of the constraints. We wanted it to be cheap. We want it to be easy to install. We want it to be-- hit our tight space requirements. We want one size fits all. And we want it to be beautiful.

And so how can we take those and then turn them into measurable evaluators? Well cheap, right, so we want to minimize material cost. We want to minimize the labor cost. Maybe you want to maximize factory labor cost-- at least against field labor cost, right, because those would be at a different rate.

We want to minimize unit mechanical area, minimize horizontal area. And I'll dig into what these mean. But in other words, we could take and find the areas of everything, right? Again, minimize our shaft area, minimize plant area. Maybe we want to minimize weight. Maybe we only have a certain weight that we can hit that needs to be built in an algorithm.

Maybe there's limits would VRF that need to be built into the algorithm. So again all this design knowledge-- constraints and everything need to be built in and go in. And then figuring out a way to measure it. So the best one-- how are we going to measure architecture aesthetics?

So if there's a louver on the side of the building, maybe we take the square area of the louver, times that by something, right? It's those ones that are harder to find a good cost function for.

Let's break it down. So if we're having labor costs, right, and let's say we have pipes, ducts, PVC pipe, we can get to the cost by if we know all the length of pipe that we need. We know long how long it takes to install that pipe. And we know how much it costs, the rate per hour of the labor in that pipe. We can now get the labor cost for installing the pipe, right?

Same idea for fittings. So how many fittings do we have? How long does it take to install the fitting? What's our labor cost? But see we need to know all this data first. We need to gather all this data beforehand.

Evaluating areas. So let's take ducts. If we know the CFM, then we can go into a data table. So here's a little bit of advice on creating algorithms.

So rather than using a ductulator for the CFM for getting the sizes, I created a data table. It's a lot more computationally less expensive. It helped with our standardization. And it's just a lot simpler. So we built-- so we have CFM come in. We look it up in a data table. That can even give us our costs, our labor-- all in that one data table.

With that, we can get the areas of the duct, again standard sizes. Then we can start to pack that stuff in. And then we get the square area using a [? packing ?] algorithm.

So now let's take a look at the static inputs for this problem. So the hardest thing was how do we define different systems and collect all that data?

So we came up with a whole bunch of different systems configurations that all have different rules and layouts. Maybe it goes out to the side. Maybe it goes into the corridor. Definitely need some type of heating and cooling in the bedrooms. Definitely need ventilation in the units. Definitely need exhaust in the bathrooms, et cetera, et cetera.

So we had all these different system types. Another static input is again our different apartment layouts. So with this, we know the layout. Where are the bedrooms? Where the kitchens? Where is my MEP closet for units? Where are my exterior walls for these units?

Then again, no data drop. Another big one is we had standardization on our thermal properties for walls, windows, ceilings. So we knew the glazing. We knew the R values, the U values. All right for automation.

So those I call the global. The ones before that are the global. It doesn't matter which project. Those stay the same.

And then we had the static inputs for project specific. So our configure air might bring in any shape. And we need to figure out the heating and cooling modes to that.

So to do that, we can take in these mass objects, apply our kit of parts for apartments. And then within an afternoon, run Revit systems analysis to be able to calculate our heating cooling peak loads. Pretty cool stuff.

And then of course that's a static input into our algorithm. Of course there's other stuff like building code, [INAUDIBLE] but I want to keep it simple.

So now let's go into the Geometry System. So really we have-- Geometry System is really just a combination of different algorithms that you can probably find on the Dynamo forum. Of course, there's huge community, not just in our space but in other industries, with all these proven simple algorithms.

So we can cluster points, we can group points, graph theory-- I think it's absolutely critical for MEP because we're able to calculate those flows, get those CFMs to go into the lookup table. And so that's what we do, right?

So we have this building. And we really want to make a graph representation of all the possibilities that the MEP systems could take. So we have our shafts, right? We always know we're going to be running the corridor. So we have our mains running through the corridor. There's mains always go into an MEP cubby in the space, or into the unit.

Each unit has spaces, right, some exhaust, some that need heating and cooling, some that need ventilation. Notice we built all the possibilities. So we also could go directly outside with exhaust. We also have nodes notice going through the different walls of the units. Those make up the different modules. So at some point we're going to have to cross a module.

So that would be a node. And I keep on saying nodes and edges because this is the representation with graph theory. You either have nodes or edges. Edges connect nodes. We can propagate flow by using this data structure.

So maybe our final Geometry System takes a clustering algorithm to find the shafts. Then we add a system definition. And then figure out the routing of the graph. And then we do our lookup table to get the sizes of whether it's PVC pipe, flex pipe, ducts. We can get the labor costs from those lookup tables. And we can go straight back to our evaluators.

Then we need a way to flex it, right? So like I said maybe the number of shafts is a variable. System types or system definitions-- just like the carts in Mario Kart, right? We have 40 different system types. Let's cycle through them.

The number of plants, are we going to do plants every floor? One major central plant, two major central plants, one major cooling plant.

What type of fittings are we going to use. Are we going to use those primo quick connect fittings that are going to cut down our labor? Is it worth it? I don't know. Are we going to use those cheap brazing? That's more cheaper but more labor intensive. That's the whole idea here is we can find that.

So if you look at the whole Geometry System as a whole, so stuff comes in. We have the architectural Geometry System. We have our apartment layouts. We make masses out of that.

We're able to do load calculations. We're able to bring in our system definitions table, do some clustering, calculate flow using graph theory, bring in our infrastructure data tables. From our graph we can find the length of copper, the number of fittings, and then calculate stuff like material and our labor cost.

So here I'm going to do--

[BARKING]

SEAN FRUIN: Pardon the dog. So time for the demo. In the Q&A I was going to do the demo. If you also want to dig into the graph a little bit more, look at the white paper. And

Just to kind of wrap this up on forward thinking. So I hope that you realize Generative Design is a way to discover new designs. We can really start to articulate the trade off between different parameters. It's really a goal oriented way of thinking, different in a way.

And then, of course it is a co-designer between humans and computers. The computer is not just going to do it. You need to put in data. You need to put in your knowledge. And that gets me over here to the triforce of knowledge.

So I think one of the hard things, and one of the things that I built-- Katara, these companies failed at, is they had a lot of technology, right? But they underestimated some of the engineering and definitely from my experience, some of the construction knowledge.

So to really pull this all off how I see it, right, you need engineering, architecture knowledge. You need construction. How is this stuff built? How is it connected? How does it come together? What's the electrical building code for this area of the country?

And then you need that technology. How are we going to organize this data? How are we going to build the algorithms to make all this stuff flow?

I do love the quote-- most people overestimate what could they can do in a year but underestimate what they can do in 10 years. So I think we're on this exponential thing. And what I really see-- the end being in sight-- and we're, at least I'm thinking about and going to. And of course the world needs it right with climate change, and the migration, and just the housing shortage now. You hear about the stats all the time.

I dream of the day that the algorithms, the building code, the procurement comes together with the architectural algorithm, and the MEP, and the fabrication, all in one algorithm. Then that goes out to the field and then the feedback loop happens, right? So taking all of our knowledge from all the different sectors and bringing them all together I think is really the future of design. And again finding multiple objective optimization of all these contradicting constraints. Thank you.