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.
Life isn’t just about Dynamo, so here is something a little different to mix things up.
Earlier this year I spoke at BiLT ANZ 2017, I had the opportunity to present two separate talks of which one was lookup tables. It’s a bit of a dry topic, so stick with me.
Lookup tables for pipe and conduit fittings provide an invaluable enhancement to the MEP workflow that we take for granted. On every project we work on, lookup tables save us countless hours in the modelling process. Without them, modelling a pipe system would require each individual pipe fitting to be sized as you go. It may be only a few seconds lost per fitting, but multiply that by hundreds or even thousands of times across a project. Then consider the revisions across the piping network. Those few seconds wasted quickly adds up.
At their core, lookup tables are simply comma separated value files (.csv) that are used in conjunction with Revit family files. Prior to Revit 2014, these files were stored on your hard drive or in a common network location and that location was referenced by the revit.ini file.
You might have had experience with tiny pipework fittings that wouldn’t size correctly in Revit if the lookup table location was not correctly configured. Nowadays, lookup tables are stored within the family themselves, provided your family content has been properly updated to 2014 or newer the new system with embedded lookup tables should eliminate those tiny fittings altogether.
Most commonly lookup tables are used for defining pipe and conduit fittings based on the nominal diameter of the fitting. Revit is then able to automatically size and resize fittings based on the size for the pipe the fitting is connected to by using the data contained within the lookup table.
The Lookup Table Format
Lookup tables can be created and edited in either a simple text editor such as Notepad or Notepad++ or in Microsoft Excel and it’s alternatives.
The first column is a reference column, the values in this column could be ‘Tom’ or ‘Jerry’ but it’s obviously more useful to give enter data that is relevant to the family being created.
Usually when dealing with pipe and conduit fittings this is the nominal diameter, when dealing with pipework branches, I like to format my references as Upstream x Downstream x Branch so for example, 100x100x65. You could however include product names, say if it was a 5000 litres grease arrestor, the reference could be GreasePit5000
The second column defines the lookup value which is typically the nominal diameter of the fitting. This is the column that Revit will look up to determine the remaining parameters for the element.
The formatting of the headers within the csv file is
which you can see in the example above. The formatting of the headers is critical for the lookup tables to work.
In column B of the example, we have ND##length##millimeters (note US spelling of millimetres) which in this to the nominal diameter, it’s a length parameter and the units are in millimetres.
If further lookup values are required, say for example in the instance of a pipework branch, more lookup columns can be added as needed, shifting the remaining columns to the right.
As you can see in the above example, we have three nominal diameter columns to determine the size of our fitting.
The remaining columns after our lookup columns contains the data that drives the modelled dimensions of the Revit family and you can have as many lookup columns as you need to generate your family.
How Lookup Tables Are Used in Revit Families
Lookup tables are stored within the family file itself through the Manage Lookup Tables dialogue. The lookup table is then referenced using a text based parameter and lookup formulas are used to retrieve these values from the lookup table.
Importing and Referencing the Lookup Table
To import the lookup table, you first must open the family file itself. In the family types dialogue box, click on the Manage Lookup Tables button.
Once in the Manage Lookup Tables dialogue, you have the option to either import or export the lookup tables contained within the family.
If you’re starting with a family that already has an associated lookup table, it’s always a good idea to start by exporting the original lookup table so you can use that as a base and then modify.
Once you have a completed lookup table, you can import it in the Manage Lookup Tables dialogue. You can have multiple lookup tables within your family files and chose whichever is required.
Once the lookup table has been imported, you need to add a text parameter to the family that references the lookup table name. Historically this parameter has been named Lookup Table Name although you can name this parameter anything that you like, it’s best to remain consistent with the out of the box parameter naming.
When filling out the parameter data, it needs to match the name of the .csv file that you are going to use, minus the .csv extension.
Lookup Table Formulas
The formula used to reference the lookup tables is
size_lookup (Lookup Table Name, “Lookup Column”, Default If Not Found, Lookup Value)
The format of the formula is similar to that of an if statement.
The first portion of the formula is telling Revit to find a value in the lookup table “Lookup Table Name” for a column named “Lookup Column” and then pull the value from the row that corresponds with the value from the “Lookup value”. If there is no match, Revit will provide the value from “Default If Not Found Value”.
In the example above, the formula is finding the value for the fitting outside diameter.
Stepping through the formula, Revit will lookup the table that has been defined in the parameter Lookup Table Name for a value in in the column named “FOD” that corresponds with the lookup value of the Nominal Diameter parameter (50mm). If no match is found for the nominal diameter in the lookup value column, a value equal to Nominal Diameter 1 + 9.1mm will be returned.
Note that the nominal diameter is currently set at 50mm. If we refer to our csv file we’ll see that our lookup value is ND1 which corresponds with Nominal Diameter 1 in our family.
When ND1 is 50mm we can see that the value of FOD is 56mm, this has set our family to have a fitting outside diameter of 56mm.
What About Multiple Lookup Values?
You may have noticed that the example family used is a DWV pipe branch fitting, so we need to deal with multiple lookup values. The fitting may be a reducing branch or it may have different variations in branch angles.
To achieve this, we simply need to add more lookup values to the end of the formula.
In this example we’re looking up the socket bottom to socket bottom run, we are again referencing the same lookup table however this time we’re looking for a match for Nominal Diameter 1, Nominal Diameter 2,Nominal Diameter 3 and Angle in a single row within the lookup table.
If a match is found, Revit will return the value from the column that corresponds with SBtSBR. If no match is found, Revit will return a value equal to that of Nominal Diameter 3 + 27.7mm.
This particular fitting we are working with is a 50x50x50 x 45° DWV branch
Referring to our csv file, we can see that when we look up the values 50, 50, 50 and 45 the corresponding value in the SBtSBR column is 81mm which is the value that has been set in our family.
Remember that the lookup columns need to be in order in columns from left to right to be able to lookup multiple values.
So that’s it for understanding how lookup tables work, stay tuned for Part 2 where we look at applying the use of lookup tables to improve our workflow.
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.
There has been a problem with printing solid fill that form family symbols in Revit using vector graphics since.. well.. forever.
You might have experienced it yourself in the past, I have found though that it mostly affects electrical documents as they have a high proportion of symbols that use solid fills; maybe you have had an essential GPO print as a non-essential, emergency light symbols not printing correctly or distribution boards showing as control panels.
In the engineering world, these problems can be pretty disastrous, especially during the tendering process. The last thing you want is contractors putting together a price based on incorrect symbols due to prints that just aren’t quite right.
The problem is fairly well documented as well with questionsaskedandblog posts made and everyone just seems to deal with it by responding with “Oh yeh.. You know you should be printing in raster right?” or better yet “Just replace all your hatching with really close lines”
Because afterall, that is what everyone wants to spend the rest of their life doing; drawing a series of lines to emulate a hatch pattern so they can overcome printing problems.
Some people even say that it has been fixed, but I can tell you for certain that working on a project in Revit 2015 the problem is definitely not fixed.
But is it a Revit problem? I’m not so sure. What if I told you that you actually can print your solid fill patterns and print them in vector? You’ll kick yourself when you realise how simple the solution is.
Dots per square inch.
That’s it. The DPI setting you have configured your PDF printer to is the problem. I’ve done a comparisson on some electrical GPO families that I have created between Bluebeam, PDF995 and BioPDF. In each case I printed in 150, 300, 600 and 1200dpi, with the exception of PDF995 where 144dpi was the closest available option to 150.
Basically the root cause is that the filled area you are trying to print is considered to not be printable within the DPI setting you have selected, so it is skipped.
As you can see on these particular symbols, the half shaded GPO symbol that signifies a UPS connected GPO does not print correctly at 150dpi at all, the filled region does not print at all other than the line down the centre which is the fill boundary.
At 300dpi, our symbols actually print pretty well with only a few small glitches in the symbol but nothing to really worry about as you can tell that the symbol is clearly half shaded.
600dpi seems to be the optimum for these particular symbols with clean filled regions, interestingly jumping up to 1200dpi seems to introduce some strange glitches to the fills again, but they only really appear when zoomed right in on the page.
Don’t take my word for it though, give it a try yourself! I have found that although 600dpi seems to be the sweet spot for the families I’ve shown above, it varies from symbol to symbol. Some almost identical GPO symbols created by a colleague still don’t print correctly until 720dpi.
Keep in mind that higher DPI prints will take longer, especially if they’re forced to print in raster mode. Print times due to higher DPI settings or due to raster printing is an argument I’ve had in the past but personally I think the extra time taken to print a correct set of documents is well spent compared to saving a few minutes to deliver drawings that don’t quite hit the mark.
Have you ever come across a project with a keyplan in the titleblock and wondered how to go about managing the keyplan shading? The last thing you want to be doing is clicking every single check box across hundreds of drawings.
In this jumbled mess there are a total of 14 shaded areas on the keyplan. 3 for the basement, 3 for the roof and 8 for ground and first floor. So what is the most efficient way to manage it all?
The answer is integers.
An integer is simply a number that is not a fraction. It is a whole number. In the instance of our keyplan, integers can be used to control the shading for our titleblock by associating those values with an on/of visibility parameter.
In this example, I have used the following number sequences
Basement = 1 – 3 (you could use negatives here)
Ground & first floors = 21 – 28
Roof = 31 – 33
Each of the visibility parameters are then associated with the integer value by simply using the formula KEYPLAN_INT = xwhere x is the value associated with each level and zone. So for example, KEYPLAN_INT = 24 looks like this
But we don’t have to stop there. You would have notice we have two wings on the project that has resulted in the drawings being rotated at 10 degrees, this means on those 3 zones our north point will be different to the rest of the project. We can again use our integer parameter to solve this.
As these rotated views are only on ground and first floor, they are associated with the codes 25, 26 and 27, this means we can control our north point rotation with an and formula nested inside an if formula. The formula that I’ve used is if(and(KEYPLAN_INT > 24, KEYPLAN_INT < 28), 3.091°, 13.091°) so any drawings that have a keyplan integer of greater than 24 and less than 28 will have the north point rotated at 13.091 from north, the remaining drawings will have their north points rotated at 3.091 degrees.
But what about the drawings that we don’t want a northpoint, or a keyplan for that matter? Drawings like schematics, details and drawing lists. The shaded parts of the keyplan already only display if the correct code is used, so we can take advantage of this and simply create another visibility parameter that is associated with the building outline, the additional border line on the titleblock and the north point. In my example I’ve named this parameter NO_KEYPLAN with the formula of not(KEYPLAN_INT = 0). When the integer = 0, everything is switched off.
If you have people that don’t know how to read hydraulics drawings (I’m looking at you Sydney), you can also associate this parameter with Stratman and his sweet 70s style.
So on the left we have an integer value of 24 and on the right, the same titleblock with an integer value of 0.
You can then use your favourite bi-directional Excel option, be it Dynamo, BIMLink or some other alternative, export all the data to excel, set the integers for each sheet, re-import the data and you’re done.
If you have it, BIMLink is a great piece of software with many different uses, from project setup to managing the bi-directional flow of data, through to standards and overall process management.
One of the things I’ve used it for quite a bit is renaming family names and type names bringing family content into line with company naming conventions turning a mess like this
into something clean like this
If you’ve ever ventured down this path, you may have discovered a shortfall in the process due to BIMLink not being able include families in a ‘type link’ with families that don’t actually have a defined type like these ones highlighted below
This suddenly makes the standardisation process a whole lot more time consuming because if you have a lot of families without defined types, there is nothing BIMLink can do to help you. I even spoke with the Ideate team at the Australian Revit Technology Conference recently and they confirmed that this was the case and there wasn’t much they could do to help out as they are limited to what they can do by the Revit API.
I was determined to overcome the issue though, there had to be a way where I didn’t have to manually create a new type for every single family!
My first thought was to export all the families and then use journal files to batch process them, in concept it worked; each file in my list would have a new family type created but unfortunately it would fail after it created the new family type on the families without an existing type – the exact families I was trying to work with. I could continue to process the next file by restarting the batch but mindlessly restarting batch files until all the files were modified wasn’t the solution I was looking for.
In the end the solution was C#. BIMLink might be limited by the API because it is dealing with families within the open model, but I wasn’t limited to that as I’d already exported the family files to my local machine.
I came up with was a somewhat simple C# macro that processes a group of families in a predetermined folder, from there it creates a new family type for each simply named New_Family.
I had initially wanted to create family types named Standard but realised I’d likely run into issues with my macro due to it’s simplicity if I came across a family that already included the Standard type name.
public void ProcessNewTypes()
Autodesk.Revit.ApplicationServices.Application application = this.Application;
string directory = @"C:\INSERT\FILE\LOCATION";
string s = "";
// loop through all files in the directory
foreach (string filename in Directory.GetFiles(directory))
s += "Family Name,Family Type,";
Document doc = application.OpenDocumentFile(filename);
// skip any files that are not family *.rfa files
// create the new family types
using (Transaction t = new Transaction(doc, "Create New Family Type"))
FamilyManager familyManager = doc.FamilyManager;
// this is the new family type name
// commit the changes and save the family *.rfa file
And it was that simple. For me, the macro processed around 350 families in a few seconds.
Once complete, you can reload the families into your template or project file and then process the files through BIMLink as per usual to rename the family and type names.
For any families that already had a determined type and have now ended up with two types, you can simply purge out the New_Family types from the model.
Quite a while ago I was looking for a solution for specification drawings, they crop up from time to time on small jobs when a separate specification document isn’t required.
The problem with these specification drawings though is that the content of the text usually started life in AutoCAD, then it’s imported and roughly tidied up in Revit, it’s usually copied and pasted from one job to the next and you end up with text that is cumbersome to modify and information irrelevant to the current project.
The answer to the problem is note blocks, in my opinion a brilliantly clean solution. The annotations can be placed neatly on a drafting view, the content of the annotations is then scheduled and you end up with a series of schedules that are easily arranged on your specification sheets. Modifying can be as simple as the modeler editing the text within the annotations or the content can be exported using BIMLink, Dynamo, custom C# macros or addins ready to be modified by the engineer and re-imported to Revit.
I was working at another company when I put together a demonstration project, did a short presentation on how it works and was flat out told “No. This solution is too difficult for the average user.” And that was the end of that. We continued trundling on with cumbersome, incorrect and generally backward methods of creating and maintaining specification drawings.
I briefly mentioned this method for specification sheets in a Reddit post and I was asked how this works, so with that glimmer of hope that someone might find it useful, this is how you go about it.
First, start with a generic annotation. This is simply for display on your drafting view and of course to hold the data in for your schedules. Mine simply looks like this
Each of these labels are a simple instance family parameter.
The parameters I used were
Number – Used to order the notes
Note – The note itself
Category – This is used for each heading in the specification sheet. For example in hydraulics this could be Stormwater, Hot & Cold Water, Drainage etc. or for electrical it could be Lighting, Power, Lightning Protection etc.
Blank Spacer Left and Right – These are to give a cleaner look to the note blocks on the sheet, they’re personal preference only.
Region – I had to deal with region specific notes both within Australia and also internationally.
Once you have the family loaded into a project, create a drafting view to arrange your annotation symbols. Mine looked like so
I manually typed in the headers that you can see just for my own reference, the headers aren’t required though as all the required information for scheduling is contained within the families themselves.
The next step is to create the schedule itself. If you’re not aware, the note blocks can be found under the schedule drop down on the ribbon.
You will then be prompted to select the annotation that you want to schedule.
From there, select all the parameters associated with the annotation that you need for your schedule.
Filter out the annotations you need for this particular block of notes, in this instance I am working with hydraulics acoustic notes for Queensland.
Sort by the number, formatting and appearance is obviously up to you and your documentation standards.
Rinse and repeat for your remaining categories. My project ended up looking like so
It takes a little bit of time to setup, but once you’re done future modification is simple and if you don’t need to modify the notes, even better! If you’re worried about template clutter, the schedules don’t need to live in your base template either, they can be located in a separate *.RVT file where all the standard notes and schedules are kept and can then be imported to the project as required.
The result is a clean, easy to organise specification sheet. If you don’t want a particular section, it’s quick to remove and re-align the remaining parts. If you don’t want a certain note to show up, you can filter it out by changing the number to xx or delete it from your drafting view. Engineers can confidently take responsibility for what is on their drawings without worrying about typos, misreading of hand markups or information hanging over from previous projects.
And finally, you can see here how the blank left and right parameters affect the schedule. As mentioned previously these are entirely optional, I just liked the resulting layout of the notes.
To get you started, you can download my example annotation family here
I’ve been poking my nose around Revit Forum a little more lately and a post in the MEP forum prompted me to write a little bit about hydraulic pipe sizing. I speak with a lot of guys in MEP locally and they give me the impression that they think pipe sizing is some kind of dark art, in actual fact it’s not that difficult at all.
In my response to the original post, I just created some generic plumbing fixtures to show the example, but I thought I’d take some time to go into a little more depth on sizing domestic hot and cold water services, my examples are going to be somewhat based around AS/NZS3500 Parts 1 and 4.
The Basics of Pipe Sizing
Before you begin, to perform pipe sizing for a plumbing system, you need to have a good set of families that have either flow rates or fixture unit ratings applied to the piping connectors. A good set of families are the building blocks of good pipe sizing results.
In the past I’ve mentioned that I have these basic families for plumbing fixtures that are simply place holders for the pipe connections. There is no need for elaborately modelled fixtures in an engineering model. If you like, you can even copy/monitor the architect’s fixtures and then map them inside your model to your engineering fixtures. The idea of these plumbing fixture families is explained really well in an AUGI article that Dave Benscoter wrote back in early 2013.
The placeholders for the piping connections are controlled by parameters for height, spacing, diameter and offset from the wall (for drainage). A lot of these adjustments may not be required on most jobs, but the ability to take the modelling further is there ready to go when needed. The family allows for automated tagging of fixture abbreviations, pipe sizing calculations and if you go to the effort of making a family type per specified fixture, you can generate accurate penetration drawings as well.
Another alternative that I have used is rather than model all the pipework up to and including the plumbing fixtures is that I will have an isolation valve box family where I fill out the fixture units of the fixtures it is serving. Just remember, if you’re doing this and you’re entering a flow rate it should be probable simultaneous flow – also called diversified flow – for which I usually rely on the Barrie Smith ‘Blue Book’.
If you’re using out of the box (OOTB) Revit families, check the loading units (which are called fixture units in Revit) and check that they match the requirements of AS/NZS3500.
In my example, the plumbing fixture connectors have their direction set to in and the hot water unit has the cold water set to in and the hot water set to out. The cold water inlet of the hot water unit also has an instance parameter where I can enter the downstream probable simultaneous flow.
You need to make sure that there are no open ends in your system, in 2014 and newer, you can use the Cap Open Ends tool if required.
The small box in my example is to cap off the end, it is set to out as it is essentially the water connection to the site.
For the purpose of the demonstration, I’ve created all the distribution pipework at 50mm. The connections on the basins are 15mm and the hot water unit I’ve used is a Rheem 613050 so both the inlet and outlet are 32mm.
For the cold inlet to the hot water unit, you can set it up to work on either fixture units or a litre per second rating. If using a litre per second flow rate, make sure that it is based on a probable simultaneous flow value.I’ve used probable simultaneous flow in my example, which based on the Barrie Smith Blue Book is 0.21l/s
Once you have all your pipework and fixtures connected, select the pipework that you want to size and you will see the Duct/Pipe Sizing icon on the ribbon.
The next step is to input the data of how you want to size your pipework.
The options available to you are to size by maximum velocity only, or you have the option to select either and/or maximum pipe friction in pascals per metre.
You can also set additional constraints using the drop down box, the options are calculated size only, match the connector size, or to use the larger of either the calculated or connector size.
Finally, you can also restrict the maximum pipe size that is allowed in your system.
I am simply going to size the piping based on a maximum velocity of 3.0m/s (AS/NZS 3500.1 Clause 3.4).
In the constraints section, restricting the sizing to that of the connector allows you to achieve the 15mm branch to a single fixture rule (AS/NZS 3500.1 Clause 3.5.2) however keep in mind that Revit will size the pipework as 15mm until the next branch (tee) fitting so if your fixture is further than 3m from a branch you will need to adjust the pipe size manually yourself. Revit will also oversize branches of pipework connected to a larger fitting as shown below with the HWU. You should always check your sizing results and never rely on Revit to do all the work for you.
As you can see, other than our oversized pipework from the HWU highlighted in red, the results are quite good.
You could argue that my 25mm incoming connection is too large to serve only 5 hand basins. The reason it sized to 25mm is because of my flow value on the cold water inlet to the HWU. If I change the cold water connection to use fixture units, and manually enter 5 fixture units, the incoming pipework is reduced to 20mm.
Analysing Your Pipework Velocities With Revit
You can create a view in Revit that analyses the velocities of your pipework (amongst other things). This can assist you when reviewing your pipework sizing with easy to follow graphical displays of your pipework velocities. You can find the Pipe Legend tool on the Analyze tab of the ribbon.
The results give an easy to follow display of your pipe velocities by colour, you can clearly see that the 32mm pipe from the hot water unit has a velocity of 0.9m/s
Manually adjusting the pipe size to 20mm, you can now see that the velocity of the pipe exiting the hot water unit is now 2.7m/s or changing to 25mm, the velocity is 1.5m/s. Based on velocity, either pipe size is acceptable under the Australian Standards.
Creating a Pressure Loss Report
Finally, you can also run a Pipe Pressure Loss Report which is found on the analyze tab.
The pressure loss report is generated in HTML format, I am simply going to select the cold water system only and I’m going to display the system information and the critical path.
The resulting report shows that we have 51.1kPa of pressure loss along the critical path. Referring back to AS/NZS3500.1 we require a minimum pressure at the outlet of 50kPa (Clause 3.3.2) which tells us that we need a minimum of 101.1kPa at our connection point.
Conversely because the maximum allowable static pressure at an outlet is 500kPa (Clause 3.3.4) if we had 600kpa available at the connection point we would need to install a pressure limiting valve to comply with Australian Standards.