Creating Smarter Revit MEP Families

ANDREW DUNCAN: Good afternoon. Hello. All right. My name is Justin Bieber.

[AUDIENCE LAUGHING]

That's what I feel like stood up here, anyway. Reality is, I'm just the same as you guys. Today I'm here to talk to you about smart Revit families and getting some additional value out of Revit. My real name's Andrew Duncan. I work for Arup in London. We're a large engineering design consultancy. As a say, I'm here to talk about getting more value out the content you create for your models. I've just given this class, actually. This is a repeat for everyone on the internet and you guys.

One of the things, in terms of what we're trying to do, is keeping in mind that every bit of content that we create is to inform the creation of a building. And if we can do that quicker, more efficiently, more high quality or reduce the risk of what we're doing through the families that we're actually using, that's a benefit. And hopefully some of what I've got to show you today is trying to take some of those principles and embed them into the content you're actually going to create to create the buildings that we all work on.

The learning objectives for this session in particular are to make some complex geometry families that are easy and simple for people to use and modify. We don't want something that's really difficult to change. It needs to be quick, easy, and efficient. We also are going to look at things called template families and template families are kind of a hybrid between a raw Revit template for a family and the finished product.

How can we kind of take it half the way along, put someone on a journey to get to the finished article that would otherwise be really difficult for them to do on their own for highly complex units such as their handling units and so on.

We're going to look at formulas and how we can use formulas in families to automate calculations and that sort of stuff. And if you get time at the end, we'll also look at access zones in families. If we don't get time it will be in the handouts and it will be on the slide, so we'll see if we get there.

As I say, I'm Andrew. I've worked for Arup for about 10 years. I'm a technician by background. Predominantly MEP but mechanically biased. I am a IEng qualified engineer, that means I'm almost qualified to be a full engineer the UK, just not quite. I finished an MSc in BIM and integrated design, recently.

I don't mind admitting, I did that to get a bit of paper but, actually, I learned a lot from the process. So if you get the opportunity to do further academic study into things like lean construction, IPD contract, I'd really suggest that you pursue that. Additionally, I've also done gunslingers twice, the Revit Gunslingers. Get in, meet the Rivet team, tell them what you want and hope that makes it into the product. It's now called Inside The Factory and again, if you get the opportunity to take part in that, I couldn't recommend it more.

Finally, I'm also somewhat of a general technology nerd. I've got my Apple Watch, my Apple Watch talks my light bulbs at home, my light bulbs talk to my thermostat. They're all at home talking now. I don't quite know what they're talking about because I'm here, but it seems to be working OK.

As I say, I work for Arup. This is Ove Arup, the guy that founded the company that I work for. Ove Arup was known to be a philosopher as much as he was an engineer and, actually, what we try to do and the philosophy that we undertake in our design processes, is to think in a multi-disciplinary way, such that when we're making a change we try to make sure that everybody benefits from that change or we take everything into consideration. And that definitely feeds through into what we're going to be talking about in families today.

We're a global firm. We've got something like 12,000 employees today in about 90 different offices in lots of different countries. I kind of forget where we do and don't have offices because it changes quite a lot but we're kind of everywhere. Equally, these are some of the buildings that we've worked on. Some of them you'll recognize, some of them you might not but the output that comes from us as a business is highly varied, often very complex, often working with very starchitecture type firms.

And I'm very proud of a lot of the work that we do. Given that we were in Vegas, I should also mention we did the high roller. I went on that last year, it is really good. I'd like to go on it at night because I think it'd be even better. But, yeah, that's something else we've been involved with as well.

A lot of the learning that comes out of this class in particular is based on this project. This is me in Revit form. If I kind of stand a bit like that it maybe looks a little bit like me. I was freely laser scanned, turned into a 170 meter tall tower filled with services and all sorts of other rubbish. The idea behind that was to explore the potential, with the tools that we had available at the time, to see how far we could push them. It was an AU class, you can go find it at the link in the top left corner. And we did all sorts of clever things, in terms of automating systems and calculations and so on.

But when we actually took that learning away and we tried to use it on real projects, we found our family library was nowhere near intelligent or complex enough for us to actually apply it across the multitude of projects we have as a firm. So we decided to kind of go back to the drawing board. And this was a meeting we had about 15 months ago, where we sat down and tried to determine the specification of what we wanted our family library to be. What did we want to achieve from using Revit. We know we can use it for 3D modeling but there's a whole lot of other benefits and what do we need to put in place in order to realize some of those benefits.

Once we'd written that specification we then locked a whole load of the people in our Revit content dungeon. We didn't let them out until they churned out loads of families. We did that on multiple occasions. Did it in London, did it in Birmingham, we did it lots and lots of times, probably five or six. And we've now generated about 3/4 of all the content that we would like to generate moving forward as our core content library.

That means that now we have our Arup UK, Middle East and Africa Revit content library and templates. And all of that is used by up to four a half thousand staff across the firm. Everybody uses the same stuff. The next challenge for us is to then try and role in the other global Arup regions so that we can then exemplifying the value of that effort even further.

So now that we've written our specification, what I want to do, this session's effectively playing back to you the journey that we've been on in terms of creating that library and what we've done, why we've done it and how you guys to do it yourselves in your firms. So thinking about families again in that specification, what is it that we actually want a Rivet family to do.

So the first and most obvious thing is we want a 3D model. Right. This is a project that I did a couple years ago. This plant room is about 100 meters long by 100 meters wide. It's got 17 handling units in it. And this to me is a really good example of how we can articulate the complexity of the designs that we undertake today. And the families that we need to use in order to create this need to show the appropriate level of geometry, need to have the right connector settings, need to feed into our templates and so on. This is kind of like the base requirement of what we're generating in terms of our content.

However, although this stuff's going to be 3D, actually, the most important thing today in terms of where we are as an industry is that it also outputs high quality 2D drawings. If we can't articulate our design in 2D, it's highly unlikely that the next person in the chain is going to be able to consume the information that we're producing and use it to inform their own processes. So again, it is really important that we actually prioritize the 2D drawing production aspect of what we're trying to achieve.

In addition to that, there's other non model and drawing deliverables such as COBie. I'm not a massive fan of COBie. I don't expect that there's anyone in this room that's particularly offended by that. But if we're going to undertake modeling processes, we want this to be as automated and as easy to put out the model as possible. And there's things that we can do, in terms of the content we're creating, in order to facilitate that.

Additionally, we looked at other deliverables that we could then take out the back of our models. So one of the primary things that we need to produce on most of our projects or equipment, data sheets, they are all of the non geometric information specification that we want someone to meet when they're going to swap in a specific component for our generic design.

In this instance, we chose to prioritize 95 different categories of equipment. Now, you can imagine that leads to a whole load of engineering variables and parameters that need to be created and we're going to talk about some of that in the presentation. And then equally, and this is drawing on some of the work that we demonstrated with Project Ove and some of the work that I demonstration in an AU class I gave last year. We want to use the families as a design tool. So we want to embed calculations and formulas within to the families themselves so that they're actually computing data and showing us, as designers, what the effect has been on the design and how it needs to be optimized and changed moving forward.

So that's the kind of specification we were writing for our smart families. So before we go any further, as I say, I'm one of you guys. I'm standing on here and I'm sharing our company's past, present and future in terms of our development. That means that you may not agree with some of what I have to say. Hopefully you will but if you don't, that's great. We'll have a debate about it afterwards. We'll have a good conversation. But Revit is a very malleable tool. It can be used in a number of different ways and I'm sure you'd certainly use it in different ways to the way that we are, in some of the ways it would be really similar, but lets have a discussion about it afterwards.

So, creating families is somewhat of a dark art, a mixture of lots and lots of different ingredients that you combine together to get some sort of output out the back of it. The way that I've kind of articulated that in this presentation is that we've got this stuff that we're going to combine together, and that's a number of different categories of things that we need to address in order to get the most value out of what it is we're creating. So we're going to look at parameters, we're going to look at geometry, we're going to look, or mention briefly, connectors and how important they are. We're going to look at formulas and we're going to look at these things called family templates that I was talking to you about before.

So, starting off with parameters. Parameters, by the way, aren't on one of the listed learning objectives for this class and I'm going to talk about this for about 10 minutes. So it's going to take us a good 20 minutes of the presentation to actually start on what you turned out for. But hopefully you find this valuable.

What differentiates building information modeling from the 3D stuff that we were talking about before. I've worked for Arup, as I say, for nearly 10 years, I've done 3D modeling the entirety of the time that I've been there. Using Revit facilitates us getting to the information and using it for a whole load of different purposes.

In terms of how we articulate that in Revit, we use parameters to store information. There's lots of different types of parameters that can be used for different things. You've got family parameters, project parameters, shared parameters that can be used for almost everything and then calculated values in schedules that have their place but are very difficult to actually get to if you want to do anything with them.

Of course, if you're using shared parameters as project parameters, they can also be tagged alongside all the other stuff. But there's definitely disadvantages to loading shared parameters into project parameters for everything and using that as the way to populate your content because if you put a shared parameter into a mechanical bit of equipment that has a specific function, it's going to go into all of your bits of mechanical equipment. So, actually, we need to think very carefully about how we create the parameters we're going to use and then how we put them into the models, families or projects that we're going to be using to actually describe our designs.

Autodesk also just recently created this new thing called global parameters. I have nowhere near enough information to actually talk to you today about how they should be used. I know that they don't have a huge impact in terms of how we're doing our library, moving forward, we have had a short review of them. We're not going to cover those today. We are going to, however, major, very heavily on shared parameters. Share parameters was what we wanted to do in order to create all of the data, all the information that we are feeding into, the models and libraries we were going to create moving forward.

However, shared parameters are quite constrained in the way that they're created. They're created with a unique identification code. They want to have a name as a one time created only thing and once they're created they're very difficult to change. So we have to be very careful how we went around creating the list of parameters that we wanted to create. How we were going to name them, how we were going to choose what types of parameters they were going to be and then how we were going to push them into the content.

As I said before, in terms of the information we were actually targeting to produce, we looked at lots of different areas for inspiration in terms of how the model would be used moving forward. So we've got [INAUDIBLE] as I mentioned before, we've got COBie, but then we've also got things like the new rules of measurement. So if we hand our model over to a [INAUDIBLE] they can take that model and use it for costing purposes. Equally, things like Uniclass, where we can automatically inform software that can read the code and understand in more detail, what has actually been offered into the model and again, use that for additional purposes.

We also then went about a process of creating a lot of parameters to be put into spaces so that we could use that to create new data sheets. And then our structure colleagues focused a lot on the Blue Book information, which is a particular catalog of data used for fabrication processes.

This is how many parameters we have today. This is, basically, every parameter that we have underneath that specification is a unique engineering variable according to one of the bits of equipment that we were looking to create an equipment data sheet for or for rim data sheets or for calculations, and, and, and, and.

But now that we've got this list of parameters we can start to put it to work within our families. The way we actually created them was to use a couple of different tools to make that process, in itself, far more efficient. So we used the Rivet SP writer, which is produced by a guy that used to work at [INAUDIBLE] or maybe does still work at [INAUDIBLE]. That's free. It's an Excel spreadsheet and it will create the GUID for you, it will allow you to name it and then it will write out the shared parameters file specifically.

We use a slightly customized version of that so we can track which parameter is going into which equipment category type. And then we also use the CTC BIM Manager suite, which is a paid product, and we use that to create automated templates for pushing large quantities of parameters into specific families of specific types. That made our processes, in terms of filling out families full of data, far, far, far quicker. And we literally saved weeks and weeks of time by using that tool.

This is the spreadsheet that actually happens to house all of our parameters. As you can see, it's very large. We came up with the naming structure ourselves. We looked at Autodesk, we looked at IFCs, we looked at all sorts of other stuff. We ended up focusing on a hierarchy based system that allows you to read from left to right the generic to the more specific version of the parameter.

In terms of tips on how to do this and name your own parameters yourselves, one thing you should do, regardless of what you choose to call it, is never, ever, ever reuse a GUID. If you create one parameter, decide that you don't like it, reuse the GUID and use it with another name, put them into two families and then try and put those two families into one project, Revit will tell you where to go and it will tell you in a very nasty way and it won't give you very much advice as how to fix it.

As I said before, you need to think very carefully about the naming. You want the naming system that you choose to use to be easily interpreted by people so that they can actually read it and understand it. But then, equally, you want some flexibility to give you the different parameters you need to describe different parts of your family or different parts of your design. If anyone wants to talk to me about that in more detail, please come and see me after the presentation.

The other thing is to try and use engineering parameters types as far as possible so that you're using Revit as a database. Revit understands how you're storing information in it by what parameter types you give a particular parameter when you're creating your family. It's really important you try to use the Revit parameter types as far as you possibly can.

Let's see, this is the BIM Manager Suite that we used to populate the families. What you can see is a group of parameters underneath, whether they're set to instance or type, what data group they're going to go into and so on.

The reason we use this tool, is this is one of the families that we created in the library, this is a [INAUDIBLE] unit, these are all the parameters that are in that family. I wouldn't want to be a person that had to go add, tell is what group it's going to go into, tell it whether it's type or instance, press OK, do it again, and do it again and again and again.

That would be horrendously painful. This actually allows you to batch process a number of families and populate them with loads of parameters at any one time. It's not cheap but if you're going to go through this process, it's worth absolutely every penny.

As I said before, the reason we're filling our families full of that data is to inform the production of things like this. So this is one of our equipment data sheets and this is all of the information in our family that's going to be used to inform the production of one of those equipment data sheets.

This is what it currently looks like in Rivet. It's just a normal Revit schedule. You can see that there's lots of engineering variables, lots of ways for people to interact with information. This is what it looks like on a sheet. This isn't anything rocket science and, actually, this is the early version of what it is we're trying to produce moving forward.

This is a slightly more developed version. This is the equipment data sheet for [INAUDIBLE] handling unit. We're going to come back to this later and look at how we can actually create this based on one of the family templates that I was describing to you earlier. The other thing that we've got the opportunity to do, in terms of using this, is to automate this output based on logic.

So what we've got standardised schedules that live in our template, as soon as we create [INAUDIBLE] handling unit and it starts but data in it, once we've got data in it we can then ask Revit as a platform how much data is in each one of these tables, lay it out on a sheet according to the amount of data you're showing based on a one click button so that [INAUDIBLE] handling unit. That's not something we've actively started working on yet, but that's something that we're going to start working on very shortly.

The other thing I mentioned is the parameters that we were putting into spaces and what we're going to put those to use for. And in this instance, the smart family that we're looking at is actually the thing around the space in the middle. The space is full of the parameters that we've created using our spreadsheet, we've push those into that space using project parameters, but the tag round that space is what's pulling the parameters out and exposing it as a RIM data sheet. So all of the information you can see around that room in the middle is one tag. And all it's doing is looking at parameters and elevating them for us to create our deliverables in a different way.

As I say, going back to the family we were looking at earlier, we've got lots and lots of parameters that we're going to use for lots and lots of different purposes. But if we've got a really bespoke unit on a project, we might have to start from scratch. However, in order to make sure that we preserve the data so that we automatically inform the schedules that we've got within our template, we created some blank family templates that were pre-populated with that data so if someone starts a family from scratch, they're at least starting it with all of that data again. So if they put that family in a project that's using one of our preconfigured schedules, it again is automatically going to start filling that out on the project moving forward.

The other thing I wanted to do is focus on some specific parameters that we have within our library and what they're being used for and effectively there's a few more little hints and tricks. As a said before, we wanted to use an automated production of COBie as far as possible. So we've got Autodesk COBie parameters in there and we map those to the overall geometry so that size information is automatically starting to go into COBie deliverables as in [INAUDIBLE] project.

Equally, we've got those NRM1 parameters we put the classification in and they can start to inform out [INAUDIBLE] processes moving forward, as well. Beyond that, I can't quite read that up there. We've also got some really generic parameters that are used for creating references for tags on drawings. So we've got one tag that we tag all of our equipment for. And the way that we've achieved that is using the same parameter in every family so that regardless of what you put it on, that information automatically comes out the back. Again, it sounds or something really simple, but unless you go through the process of creating a standardized set of parameters and pushing them into your families, you're not going to be able to do that.

Beyond that, we do also have a copyright parameter. Is our way of wrapping ourselves in a nice blanket and pretending that no one's going to take our families and run off and use them themselves. All it does to us is tell the world, this is where it came from. If you choose to change it, that's fine, it's probably, actually, illegal but it's still probably fine.

One of the things we've been debating at the company, I can't promise that we're going to do this, is the idea of whether we actually give away our content library to start to inform some consistency across the industry so that when we're working on a project or someone else is working on a project, they're using the same parameters values, you can start plugging those into different processes and trying to stitch together some of the disparate processes we have across the industry.

You can try protectorate your IP and families definitely hold a lot of IP. However, it's almost as important, I'd say, actually, it's far, far more important, that you know how you use those families and how they stitch into your wider system, not just having access to them in the first instance. And that's not where the values come some.

And the final thing I want to talk about, and this is something that came up out of discussion from my earlier class in the week, is the system connection and function parameters we've put into all of our families. And this is a way for us to take broad categories of equipment, such as mechanical equipment, and describe more specifically how that's being used on a project. So, does it have a power connection? Does it have a drainage connection? If we've got something like a fan coil unit and, actually, the other thing we do is give each one of those bits of equipment a specific function. For something like a fan coil unit we say, your ventilation equipment but you also have other connections.

So in this instance, we've got a four pipe heating and cooling fan coil unit. It's going to appear on our heating drawings because it's been ticked as having a heating connection. It's going to appear on our cooling drawings because he's been ticked as having a cooling connection. But it's also going to appear on our electrical drawings. It's going to be gray in the background and that's going to highlight to our electrical engineers that they need to give it a supply.

The other thing it's also got is a drainage connection. So that's automatically going to highlight to our plumbing colleagues that they need to take the condensate away from the cooling coil in that fan coil unit and get rid of it somewhere. The ways that we were discussing this earlier in the other class was that, and it was a guy described to me, that work sets are his first line of defense for choosing where his content arrives in his drawings. And, actually, the approach that we've chosen to take is to use the intelligence within the family as our first line of defense and work sets as our very, very last. And I expect that some people have some slightly different opinions to this. Again, please come and talk to me after the class.

Some other Parameter tips. We don't actually have an LOD parameter. One of the reasons we don't have an LOD parameter is because instance parameters do not reset when you copy elements from one part of the model to another. That's really dangerous if you're trying to describe something like LOD using a parameter and you're not addressing that value every single time you create a new instance of a family on a project.

We also chose to take the approach of generating our parameter names in a multi-disciplinary team. One of the reasons for doing that was to promote consistency in terms of how the teams chose to name their parameters. I named a massive amount of them myself, it wasn't a fun job but it did mean that ideally the quality went up a little bit.

But it also allows you to reduce the quantity of parameters you're creating because you could reuse electrical parameters from the electrical side in your mechanical equipment and vice versa. So you can really start to weed out where you've got duplicates and come up with a leaner list of parameters you can use moving forward.

The other thing is, don't be afraid to use other people's parameters. Other people are creating parameters like Autodesk or the COBie toolkit where that toolkit will hook into their share parameters. So if you're going to create COBie parameters, why not use theirs. We've recently discovered that Autodesk have also got a library of IFC parameters and we're looking at how we can integrate those into our families moving forward as well.

Going back to our concoction of stuff, the next thing I wanted to look at was geometry. As designers, were only going to take our models so far. Now, in the UK, that means that we kind of draw a line here. And generally, everything that we're going to create is going to be LOD 200 or less. Now, again, this might be slightly contentious with some of you but that's where we stand and this is the kind of approach that we've taken to create our library thus far.

The reason for that is that we can only generally specify the generic. We say we want to pump, we say we want it to be horizontal and we say we want it to meet a certain specification. So we can output this flow rate, it's going to have this pressure, and so on. Well, then we need to pass that information on to a contractor who's going to use their supply chain to actually determine which pump they're going to purchase to the best of their ability, the cheapest as they can, to actually give that back to their client. We can't specify that information so we need to be generic. That means we focus on LOD 200.

Now, in terms of what's available to you as preexisting families, you could use one of these. This is a manufacturer's family. I'm not going to tell you which manufacturer. I just cribbed this off of Google.

We don't want to use these at all. That's again, as is designers, the reason for that is that these sorts of families effect model performance, they don't necessarily align with our drawing standard output, they don't schedule because they haven't got our share parameters in them, they can be set up correctly. I've seen families like this, where the connectors are garbage. They don't have the formulas in that we want to use doing inform a whole lot of different processes moving forward, and, and, and. So there's a whole load of reasons why we're staying well clear of manufacturers families.

Autodesk, very kindly, provide a whole load of content out of the box. I'm going to say this on an Autodesk live stream, we don't use your stuff either. The reason for that is that they do things like this. So we've got a whole [INAUDIBLE] of nondescript dimensions that are controlling our family and this is what our users are going to need to contend with if they're going to put this family to use themselves on a project.

If I highlight one specific parameter, height 2. Height 2 current has a value of 210 millimeters. If I adjust that to 500 millimeters, it does this to the family. I've never seen a pump that looks like that. I don't want anyone to design a frankenpump that looks like that. So, again, we're kind of a bit lost with using this sort of stuff out of the box.

Now, this is the Arup version of a horizontally mounted pump from our library. It looks a little bit like a train. Someone said to put a Thomas the Tank engine face on the front of it.

But the idea behind this is that we want it to be simple but representative geometry. We want someone to understand it's a horizontally mounted pump, it's not just a box. We want it to parametric so it will stretch and flex in the way that Revit is able to do very cleverly. And we want it to be really easy for users to modify.

So unlike the Autodesk generic pump, if we look at that family in particular, these are the parameters that we're expecting people to interact with. And we've got a list of seven parameters, many of which are automated based on the axis width that we're going to come back to later. And if I go and change some of those parameter values, I'm going to change it from 500 to 750, I'm really boring to have memorize this video enough to know that changes to 1600 and then I think I change the connection diameter to 200.

What happens when I entering that information back into the family is the whole thing flexes and it just gets bigger. The way that we achieve that is to shift all of the parameters that we don't want our users to interact with into the division geometry group, and to give those parameters formulas that are a fraction of the parameters that we want our users to interact with.

So for example, if we look at that family in plan, we've got the length parameter and we've got the width. If we look at the length all of the parameters highlighted in red are referenced to the overall length of that family. So if I change the length, each one of those parameters is going to divide by a certain distance in order to grow or shrink that family generically across the whole of the geometry within the file itself.

Equally, in this instance, the height we've actually made proportional to the width. So as you make it longer, you make it wider, it automatically gets taller. And that's how we're starting to embed this sort of functionality into families that makes it easier for people to use so that they're not having to contend with difficult unresponsive families on projects. So, hopefully, we fulfilled that wish list.

However, one of the things I was saying before about only going to LOD 200 means that we are doing the generic, but if we go back to that family again and we look at the formulas that we've got listed against those very specific parameters, which also happen to be named very descriptively as to what the changing, we strip out those formulas, anyone can then enter very specific values against each one of those different parameters. So they can, if they choose to do so, take our model and then describe the specific using that family but that family that's full of engineering data. Then they can add their data to it moving forward.

That hopefully moves us somewhere towards actually evolving a model through rather than throwing our model over the wall and expecting the next guy to trace it from scratch. A few other little geometry tips. Things that model lines can be really useful for describing additional detail in families, you don't always have to use 3D extrusions. The room calculation points can be really, really important. We've got 32 fan coil unit family's. That's because we've got families with four pipe heating and cooling connections, families with just cooling connections, families we just heating connections.

And then we've got families with room calculation points hanging out the bottom of them because they live in ceiling voids, and we've got that same set of families with room calculation points pulled out the top of them because they live in floor voids. The fact that we can't actually address the room calculation point using parameters means that we have twice the number of fan coil units that we need. So if we could have a parameter that allowed us to change the room calculation point, that would be great.

The other thing is that, if we need to be able to move a whole load of complex geometry in one go by shifting things around parametrically, make that geometry nested within your family and then push it around using reference planes that way because it's a hell of a lot more stable and a lot more simple to set up. And one other thing is, out of the box, you can't schedule the system offset parameter, which is a real pain for things like air terminals or [INAUDIBLE]. We need that information to go on our drawing.

So we actually use our own version. And the way that we do that is to offset the geometry of the family we're creating from the level plane within the family and then use a parameter to push that geometry up and down. That means that all of the families that we put in for, say, lights, are put into the Revit model with an offset of 0 and then the mounting height parameter is used to describe where that offset is actually going to live and it will push that geometry up and down.

So we get exactly the same Revit behaviours, although, be it executed in a slightly different way, but we get the ability to reference the offset in the schedules that we need to output for our lighting and air terminal schedules.

So, beyond geometry, we then got the idea of connectors. I did a class last year where I focused very heavily on connectors and connector settings. I can't express enough, how important it is for you to get your connector settings correct. If you want to use Revit for anything more than 3D modeling, it's absolutely vital that you know what you're doing. You can go back and look at my class last year for some more information on this because it's a really, hefty, weighty topic.

Or, actually, you can go back to a guy called Martin Schmidt's class from 2008. Martin's actually one of the senior leadership team in the Revit MEP side of Revit. And he wrote a really good reference document which is actually what I go back to. So that's what I think you guys should probably use. He did give that AU talk in 2008, which kind of suggests connectors haven't changed very much recently. But it's still a really, really useful reference.

Then, moving on to formulas. We're going to start this by looking at a session I actually gave earlier in the week. And the idea behind this session was to link the space heating load we had for a given part of a model to the actual equipment within the space itself. So if I change the heating load within the spice from 80 to 35 kilowatts, that's going to divide over the families within the space, which is great. [INAUDIBLE] functionality. Go look at that class for that. But then within each one of those families we've got a formula that takes that new heating load and calculates the flow rate, which in this instance is 0.08.

If we revise the heating mode is going to revise that flow rate again. That flow rate goes into the pipework network and that's what we use to size our pipe work moving forward. What we need is that formula within the family that's going to facilitate us doing that.

Starting off with a quick physics lessen, Revit understands what parameter types are when you put data in them. So if you're looking to put wattage or horsepower or flow rate, you have to tell the parameter that's what you're putting in because if you try and combine parameters that won't combine according to the laws of physics, Revit won't let you do that either.

If we take the example of the formula that we're actually using in the video that I just showed, this is Q equals m c delta T. So the heating power of the heating coil is proportional to the mass flow rate of the water passing through the coil, the specific heat capacity of that water and then the temperature difference of the water going into and then coming out the back of that coil.

Revit won't actually allow you to do mass flow rate. Revit does everything in volumetric flow rate. So because we need our formula to balance, we need to add in the weight, the actual mass of the water. So we have to take the volumetric flow rate and times it by the density of the fluid that's actually being used in this instance.

So in this instance, we have to times it by 1 kilogram in order to actually-- at 1 kilogram per meter cubed-- in order to actually give the water that's passing through our coil, the mass required for the formula.

Now we've got that slightly evolved formula, if we look at that in terms of all the different things we have and actually look at the units for those, I make no apology for using SI units. They're awesome. They're much better than imperial units. We invented those as well. Actually, maybe we didn't. They might be French.

Anywho, the point is that according to an esteemed colleague of mine, any government projects you guys do, you have to do in metric. So hopefully these will make sense. What we're going to do is just demonstrate how this formula actually cancels and why it is balanced. So we're starting off the watts. But, actually, watts are equal to a joule per second, it's energy per second, energy consumption.

So if we look at that in comparison to the right hand side of our formula, we can cancel out the volumes, we can cancel out the weights, we can cancel out the temperatures and that leaves us with a joule per second either side of our formula. That shows, from a physics perspective, that this formula is balance. So Revit will accept this formula.

How many of you have seen this dial up box? Right. There's two reasons why you'd see this dial up box. One, you're trying to write a formula that doesn't obey the laws of physics, which is not a good idea.

The other is that you've used the wrong parameter type when you're trying to put the data in in the first instance, which, again, means that Revit will misinterpret what you're trying to put in and will tell you, you are trying to disobey the laws of physics. In order to design buildings properly that are going to stand up and provide the heating we want, and provide the power we want, we kind of have to live within the laws of physics that are available today to us and how Revit understands them.

So going back to our formula again. In this instance, we're actually looking for the volumetric flow rate of the water. We've already got the heating load. So we're going to rearrange that formula so we've got the heating loads. We're going to divide it by some constants that we're going to add into the family and then that's going to calculate the water flow rate that we require in order to give us the output that we're looking for.

If we do it in Revit speak, I've got a simplified version of that formula at the bottom of the screen, you would have to use the parameter names that you choose to use within your family's. The names that we have now would mean that that formula would probably be about four lines longer than it is. But that they do make sense, honest.

But again, it's really important that you look at things that brackets carefully because if you put brackets in the wrong place, that moves how your cancelling those units and again it will mean that you're starting to stray away from the laws of physics that we're bound to in reality and in Revit.

If we look at that, actually, within the fan coil unit family we've looked at a lot before, we can see we've got the heating load. This is the heating load that, in the instance of the [INAUDIBLE] class I gave yesterday, it's being derived from the space. You could manually enter this yourself. And then we're going to take that heating load and put it as the first item into our [INAUDIBLE] flow rate formula. We're then going to divide that heating load by, within a bracketed structure, the specific heat capacity of the water, the water density, the [INAUDIBLE] flow rate entering the coil and the [INAUDIBLE] flow rate leaving the coil. You combine all that lot together and you get your water flow rate.

And looking at the potential to use formulas in this way to actually put Revit to use as a design tool that takes information, computes it and gives it back to you to inform the design processes usually on projects is a really high priority for us and I'd suggest it should be a really high priority for you.