Creating Even Smarter MEP Families and Workflows Via Revit and Dynamo

ANDREW DUNCAN: Here we go. This is really horrible, because I want to be able to stand out here, but I can't see what's coming in. So I might walk backwards and forwards a bit.

So this is a follow-up class on one I did two years ago called "Creating Smarter MEP Families." How many of you went to or have seen that class, out of interest? OK, only about a dozen here. That's fine. How many of you have been to, or seen online, one of my other classes from previous AUs? OK, so about a third of the room total. Cool.

So let's say this is a follow-up class on "Creating Smarter MEP Families." This time we're going to be looking at a little bit of Dynamo thrown in for good measure. I'm going to keep asking you questions. How many of you have used Dynamo in any capacity? Good. Now, keep your hands up. How many of you would consider yourselves proficient Dynamo users?

[CHUCKLING] Half of them went, no! OK.

So the objectives of the previous class were making families with complex geometry that you can adjust parametrically. Creating family templates we're going to touch on again today so that you can provide users with things that they can finish off rather than start from scratch. Using formulas and families to do calculations-- we're going to talk about that in detail today. And how you can use access families-- we're not going to touch that at all.

These are the learning objectives for today. The first one, when I reread it, was horrific. So actually this is the slimmed-down version. And what we're going to do is we're going to learn how to create automated workflows that provide some optionality as to how the calculations are actually completed. I'm amazed there was a queue outside, but thanks for joining.

We're also-- and I'm going to caveat this. We're going to learn how to use Dynamo to automate a huge amount of work into seconds in an hour and a half. This is one of the learning objectives, so actually it's more like about half an hour of the class. And of course, I can't actually teach you the ins and outs of how you're going to use Dynamo to do that. But what I am going to do is share with you in quite a significant amount of detail our strategy in regards to how we're using Dynamo to do exactly that and take you through one of the tools that we've created inch by inch, and that will become clear as we go along, as to the techniques we use within Dynamo scripts themselves to make the scripts that we're generating, provide us with those sorts of efficiency [INAUDIBLE].

Absolutely crucial to achieving any of those efficiency gains is how you manage the data within your Revit projects and more so within your families and shared parameters libraries and so on. We're going to cover that in detail. And then I was deliberately obscure about a secret objective that I was going to plan to announce today. I am going to talk to you about that at the end of the class. It's not quite the announcement I wanted to make, but hopefully that will still resonate.

I also do need to cover off who I work for, because they pay for me to be here, and a little bit about who I am, just to give you some context. I work for a company called Arup. How many have you have heard of Arup? OK, good. Arup was founded by this guy in the '50s, I think. He was known as a philosopher. Ove Arup was known as a philosopher engineer, very deep thinker and wanted to provide total integrated design-- so bringing all engineering disciplines together and offering a holistic, whole solution.

We have offices everywhere. We've got lots of offices in the US. I am actually based out of London. I joined Arup circa 12 years ago now. I joined as a youngling. I'm now not so young. I now lead what we call the digital design development team for the UK-MEA Buildings Practice. UK-MEA Buildings is about 5,000 people. I earn-- no, it's not. It's about 2,500. people. UK-MEA is about 5,000 people.

And the work that we produce is used by that entire number of staff across the entire region. And actually, a lot of it is starting to be used across the rest of Arup as a whole. I'm MEP by background, you'll have guessed from the title of the class. I'm mainly mechanical. Every time I talk about MEP, I tend to talk about mechanical. But today I've got some electrical stuff in there as well.

I've got a background academically in doing services engineering, and a couple of years ago I did a masters in BIM and integrated design, which I thought would just be going to get a little bit of paper, but actually I learned a huge amount about lean production methodologies, manufacturing techniques. And a lot of that has informed my thinking since completing that course. I'd encourage you to go and look at lean yourselves.

I'm also a three-time Revit Gunslinger. Autodesk has renamed that now. It's not quite so PC. It's inside the factory. You get the opportunity to go into the Autodesk Development Offices, beat up next year's version of Revit, and help Autodesk to improve it. I'm very fortunate to work quite closely with Autodesk now in regards to developing the next versions of Revit. And I'm also-- this is my seventh AU, and it's the fourth I think that I'm speaking at. After the five classes, I think this is the sixth.

I'm also somewhat of a general technology nerd. I like to do things like control my lights from my watch when I'm away at conferences to wind up the missus. And I was looking for opportunities to use Animojis in my presentation, but I've been quite restrained and managed to not do that too much.

As I say, I lead digital Design Development. And the remit of that team is effectively to look at anything that improves efficiency, improves the quality of what we do, or reduce the risk associated with the information that we eventually throw at our clients. That kind of adds up to everything, which is quite nice for me. It means I can be quite nosy and stick my nose in wherever I want. But effectively what we're trying to do is fulfill our deputy chairman's ambition. He's one of the guys that looks after digital for Arup, which is reducing the effort to do the usual, the necessary, in order to provide more time to be innovative and creative. And I think everybody would quite like that in regards to their general day jobs and how they go about the business.

The way that we're doing that at the moment is to look at the processes that we commonly undertake in projects, and then to think about the data that is required in order to complete that process. So if you can isolate the data that informs a standardized process, you can create a data structure and an automated workflow that, say, would consume that data structure, which ideally provides more value out the back. It's more efficient, it's better quality, it's reduced risk, and so on. And then actually what you can do is you can continually learn from and improve that process over time by revisiting your thought process, revisiting the data, and continually iterate it.

So that's kind of where we're going to start. We're going to look at how to create automated workflows and specifically-- as I said, somewhat as a follow-up to my previous session-- providing optionality around how we complete calculations within families is particularly important in that respect. So we'll cover a couple of the-- well, the reason why that's important and then the techniques as to how you can actually do that yourself on your own projects.

If you think about-- I mean, I'm the consulting engineer. So this is the sort of stuff that we typically produce on projects. We do lots of calculations, we produce drawings, we create models, we do analysis, we do all sorts of stuff to create reports, datasheets, specifications, lots of unconnected deliverables that eventually leave the door. And unfortunately for us, we have to use a huge amount of different bits of software in order to do that. Now, this is just the tip of the iceberg of the software that we use. Apparently someone did some sort of study. We've got 14,500 members of the staff. Someone did a study a little while back, and we worked out that we're using 14,000 pieces of software, which is bonkers.

But basically, where we are today-- and I think it's as true for Arup as it is for the rest of the industry. We're not alone in this. Most of these bits of software are silos. And especially Excel is particularly guilty of being silos, not only to whole businesses but to individual members of staff and engineers as they go about their daily work. You know, most people sit next to someone who's doing a similar sort of thing to what they are, but they tend to use different spreadsheets to do it, because they don't trust the guy they sit next to or the spreadsheet that they've put together. It's bonkers.

So in order to-- Andy what's-his-face, the new CEO, stole my thunder and used this slide basically exactly the same as I did yesterday. But in order to be more efficient and to think about things in an automated way, we have to think about how the data flows through a process such that the next process is geared to receive the data that we've produced already. And then what we wanted to do is try and daisy-chain those things together. In order to do that, we need to be much more structured around our thoughts processes in regards to the processes we undertake on projects and how we're going to feed data into those processes to generate a final outcome.

This is a very simple process. It's one that I've used in previous classes. This is around heating design and the steps involved. So we generate some heating loads at one point. We then size the equipment, or if we're doing it again, resize it, divide the heating loads over said equipment, calculate the water flow rates, and then eventually size pipes. And if you look at that as an overall compound process, these are the different bits of software that we, as Arup-- say, kind of UK skewed, because lots of people use different tools for heating loads-- these are the tools that we use in order to undertake those processes, typically or historically.

And the reality is that pretty much the interfaces between all of those steps are manual. If they're in spreadsheets, they're in different spreadsheets. They're being done by different people. They're being marked up, put on bits of paper, and given to other people to interpret into what is the final deliverable, which is bonkers.

So what we want to do, as I said before, is think about what is the process we're undertaking, and what data do we need in order to inform that process? What we also need to do is structure that data far more so with a much greater degree of rigor than we would have done previously if we're going to be able to pass it from one task to the next to the next to the next. And the way that we've been tackling that from a strategy perspective is using Revit as a database.

I don't like to describe Revit as a 3D-modeling program. I describe Revit as a database that happens to be able to express itself in 3D. Someone else described it to me as a database with lipstick on, but you take whichever definition that you want. An effectively, once we've got a structured database-- and unlike Excel, if you put a number into Excel, it's just a number. You put a water flow rate into Revit, it's a water flow rate. You try and convert it into a voltage, and Revit will just give you a horrible error message saying "inconsistent units," which I'm sure most of you have seen before.

Once we've got that consistent database, we can then start to think about the tools that we're going to use in order to pass information from one task to the next in that database and how we're going to churn through that data in order to achieve the next thing. And in this instance, we're using Dynamo, Revit functionality itself, because Revit can do things like size pipes, so why create a custom tool to do that? And very specifically, and the first thing we're going to look at, is using formulas in families to undertake formulas that would otherwise be done in spreadsheets.

So this is old slide of an old tool that takes heating loads for a space and divides the heating loads within that space over the heating equipment in the space able to provide heating. That just about made sense. This is something that Revit doesn't do out of the box, so basically, as we adjust the heating load, you can see it's dividing over the different pieces of heating equipment. And then what the heating equipment is doing is using formulas within the families to calculate the water flow rate, which goes into the pipe work, which then you can use to size the pipes automatically. All right, class done. You can all go.

No. So what we're going to do-- if I can skip on-- this is part of-- it was one of my old classes. I think this is the "Creating Smarter Families" one. Basically, this is the formulas that we put within the families to work out what the heating load is. So you've got-- or heating water flow rate. So you've got the heating load, and that goes into our formula. Don't do that. That's horrible. OK, you don't really need to see the background, but we've got a water density, we've got a specific heat capacity, a [INAUDIBLE] without delta T, and so on.

What that does is calculates our water flow rate. So you're using the information we're storing within families, combining that together into a formula, and using that to calculate what would otherwise be a manual process that doesn't live within the model. However, the reason why this is starting off this class is because when we actually went to turn this from effectively a proof of concept to demonstrate how Dynamo and Revit could be used to automate this stuff, we found that because this uses a formula within a parameter, that parameter is locked to only use that formula alone, which means that if someone wants to enter a manual water flow rate, they can't, which means they can't use the families, which means that absolutely every project Arup ever does in the UK would have to use the heating load to derive the water flow.

Now, although I think that's a good idea on the majority of projects, I can appreciate that there are instances within a model you just want to give something a water flow rate. So what we need to do is think again as to how we are going to facilitate that sort of functionality for our users so we could incorporate these automation techniques using formers and families but also provide them with the opportunity to do something different, as in when the requirements of the project dictated that was necessary.

So the way that we overcame that was with the Selection Method Technique. And that's the first thing I want to cover for you in this class. Selection Method Technique relies on if-statement formulas. I'm waiting to see as to whether or not this is something that you guys find revolutionary-- because I don't think if-statements are revolutionary-- or whether or not this is something that you find a little bit more mundane. But the reality of implementing this workflow for us was that by using if-statement formulas and combining many different calculation methodologies with a Selection Method, we were able to implement effectively the workaround that allows us to use this on all of our projects now.

So an if-statement, for those of you that might not be aware, is a logical test combined with a value if the logical test is found to be true or a value that it'll give you if the logical statement is found to be false-- ie, you ask the question. If it's correct, do this thing. If it's wrong, do this other thing. And what you can do with if-statements is you can nest them, as you can with any other kind of formulas, really. You can nest them into one another.

And if you do that-- and this, I colored it so it's slightly easier for you to understand. But actually, this is also-- I've just copied and pasted directly out of a Revit family I've put together. And I don't know whether you can paste it back in with the line breaks. I need to double-check that. But this was a particularly good way for me to work out how the if-statement all goes together.

Effectively, if you got three tests or three different questions you're asking, you have three brackets at the end. You're opening a bracket every time you ask a question. You need to close the brackets at the end of all your questions. That means for every question you ask, you have to have your brackets closed at the end. So three tests is three brackets, n tests is n brackets.

And rather than focus on the water flow example that I showed you before, I'm going to use another tool, which we're going to go through in detail in a moment-- the Automatic Mechanical Power Supplies tool. Those of you that are electrically inclined will realize how awesome that name is. And the reason we're going to do that is because the formulas we use in this are exactly the same and structured in exactly the same way as the water flow example, except the parameters are shorter, so they fit on a PowerPoint slide.

So we've got our Electrical Power Selection Method. And our Electrical Power Selection Method is an integer family, or an integer parameter. It is going to allow you to select one, two, three, four, et cetera. Not 1.1 or whatever. You can use a number parameter if you want. They just look horrible.

We're also going to have an Electrical Power parameter. And the Electrical Power parameter then references a number of other parameters using if-statements. So if our Selection Method parameter is set to 1, I want the electrical power to reference the Electrical Power Full Load parameter. If it's set to 2, I want it to reference the Electrical Power Running parameter. And because you have to have a value, if the logical statement is found to be false, if it equals anything other than 1 or 2, give me a really, really stupid power that couldn't ever possibly crop up on a project so that my engineer knows that something's gone wrong. One day in the future we're bound to have an engineer oversize the building by 400 times because they've not realized that the number is wrong, but we'll cross that bridge when we come to it.

In order to reference a parameter, you then also need to create the parameters that are referenced. In this instance, these are manually entered values. And what this is doing is it's providing our engineers within the AMPS tool-- and I'll show you a demo in a moment-- to use the value that they need in order to size the piece of equipment in the context of the building that they're actually placing that equipment into, or the design that they're placing it into. Not only do we do this for power within AMPS, we do exactly the same thing for Current. These are the Current parameters, the Current formulas, and what we have to put in to make this work.

And I'm also, at this point-- because I've been asked once or twice already, going to cover off a question that I'm sure I'm going to be asked otherwise-- there isn't a handout for this class. These slides are your handout. You're here to listen to me and hopefully for me to be able to share with you what we've been working on and how this works. I'm going to-- there's been a lot of work going into this presentation, and I'm showing you a lot of what we've been doing as a business. And unfortunately, any of you that have attended any of my classes in the past will know how excellent I am at producing handouts. I think of the five classes I've done, I've done one handout. And that was the only class I did with a co-presenter. Guess who did the handout.

So I put a lot of details into the slide so that I don't also have to do a Word file. Any of you that take issue with that, that's fine. If you don't want me to come back in the future, please select that rating in the surveys. Those of you that do want to hear me again, this is your handout.

Anyway, right. Demo-- so this is what AMPS looks like. And by putting in those Selection Method parameters, what we've got over here here is we've got the electrical information about the mechanical kit that's been entered ideally by the mechanical engineer at the top. Then the electrical engineer can run through that data and choose the data they want to use in order to inform the outcome from what is ultimately going to be a Dynamo script.

This means that they can choose the values that they need in order of the context, the building that they're working on, or the design of the system that the equipment is being entered into. So we've got the ability to choose between full load power, running power, and then starting current, running current, or a current calculated from the chosen power, which uses a formula in the family to generate that.

Once we've made those decisions, and-- oh, rubbish. Here you are. Make sure you're on it. There you go. Bear with me. I thought I hadn't included [INAUDIBLE], but I have. Once we've made those decisions, we're then able to use Dynamo script. It looks a bit like this. It's big, scary, and the only thing the engineers need to know is it's got a Run button. There's no other means of interacting with it.

And basically, by pressing the Run button, every piece of mechanical equipment gets a power supply. Not only does it get a power supply, it gets the right type of power supply for the mechanical equipment. So a boiler gets an isolator, a [INAUDIBLE] beam or a [INAUDIBLE] unit gets a fused spur. In addition to that, all of the electrical information from the mechanical equipment is transferred to the power supply. A link is created between the two. So if you close the Dynamo script and reopen it, run it again, they don't all get another power supply. Only new pieces of equipment get a power supply.

And then if you have a Duff voltage value, if you've copied one of the supplies to another piece of equipment and then rerun it, if you've not got a power supply big enough within your project to actually provide a supply to the piece of equipment and a couple of other things, the script will also color in the objects to say, something's gone wrong, you need to pay attention here. Other than that, this automates pretty much weeks of work into seconds. And it is only able to do that because we're providing the optionality-- which could be in the Dynamo script, right, we could put the Selection Methods within the Dynamo script itself-- asking people to interact with a schedule and select some numbers on a column with that number in it. I know from experience it's a lot easier than saying to someone, OK, I've just about made you less scared of Revit. Now I'm going to introduce you to Dynamo. And within Dynamo, there's all these nodes. And this little slider thing changes how it works. And you just watch someone's head explode if they're not used to interacting with that sort of stuff.

So this Selection Method technique with a formula embedded in a family provides a simple and easy interface so it can figure how you want something like a Dynamo script to run. But it could just as easily reference a formula that exists within a family. So that's what we did on the water flow version. These are the parameters and the formulas that go into the water flow example that I showed you earlier.

And in this instance, what we ended up doing is having a water flow rate heating parameter that referenced a formula that could base the water flow rate on the heating load, one that you could base the flow rate on the heating capacity, should you say, actually, I want to just-- this thing needs to be able to cover off the absolute max that this piece of equipment would ever, output-- which I don't expect people to use very often, but we can provide it as an option-- and the ability to just reference a manual valley, which is what we were talking about at the beginning of the class. So now they can use the automation tool that we've created that allows them to automate that effort into a significantly short period of time. But they can also, should they choose to do so, actually just say, no, set it to 3, and this is the water flow rate that I wanted to go into the system.

Something I've kind of skipped over with this is, I think we've got lots of parameters within our library. This is an excerpt of all of our parameters circa two years ago. There's a couple of thousand of them that we went through. I painstakingly went through and had to name about 3/4 of them myself. They're named hierarchically, they use engineering parameter types-- so a water flow is a water flow, a current is a current, et cetera-- and we looked at all the standards out there and decided that there was no one standard that fits on these, so we just added another one.

But as standards start to homogenize in the future, what we can do is either map our stuff to a standard as it arises, or we'll just swap everything out and start again. The reason for mentioning that is that all those parameters go into the Revit standard that we now use across the entire UK within Arup. Ideally, we'll be using that across the rest of the world in Arup at some point in the near future. Some other parts of the business do use what we've done. Some other parts of the business don't, and that's just a matter of the autonomous nature of the way Arup does business.

But the reason why I cover that is, effectively things like the Selection Method Technique I've just shown you and AMPS allow you to ask questions of your model. And the only way they allow you to ask questions of your model consistently is if you've got consistently structured data within your model. Use different parameters in different families. If you use families with different names in all of your different projects, you're going to really, really struggle to do anything in regards to automation, or especially things like the formulas, but particularly in regards to Dynamo.

You know, the simplest example of asking a Revit model a question is using a schedule. You create a schedule, say, I want a table of data that shows me the values for this parameter and this parameter and this parameter. This is an example of the equipment data sheets we produce out of Revit for a handling unit. If you understand how-- well, I gave an explanation of how to build this air handling unit in my previous class, the previous class to this one, the "Creating Smart Families." If you've got any questions about that, come and ask me afterwards.

But I would not want anybody ever to have to create all of these tables from scratch because we've used different parameters in different families, and that's been inconsistent. Actually, what we've done is we've been able to create standardized families with standard parameters with standard schedules that go in our standard template, which means that everybody, as standard, can put that all on a standard sheet-- really quick and efficient. And actually what we've done-- I need to put some more work into it-- is create an automation routine that says, click on the air handling unit, and it creates the sheet for you. It just dumps all of those tables onto the sheet, pulls the data down from the families, asks the questions that it needs to, and gives that back to you as a deliverable.

So what we're going to talk about now is how to use Dynamo to automate huge amounts of work into seconds. And actually, I don't think it will come as any surprise-- or we'll cover this quickly first-- as I just said, we need consistent data. And once we've got consistent data, consistent data is what unlocks the opportunity for us to have consistent workflows. The way that I'm defining consistent data is to think in regards of your Revit parameters and your Revit families. If you've got consistent parameters using consistent families, you can start to develop consistent workflows. Those workflows can express themselves both in terms of standardized Revit workflows-- ie, the schedules that I was just talking to you about-- they can express themselves in terms of formulas, so being able to reference one value from another within Revit, or in terms of Dynamo. There's other ways as well, but these are the three that we're talking about today.

And once you've done that, you will be able to consistently generate the same type of project output. So you've got projects that you can start to ask questions of. And what we're going to do is go through the workflow example for AMPS. So this is the process that will typically be undertaken by an electrical engineer on a given project. Again, you can map the software to it. And again, the interfaces between these are all completely manual. To go over how-- well, at least the way we used to do it, I'm all for full exposure and honesty in these discussions because there's far too much misinformation that gets bandied about. The way that a lot of people still do this is, go print off a drawing of the mechanical design, go sit in the corner of the office with a red pen and a laptop, and work out, OK, that's a fan coil unit. What's the-- OK, I need the [INAUDIBLE].

OK, that's going to have an oscillator, and it's going to be this size. And I'm going to draw it on a red symbol on a bit of paper. And I'm going to do that for about three days and then give it to a technician or a drafter to then convert into a drawing, by which time the mechanical engineers change the design and I have to loop back around and do the whole thing again. That sound familiar? Yes, OK. That's what we all do. Welcome to the construction industry.

And what we're going to do is think about that process in a different way, think about the data that we need to actually undertake that process, use Revit as a structured database that can carry all of the information that we need to produce, and then think about how we're going to undertake the process differently in order to generate the data that we're ultimately going to store within Revit itself. We've already covered off how to use formulas and families in Selection Method Technique. AMPS does all this bit. And actually, you can kind of extend it left a bit as well, because we're using Revit to input the data upon which the AMPS tool runs.

So there's quite a lot to cover there. And I've already shown you, AMPS will do that lot in seconds rather than in weeks. And I have to admit, I was a bit pained as to how I was going to go through this and do this with you in in half an hour. But actually, if we get the PowerPoint working again, unlike most people, I don't think about Dynamo as a tool for generating funky parametric geometry. This is a video that I nicked off of the Autodesk website showing you how to do a pylon or column thing, create different lines of different lengths. And you can use sliders to make it taller, shorter, and fatter and thinner and all that sort of stuff. And that's great for structural engineers. That means absolutely nothing to me as a mechanical engineer.

We did a session two years ago on how to use Dynamo for MEP. And effectively, the way I use Dynamo is as a really funky calculator that can do all sorts of stuff and interact with 3D geometry. This class covered things like nodes, as you'd expect it to, and the details as to how different nodes work. It also covered list structure. Lists are incredibly important within Dynamo. If you don't understand how lists are passing through a Dynamo graph, you don't understand Dynamo.

We also covered things like lacing within Dynamo-- lacing and how you lace nodes together, not the little line between nodes. Lacing is the behavior of a node. You can make it behave either shortest, longest, or cross product. And Dynamo team, of which there's a couple of people here today, keep changing the way that this stuff works. But this is really, really important in regards to how you use Dynamo.

And I don't think it's going to come as any surprise, we're not covering this in detail today. I've done a class on this before. You can go back and look at that class. There's an hour and a half worth of material for you to go and learn about how to use lists, how to use lacing, and effectively learn that there. This session is going to tell you about how we take these principles of effectively using Dynamo. We've got an input, you use it to perform some sort of function, and then you generate an output. In regards to AMPS, we've got some data. We've got some mechanical equipment in the model. We're going to use all of that data to effectively derive some outcomes through many different functions that are chained together.

So just to cover back off some of what AMPS does, AMPS-- and let's stay here to read this-- AMPS automatically creates power supplies for any piece of mechanical equipment. It does what it says on the tin. It automatically sizes each of these power supplies. So if you got a certain amount of current, you get the right size power supply. It automatically transfers all of the data from the mechanical equipment to the power supply.

It creates a link-- and the way it does it, because we don't cover it in detail at the moment-- is it transfers the GUID of the mechanical equipment to the power supply and the GUID of the power supply to the mechanical equipment, so that they each understand the exact reference to which they relate. And it draws a temporary Dynamo line between the two, which is quite cool. And it highlights any element that's causing an error to occur in regards to the tool.

This is what AMPS looks like. It's quite a lot of nodes. Trust me, there are some nodes there. Someone in the office said that they'd go through and count it for me, but they haven't done that yet. I think it's probably a couple of hundred nodes chained together. But what this is is effectively the same engineering logic that an engineer would otherwise apply going and sitting in the corner of the office with a red pen and marking up drawings condensed down into a logic diagram that uses the model as the basis of what it's going to do to undertake task and automate it all for you.

And what we're going to do in order to cover off the techniques that we've used to generate this tool is actually walk through the tool bit by bit. And we're not going to cover of the function of absolutely every node. We're not going to talk about how the list passes through it at all, because I said you can go back to the other class. But there are some specific things that we're doing and some techniques we use over and over and over again, not just in this tool but in many others that I'd like to think you can take away and apply to your own problems to come up with your own solutions. So it's really difficult to think about how to frame this in such a way that you can take away something useful. But I really hope going through this in some detail gives you the ability to do that.

It does also mean, unlike in this view, you'll get to see the majority of the nodes how they are actually laced together and the lacing that's been applied to each of them. So if you want to go away and try and recreate certain portions of it, you can. So all of that detail, as shown here-- you can't quite see it probably [INAUDIBLE]-- you kind of can see it-- the names of the nodes so you understand how the things work together.

And you can also see the top right hand corner. Got a little key showing roughly where we are. That's going to keep stepping through just to kind of show you roughly where we are on the kind of awesome map that is AMPS. So we start off with asking the model what elements it has. And we start doing that with a very specific node that-- I keep getting static shocks off of this-- that only references the elements in the active view. That's a conscious choice for two reasons. One, we don't want to do anything to the model that the engineer can't see.

You could do it to the entire model if you want. If something goes wrong on another floor, how are they going to know? So, in this instance with this tool, we use AMPS to automate all of that stuff for one floor at a time. Having done that, we then also retrieve some information from the elements that are on the active view. The first piece of information we retrieve is the Revit category. So I want to go and find only things that are-- well, I want to find them the categories of all the equipment that's been-- all of the elements that have been selected on that view. Then I go and ask each of those elements, are you either a piece of mechanical equipment or a duct accessory? The reason why I ask for those two things is because they're the only two things we've configured AMPS to be compatible with thus far.

In reality, you could probably also do the same thing for pipe accessories with actuators on valves and that sort of stuff. You can extend this further, but that's the way it works today [INAUDIBLE]. And then we take all of the elements that we selected from the active view, we take the information that we've retrieved from each of those elements, and the result of the question that we asked, are you a piece of mechanical equipment or are you a duct accessory, and then we run that through a filter. And we use that filter to get rid of everything that isn't a piece of mechanical equipment or a duct accessory. And that's achieved through the [INAUDIBLE] using these nodes called Filter By Boolean Mask.

Now, I've had the opportunity to run for some of the Dynamo team through this, and they've said, you use a lot of filters. And yes, I do. The way that I go about doing a lot of my work is I use loads of filters to go through and start off with a big question and slowly whittle down that big question into more and more specific data. You're distilling your model. When you interact with Revit generally, through Dynamo, you can only really start off with some really big, specific questions. And then I use these filters to filter it back.

This is an example of how we're actually using this in a way that you can see actually within the list structure itself. So on the left hand side, we've got a number sequence, 1 to 10. We've then got a test in the middle. Are those numbers less than or equal to-- and in this instance, 4. And what you can see is, you get a list of true values and a list of false values. False is where it's not less than 4, or less than or equal to 4, and true is where it is less than or equal to 4.

And then what you get out of the back is two outputs, a list of things where that was found to be true and a list of things that were found to be false. Now, in the first instance where we start off in this script, everything that isn't a piece of mechanical equipment or a duct accessory I don't care about at all. So I have nothing that comes out of-- and these need to be renamed, but you've got an in output and an out output. The out output is the stuff that failed the test. The in output is the stuff that passed the test. In this instance, we don't do anything with the stuff that failed the test because we don't care about it. We're not providing a power supply for a wall. We're only providing a power supply for mechanical equipment or duct accessories.

Then, next part of the script, as it slowly chugs its way along the graph, is asking another question. Right, I've got a piece of mechanical equipment. Does it actually require a power supply? Revit defines mechanical equipment as a very binary thing. It's just mechanical equipment. We all know that mechanical equipment actually expresses itself in terms of things like radiators, fan coil units, AHUs, and, and, and, and.

What we also have to do, because it doesn't come with Revit families out of the box, is tell the piece of equipment it actually requires a power supply. You could potentially use another technique to actually go and find out if there's an electrical connector within the family. Actually, to my mind, that doesn't necessarily mean it requires a power supply, because it might be a power supply. That's actually where most of your electrical connectors are created.

So what we do is we add some family parameters into all of our mechanical equipment families that tell the model what types of systems they're connected to. So a fan coil unit, or a heating and cooling fan coil unit, for example, would have a cooling connection, a heating connection, a power supply, and a condensate drainage output. A cooling only would have all of the same bar the heating connection. What we can use this for is we can use it in things like this Dynamo script. So we go and ask every single family that has ever been created in our library, do you have an electrical power connection? If you do, right, you're going to need a power supply.

What we can then also do is use these parameters to configure things like our view templates. So what we do is we say, anything that needs-- anything that is mechanical equipment that requires a power supply we want to be shown on the electrical drawings. But we show them grayed back, and we use the filters within the view templates to gray back those pieces of mechanical equipment, but still show them so that you don't just see whole loads of power supplies floating in midair in the hope that one of them might actually be attached to something. You see a power supply hovering over a gray box, which is a fan coil unit or a pump, whatever. So we use this data structure to provide more intelligence to the model itself.