Understanding how to integrate with your client’s asset and facility management requirements at first seems like a daunting task, however getting it right can be as simple as asking the right questions.
From the perspective of a project manager or even an asset owner, some of the questions that should be asked are:
When will the facilities management team get access to the model? Will it be during the design phases of the project, or will it be once the design is complete?
Will the facilities management ream be able to dictate to the design team what information is incorporated in the model?
Will the facilities team be able to review the model before construction and commissioning?
Will the facilities management team own the model when it is completed?
Who maintains the model once handover is completed?
Then there are questions that the more technically minded team members tend to focus on around information requirements
What information does the facilities team require?
Do the facilities team actually need all of this information?
What data formats does the facilities team require?
Do they have existing non-BIM facilities packages that require integration into the new BIM enabled system? Can it be integrated at all?
If you’re interested in how I approached the problem of recording existing assets in one of Australia’s largest health precincts, take some time out to check out my AU2018 presentation
A lot of people ask me if I’ll give them my Iplex floor waste gully family. The answer is always no, not because I don’t want to share, but because I would rather people learn and understand for themselves rather than taking the easy way of “grabbing something from the internet”
I recorded a video on how to create the FWG a long time ago, but after a bit of back and forth discussion on Youtube, I have decided to pull that old video out and record some voice annotation so you can follow along.
I do apologise about the audio quality, I only had my junky work headset to record with.
Yes, this is how I spend my nights in hotels when travelling for work.
It’s clear how lookup tables are beneficial to the pipe and conduit modelling process, so how can we use them in other Revit family categories?
Originally lookup tables were only available to pipe and conduit fittings, but we can use them in any family category. We can build fully flexible families that a controlled with lookup tables, we just need to use a bit of common sense when deciding if a lookup table is best suited or not.
Valves would be suited quite well to utilising lookup tables, whereas a VAV box would be more suited to using formulas and other parameters.
Building Your Own Lookup Table
You can use dimensions, angles and integers to both look up and be looked up, the trick to working with integers is that your column header format should follow
Using integers can be valuable within lookup tables to control the dimensions of specified manufacturer equipment. To achieve this, we need to take the manufacturer sizes and populate them into a lookup table. Working this way locks down the sizes so that the end user is unable to manipulate them. In this example, we’re going to work with a basic rainwater tank.
Rainwater tanks are a perfect use of lookup tables, you could have a family file that contains data for one manufacturer, then the lookup table drives the dimensions based on the volume. We use the volume value because this will drive all other dimensions of the tank.
We’re going to use an integer parameter for our tank volume, as volume parameters can not be used in lookup tables.
This is our basic lookup table to get started with. We’re going to look up the volume as an integer which will in turn drive the tank diameter, height and inlet height dimensions.
You can see that based on our basic lookup table and our lookup formulas, the correct data is being input into the family.
Once the lookup table is populated with the tank dimensions across the product catalogue, all a user needs to do is change the tank volume to a value that corresponds with one in the lookup table and all the dimensions will automatically update.
A trick that can be used with lookup tables is that we can drive a single text parameter with a lookup table, the same old restrictions apply though, if you’re looking up an instance parameter, you must be driving an instance parameter.
The secret behind bringing text in from the lookup table is to leave the lookup column in the formula blank. In our rainwater tank example, that would read as follows
Getting More Advanced – Allowing Custom User Input
The example water tank is great when you want to completely lock down a family, but what if you want the option to allow input form the user? We can allow for this by adding a few additional parameters to the family.
To achieve this, we’ll add a yes/no parameter to the family which can be checked when the user wants to specify a custom size. When checked, this parameter will override the lookup table.
We then need to add parameters within the family for every parameter that is controlled by the lookup table.
The new parameters that have been created in the family are CustomDiameter, CustomHeight, CustomInletHeight and CustomTankType.
We now need to change the formulas for each parameter being controlled by the lookup table so that the lookup formula is nested within an if statement.
This also allows our trick with the text lookup to make it very clear that custom dimensions are being used, as we’re changing the TankType parameter to read “CUSTOM DIMENSIONS”
Modifying Existing Pipe Fitting Lookup Tables
Now that we know everything there is to know about lookup tables, modifying existing lookup tables should be quite easy. For this example, we’re going to use a PVC pipework bend.
You can download a copy of the files I’m working with here
Open the family
Open the family type dialogue
Click on the Manage Lookup Tables button
Export the existing lookup table
Rename the lookup table to Bend_PVC_DWV_Iplex.csv
Back in the family types dialogue, import the new Bend_PVC_DWV_Iplex.csv and chance the Lookup Table Name parameter to Bend_PVC_DWV_Iplex
Apply the changes and close the family types dialogue before continuing.
We also need to refer to the Drain, Waste & Vent Pipe table on page 23 for information about pipe diameters and wall thicknesses
Open the .csv file in Excel. The out of the box (OOTB) lookup table is in inches, it is up to you if you convert the current dimensions to millimetres or not, but we will need to change the column headers from inches to millimetres (USA spelling)
Compare the dimensions of the Iplex product catalogue with that of the Revit family.
L1 – L2 (from fitting table)
Centre to Socket Bottom (CtSB)
L2 (from fitting table)
Socket Depth (SDpt)
a (from fitting table)
L1 (from pipe size table)
Fitting Outside Diameter (FOD)
L2 (from pipe size table)
Wall Thickness (WThk)
Something to take note of is that the L1 dimension from the pipe fitting takes into account the total length of the fitting from the centre of the fitting to the end of the fitting including the socket.
Within Revit the Centre to Socket Bottom does not include the socket, so the figure that we need to take for CtSB is actually L1 – L2
In this example, I’m going to start with the 40 dia fitting size, however if you have a need for the 32dia pipe fittings you can start there.
There are 3 different 40 dia elbows in the Iplex catalogue. 40×15°, 40×45° and 40×90° each with differing dimensions. To allow for each specific fitting, we’re going to add a row for each fitting from the catalogue.
Fill out the corresponding data to the lookup table from the Iplex catalogue, once done, save the csv file and load it back into the family and test the flexing of your new 40 dia fitting.
If you’re happy with how the family flexes for your 40 dia fitting, continue adding the remaining sizes to the lookup table.
Once you’re finished you’ll have a complete, dimensionally accurate Iplex PVC pipe fitting.
If you’re finding yourself modelling more detailed models that reflect proposed fabrication or constructed works, Cesare Caoduro over at the BIM and Others blog has a great step by step tutorial on how to use Dynamo to generate Unistrut style pipework supports.
If you’re mechanical or electrical it would be quite easy to adapt the first portion of the script to generate the same type of supports for ductwork and cable trays.
Over the last 3 months I’ve been busy working hard on coordinating the BIM for an existing infrastructure study of a hospital. The site consists of everything from heritage listed sandstone buildings constructed in the 1800s where for obvious reasons there are no existing drawings to a building that’s currently in the final stages of construction and has been fully designed and coordinated in BIM. The infrastructure study involved locating assets and services that interconnected between buildings within relatively accurate space within the BIM at LOD 200 as per the BIMForum guidelines.
When it came to the BIM, we decided to work with one building per MEP model which meant we had 28 MEP building models, 28 architecture building models that were created using a series of stacked DWG files and 4 site models. The obvious problem with so many models was going to be the consistency of the data and how we would go about verifying that data. Ensuring that we had all 60 models with the same information consistent information was a mountainous task that would have taken an exorbitant amount of hours to complete if manually reviewed, even if utilising BIMLink.
Enter stage left: Dynamo.
We used Dynamo far more extensively on this project than any that I have worked on before. Normally I’d work with little snippets to process small amounts of data and automate minor repetitive tasks, but this project was a real BIM project; there were no traditional drawing deliverable which actually seemed to genuinely baffle newcomers to the project. The deliverable was the federated model and more importantly the information contained within all the individually modeled elements. A few hours on one of my Sundays and I ended up with what you see below
That structured mess was able to verify photo file names and associated photo URLs, it verified asset codes were correct and if they weren’t, it generated new asset codes in the required format, it also checked and corrected all the information required to generate those new asset codes and finally probably the simplest part of it all, it filled the project information parameters for us. It was run on all MEP models, with another run on all the architecture models that we created.
Although we were able to automate a lot of really mundane processes, they were for the most part fairly project specific so even though the Dynamo script itself was invaluable to the project, other than the experience provided it doesn’t hold that much value for future projects. There was however one custom node that I put together for the population of Project Information parameters that will probably get used again and again on projects in the future.
Each input of the node is filled with a string for each individual parameter. In the project, the building name/number parameter relied on the levels within the model being named correctly for which there was another portion of the script that checked that the naming conventions for levels were followed.
The processing of the data itself is performed by Python code inside the custom node, after which the output showed the data that has been filled. You can either pick the custom node up from the MisterMEP Dynamo package or if you want to recreate this yourself the Python code is below
from RevitServices.Persistence import DocumentManager
from RevitServices.Transactions import TransactionManager
doc = DocumentManager.Instance.CurrentDBDocument
projinfo = doc.ProjectInformation
#The inputs to this node will be stored as a list in the IN variables.
OrgName = IN
OrgDesc = IN
BuildNumber = IN
ProjAuthor = IN
ProjDate = IN
ProjStat = IN
ProjClient = IN
ProjAddress = IN
ProjName = IN
ProjNumber = IN
projinfo.OrganizationName = OrgName
projinfo.OrganizationDescription = OrgDesc
projinfo.BuildingName = BuildNumber
projinfo.Author = ProjAuthor
projinfo.IssueDate = ProjDate
projinfo.Status = ProjStat
projinfo.ClientName = ProjClient
projinfo.Address = ProjAddress
projinfo.Name = ProjName
projinfo.Number = ProjNumber
elementlist = list()
OUT = elementlist
#OUT = "done"
An important part of domestic water design is calculating flow and pressure losses, a common complaint I have from fellow Aussies though is that Revit’s pressure loss report is it’s not in a familiar format and is not something that they’re comfortable including within their design folders. Not to mention, with the AS3500 pipe sizing work(around)flow that I posted last week, the flow rates still don’t quite match up due to the IPC vs AS3500 conversion factor.
So with a powerful tool like Revit at your disposal, why not utilise it to generate data outputs that are in that familiar format and that you are happy to drop into your design notes?
There is always old faithful – the Excel spreadsheet that performs all your calculations..
..because it’s the way you’ve always done it, so why change right? Not a bad solution if you want to spend the rest of your career manually measuring pipework on drawings to verify your design; ultimately though this is how we came to the true “She’ll be right” Australian method of pipework sizing. After all, doing it properly takes far too long, so just go with your gut and prove your design with actual calculations later, but only if someone questions it down the track.
Did you know you can recreate basic Excel calculations within Revit schedules using calculated values? Of course you did! OK so maybe you didn’t. The problem I have with this method though is due to needing to neutralise Revit units your formulas will start looking a little.. weird.
Take the following example, comparing a simple Excel formula to it’s Revit equivelent
Which how you’d explain that to another engineer I’m not quite sure. They’d probably look at you like you’re a bit odd. So what’s the solution then? Well, maybe you’ve heard of this thing called Dynamo? It’s frequently touted as the best method to model a facade made from old chairs, but did you know that Dynamo can be used for actually useful things too?
In Dynamo, our formula is quite clean and simple, in fact if you squint a little, it looks just like our original Excel formula.
Armed with that knowledge and a bit of time, that trusty old Excel sheet you’ve been using your whole life can be converted into Dynamo. Once you’ve got the calculations working off your Revit model in Dynamo you can generate all the data within your schedules for every single piece of pipe in your model within seconds. So do you still want to spend the rest of your life measuring pipework? I thought not..
And here are the fruits of my labor. My graph was developed in 0.9, but I can confirm it will work in 1.0 and the 1.0.1 pre-release.
Stepping through from left to right, this is how it all works:
Starting off simple, I’m selecting all the pipework within the model.
From there, we’re feeding the All Elements of Category node into the Element.GetParameterValueByName node. Filter out the pipework elements based on their system classification using a combination of String.Contains and List.FilterByBoolMask. This gives a set of true and false results for all of the selected elements, which in this case is our pipework. We take the “in” output of the List.FilterByBoolMask which gives only the elements marked as true.
In this instance I have used String.Contains and checking for the string water. What this means is that it will select anything with water in the name, which would include cold water, hot water, rainwater and so on. You can adjust this to filter out your pipework as you need for as many different systems as needed.
From this point onward is where all the good stuff happens. We push our pipework out to three separate groups of nodes. A Barrie Smith lookup, velocity calculations and head loss calculations. The Barrie Smith lookup was the most difficult part as it required custom python code to perform the lookup.
In this group, our results from the previous step feed into the Element.GetParameterValueByName node. We’re picking up the calculated fixture units from our pipework and multiplying it back out by our 3.5x multiplier from my previous post to give us our actual AS3500 compliant fixture units. The code block in the upper left generates a list which is Table 48 from Barrie Smith transcribed to Dynamo. The fixture units and Table 48 are then fed into the custom python node
The output of the python node then feeds into a math divide node and we divide our flow rate figures by 28.317 and pushes the result to a flow based parameter that I’ve named AS3500_PSD. The reason for division is that Revit stores all units of measurement in imperial rather than metric. When inputting data through Dynamo, Revit doesn’t know that you’re inputting metric figures. What this means is that when you review your data in Revit, you have input 0.23 gallons per minute, not 0.23 litres per second.
Heading back to our second (green) step, the List.FilterByBoolMask node feeds into another Element.GetParameterValueByName node. This time we’re picking up the diameter of our pipework and we’re finding the diameter in imperial and converting it to metric using a formula within a code block.
The metric diameter from the code block and the probable simultaneous flow rates from the third (blue) step combine first to calculate our velocity. The calculated result is converted back to imperial and populates to a velocity based parameter named AS3500_Velocity
Our last fork from the second (green) step is to calculate our head loss for our section of pipework. The brighter pink section first takes our length. Now for whatever reason this is taken in millimeters, so no conversion from imperial required. In the purple section we’re feeding the code block with our pipe size and probably simultaneous flow from previous steps to calculate headloss per 100m, then another code block to calculate headloss for the section of pipe. Finally we push our headloss calculations into their respective parameters AS3500_Headloss and AS3500_HeadlossSection.
When you’re finished, you end up with a schedule you can drop on your drawing or export to Excel for design verification, and it’s all calculated as you model and far more accurate than you would have ever provided before.
The example that I’ve used here is highlighting flows where the velocity falls outside the acceptable range of AS3500, so you have a simple visual prompt that you need to check your design. I have found though that most of the time, the design is correct and the sections of pipe highlighted are either 15dia supplying a single fixture with a velocity greater than 3.0m/s or 20dia with two fixtures connected with a velocity of less than 1.0m/s.
Give it a go yourself, once the Dynamo portion is humming along your return of investment is incredibly quick.
I will be presenting two talks, one on Navisworks clash detection and another on documenting MEP models in Revit, as the Singapore BIM mandate keeps marching forward toward the next goal of an FM mandate it’s important to get a handle on tools of the trade and how to make them work for you.
You can register to attend the event on the RTC website here.
Have you ever had a model that you’ve wanted to remove the project/shared parameters from quickly without having to go through the mind numbing process of clicking the series of buttons to remove each individual parameter?
Have a crack at AutoIT, it’s a scripting language that you can either run direct from the editor or compile into *.exe files.
; usually a good idea to put this in so you don't max your CPU
; open your project parameter window and hit go!
ControlClick("Project Parameters", "", "[CLASS:Button;INSTANCE:3]")
ControlClick("Delete Parameter", "", "[CLASS:Button;INSTANCE:1]")
I had a series of about 50 hodge-podge parameters that I wanted to remove and this little script cycled through them in a few seconds. Of course it only really works if you want to get rid of all the parameters in a project or template, but that is exactly what I wanted to do.
Hopefully someone else will find this one useful too.
In Australia and likely elsewhere, a lot of people believe that BIM = Revit, however this is certainly not the case; there are many other software packages out there and if you need to collaborate with these software packages, chances are you will need to use IFC files.
IFC stands for Industry Foundation Class, it is a platform neutral file format that is not controlled by any of the software vendors.
For those that haven’t worked with IFC files before, there are a few things you need to keep in mind before you jump headlong into working on a project where IFC is used for collaboration. I will specifically be talking about my experiences working with IFC outputs from ArchiCAD.
You need time
Depending on the size of the project, the process of importing and IFC file into Revit could take a very long time. IFC imports can be anywhere from almost instant to a few days. You need to make sure that you clearly communicate this not just with your engineering team but with your architecture design team as well.
It’s very important to keep an open line of communication with your architect. Pick up the phone.. or more importantly answer the phone! Don’t let problems go unsolved sitting in someone’s inbox. 5 or 10 minutes spent on the phone with the architect might save hours of time for both of you down the track. They will be able to split large projects into smaller chunks or limit what elements are being exported from ArchiCAD so that the heavy lifting your hardware needs to perform is more manageable.
In all my testing, Revit appears to use 2 cores at most when importing IFC files. If you have a fast multi-core machine, you can set more than one file to import at a time. I highly recommend selecting each instance of Revit that you have open and setting the CPU affinity in task manager. This forces windows to spread the load across your CPU, maybe I’m imagining it but I found that if I didn’t do this all Revit processes seemed to share the same few cores; without doing this my 6 core/12 thread Xeon CPU sat at around 12% utilisation where as if I forced each instance of Revit to use certain cores I could push my CPU usage towards 80% utilisation. The problem you will face though is RAM. On some IFC files even 32gb is not enough.
For the Revit users on the team, push for the use of 2015 or newer; there really is no reason to dilly-dally in the comfort of older versions of the software. Revit 2015 brings to the table more efficient IFC imports through the Link IFC option. It is not a true IFC link, Revit actually converts the file to an RVT on the fly, in my testing using IFC Link instead of the open IFC method saves up to 60% on import times. The first iteration of architecture I received for the most recent project I’ve been working on took just on 3.5hrs to import a 286mb IFC file using Open -> Open IFC where as using Link IFC on the same file took only 24mins.
With some helpful splitting of models by the architecture team you can improve your workflows significantly.
I have worked on two hospital projects authored in ArchiCAD and we split the FF&E from the building fabric. The building fabric was always imported first and the FF&E flowed on afterward. We always requested up to date DWG exports of the floor plans that could be overlayed to reflect the FF&E as well.
You need DWG files
DWG files will play a very important role when working with IFC files, they will allow you to keep up to date quickly with furniture layouts but they’ll also help speed up your model. ArchiCAD seems to be able to handle higher polygon counts far better than Revit can which leads to glorious, highly detailed furniture models, trying to run a model with the 3D furniture models loaded in is going to slow you and your team down to a crawl. You don’t need to coordinate in 3D with a chair, but you may need to know where it is so you can place power and data outlets or other equipment. DWGs are the best way to do this.
Make sure you follow all the usual rules about DWG files. Keep them clean. Link them into their own host model, don’t insert. Never link or load them into your live model where possible. There is an article in the June 2015 AUGI magazine which goes into detail on best practice. Something they suggest that I’ve never tried before is to insert the DWG files into an *.RFA file and then stack the *.RFA files in the host model. If it means that it will be less problematic, go for it.
IFC files do not carry ceiling tile information
Don’t worry though, you asked for DWG files remember? Depending on what you want to show on your plans, you may need to link the DWG at certain heights so that they fall within the view range of your ceiling plan.
Again, follow best practice with linking in DWG files to a host model. Do not locate your RCP DWGs in your working model.
You need to understand coordinates
And you need to understand them well. When working with IFC exports from ArchiCAD, you will be working at the architect’s origin location, not shared coordinates. As much as it has probably been drummed into you to “always use shared coordinates” there is nothing actually wrong with using an origin to origin system.
In fact when importing an IFC file you don’t get a choice of how to bring the file in, Revit will automatically import at origin to origin. This poses a problem if you’re also collaborating with a civil team, but this is pretty easy to overcome, you just need to make sure that it’s part of your workflow.
You can’t host families to an imported IFC
Unless you’re going to draw hundreds or potentially thousands of reference plane, forget about using those face hosted families that you’ve become so accustomed to.
As you’re probably aware, all elements in Revit have a unique identifier, also known as an element id or global unique identifier (GUID). For whatever reason, Revit does not have a consistent way of applying GUIDs to imported IFC elements. This means that today the wall on ground level at grid intersection D5 might have an element id of 654321 and next week, it could be 751155 and as a result your hosted families will become orphaned. Or worse yet, maybe now a different wall from level 10 has picked up that original 654321 identifier and now your data outlets have been automatically moved to that new location by Revit.
At least this was the case in earlier versions of Revit. In newer versions of Revit you simply are not even allowed to host a family on an imported IFC face at all.
My advice would be to develop a suite of unhosted families. IFC is going to become more prevalent in the future especially as some governments around the world are mandating the use of IFC so you’re going to have to deal with it more in the future, you might as well be prepared.
Never ask the architect “Can’t you just do it in Revit?”
Unless you want the architect to ask “Well can’t you just do it in ArchiCAD MEP?” then don’t; and yes in case you were wondering there is an ArchiCAD MEP. Seriously, show a little respect. Sure Revit has a larger market share than ArchiCAD but that is not the point. BIM shouldn’t be and is not restricted to a single piece of software.
At the end of the day it’s not actually that hard to work with IFC files. Sure you have to think about things a little more but that’s OK because how boring would life be if every day was exactly the same? The most important thing if you’re on your way to higher levels of BIM is to make sure you get the rooms imported from the IFC file, that way you can still create MEP spaces and in turn perform all your MEP calcuations quite successfully. Otherwise if you’re still finding your feet in BIM and Revit is primarily a 3D documentation and coordination tool, working with IFC isn’t as hard as you might think it is.