In the past months, we’ve been working closely with consulting engineering firms to produce families that work with their shared parameters. The process has brought to the surface some issues that we think deserve closer attention for the way that they can impact the long-term utility of a firm’s shared parameters.
The first issue concerns itself with the units assigned to shared parameters that relate to MEP systems. In our recent experience, we’ve found that many of the parameters associated with duct or pipe connectors get set with generic disciplines and units. For example, a parameter for “Water Diameter” pipe connection would be set to a discipline of “Common – Length” as opposed to “Piping – Pipe Size”. Or “Water Pressure Drop” would be created as “Common – Number” instead of “Piping – Pressure”.
When raising this issue to clients, they will counter that having these parameters in Common units doesn’t have any adverse effect on Revit system calculations and that it actually makes their scheduling workflow easier. There’s some truth to this argument, but also some potential drawbacks, so let’s take a closer look.
When I place a pipe connector, for example, and select the loss method as Specific Loss, I then need to path family parameters for flow rate and pressure drop to the connector (see image below). In order to path family parameters to the connector parameters, the family parameter values must be in the correct discipline, otherwise Revit will not path them. The family parameter for Pressure Drop, for example, must be in discipline “Pressure”. So, if I set my shared parameter for Water Pressure Drop to be in units of Common – Number, then I’m going to have a problem if I want to have that parameter pull its value from a piping system connector.
Electrical connectors can have even more values that need correct parameter pathing, especially a power connector that will have Number of Poles, Voltage, Current, etc. All of these need to be in the correct units. So these need to be identified in the firm’s shared parameter file and updated if incorrect. This is something that we’ve talked about for years, but it still gets overlooked more often than it should.
On the other hand, the particular discipline used for assigning units has a much more subtle impact. For example, let’s consider a shared parameter that will control a pipe diameter. In this case, Revit allows more than one discipline-unit to be pathed into the radius/diameter of the connector.
In the image below, I created a simple test family. Within the family there is a diameter parameter for each discipline-unit (pipe size, duct size, pipe dimension, common length etc…). When I start to path a parameter to the connector’s diameter, you can see in the image that the parameter type is simply “Length” and that Revit allows you to path ANY length parameter to the pipe connector, even a nonsensical one like duct size.
This raises the question of why we should bother to specify the shared parameter for a connector length as anything other than “Common – Length”. I believe the answer has to do with units and having the control to use different units for your piping, ducting and general lengths/dimensions. By assigning different discipline-units to different shared parameters for length, a project can have its piping shown in millimeters, duct in inches, and so on.
So Revit gives the user the ability to exercise more fine-tuned control with how units are displayed on a drawing (tagged). But if we just use “common – length” for any shared parameter that can take it, we lose that flexibility and open ourselves up to the possibility of inconsistencies between drawings and schedules, or even inconsistencies on the MEP layouts depending on which elements are tagged in the drawing.
In addition, for pipe systems in particular, there is an intrinsic parameter called “Size” which is set as a Piping – Pipe Size parameter (see image below). I can change the fitting connectors to use Common – Length or even Pipe Size – Pipe Dimension, but the pipe’s “Size” will always be a Piping – Pipe Size parameter. Duct systems also have an equivalent setup. This is another reason why it is best to have the correct mechanical units for these types of shared parameters.
Another concern we’ve encountered in our recent work is the use of a single shared parameter across multiple applications or contexts. For example, one of our clients had a shared parameter called “Diameter”, which they would use for pipe connections but also for the diameter of other cylindrical geometries such as expansion vessels. In the short term, this can easily seem like the most convenient and common sense approach. Rather than users having to choose from among various diameter parameters, you can be assured that everyone will use the same shared parameter across different teams, projects, etc.
In the long term, however, this approach ends up tying your hands and introducing confusion. First there is the issue described above of limiting your tags to all display in the same units. By using one shared parameter for every kind of diameter, you can’t have piping tags display a diameter symbol and your expansion vessel tags display in millimeters. But secondly and perhaps more importantly, what happens when a family has both a cylindrical geometry and a piping connection? If you only have one shared parameter for diameter, then either you can’t schedule or tag both, or you end up creating a new shared parameter on the fly to work around the limitation. Usually it will be the latter that ends up happening, which is what leads to having inconsistent and messy shared parameter files over the course of time.
Instead, I prefer taking an approach that can be successfully applied no matter how simple or complex the circumstances. In the previous example of an expansion vessel and heat pump, I would have one shared parameter called “Vessel Diameter” and another called “Water Diameter”. They can be used independently or at the same time as required.
It’s true that such an approach takes more careful planning to determine when you will need multiple shared parameters to cover different circumstances, exactly how specific a shared parameter ought to be, how to effectively review and update your shared parameters file when new circumstances arise, etc. But from my experience working with Revit as an MEP coordinator and family creator, the more work you put into structuring your families and adhering to Revit best practices, the better your workflow and results will be, not only for the present day but for well into the future. And isn’t that what BIM is supposed to be all about?
