shared parameters

Fixing SP.Writer Run Time Error 70

If you’re like me, you haven’t used SP.Writer in a while but then if you’re also like me, you will at some point need to use it to generate a project customised shared parameters file. The first thing you do is pull out your trusty SP.Writer only to find that when you create a new parameter you get a run-time error 70.

If you hit the debug button, you will be taken to the mod_GUID module and the 4th line will be highlighted as the problem child.

The function used to create the GUID in SP.Writer was patched in the July 2017 security patches for Microsoft Office so if you’re up to date with your security patches, this is working as intended. That doesn’t help us in the slightest with creating shared parameters though, so what’s the solution?

First if you haven’t already done so, you’ll need to enable the developer toolbar in Excel which you can do by following the instructions over at the Microsoft website.

Once enabled, select Visual Basic from the developer tab on the ribbon. Alternatively you can use the ALT+F11 shortcut on your keyboard.

On the left hand side of your screen, you will see a window titled Project – VBA Project, scroll down until you find Modules. Right click on modules and from the contextual menu select Insert.. -> Module.

Copy and paste the following code into the new module.

Private Type GUID_TYPE
Data1 As Long
Data2 As Integer
Data3 As Integer
Data4(7) As Byte
End Type

Private Declare PtrSafe Function CoCreateGuid Lib "ole32.dll" (guid As GUID_TYPE) As LongPtr
Private Declare PtrSafe Function StringFromGUID2 Lib "ole32.dll" (guid As GUID_TYPE, ByVal lpsGUID As LongPtr, ByVal cbMax As Long) As LongPtr

Function CreateGuidString()
Dim guid As GUID_TYPE
Dim sGUID As String
Dim retValue As LongPtr
Const guidLength As Long = 39 'registry GUID format with null terminator {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}
retValue = CoCreateGuid(guid)
If retValue = 0 Then
sGUID = String$(guidLength, vbNullChar)
retValue = StringFromGUID2(guid, StrPtr(sGUID), guidLength)
If retValue = guidLength Then
CreateGuidString = sGUID
End If
End If
End Function

You can also rename the module, I renamed mine to mod_CoCreateGUID as this is will be method we’re using to generate the GUID. If you can’t see your properties window, press the F4 button.

 

Next, open the module mod_GUID and replace the existing code with the code below

Sub GetGUID()
Dim sGUID As String
sGUID = CreateGuidString()
wsData.Cells(LastRow + 1, 2) = "PARAM"
wsData.Cells(LastRow, 3) = Replace(Replace(sGUID, "{", ""), "}", "")

End Sub

 

The final step is to make a small change to the UserParameter form. In the VBA project, find the UserParameter form and right click and select View Code from the contextual menu.

Search for the code

'generate the GUID
GUID

and replace with the code

'generate the GUID
GetGUID

and that’s it! You’re done! You can now start creating shared parameters again. The GUID looks a little longer but it’s actually just the difference in length between upper and lower case with the font used.

Lookup Tables and You – Part 2 – Improving Your Workflow

Now you understand how lookup tables are formatted and referenced from Revit families, let’s have a look at how we can improve our workflow.

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

ParameterName##number##integer

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

size_lookup(Lookup Table Name, “”, “NOT SPECIFIED”, TankVolume)

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.

Download a copy of the Iplex DWV piping catalogue from http://www.iplex.com.au/iplex.php?page=lib&lib=8&sec=186 we will be referring to the Plan Bend F&F on page 24.

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.

Iplex Catalogue Revit Family
L1 – L2 (from fitting table) Centre to Socket Bottom (CtSB)
L2 (from fitting table) Socket Depth (SDpt)
a (from fitting table) Angle
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.

Lookup Tables and You – Part 1 – Understanding Lookup Tables

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

ParameterName##ParameterType##ParameterUnits

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.

 

Quick and Dirty AutoIT – Delete Project Parameters

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.

While 1
; usually a good idea to put this in so you don't max your CPU
; open your project parameter window and hit go!
Sleep(100)
;click remove
ControlClick("Project Parameters", "", "[CLASS:Button;INSTANCE:3]")
Sleep(100)
;confirm remove
ControlClick("Delete Parameter", "", "[CLASS:Button;INSTANCE:1]")
Sleep(100)
WEnd

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.

Using Dynamo to Generate Mark Parameters from Information in Families

I recently had a question as a follow up to my bi-direction Excel using Dynamo post

Hi Ryan,

I’m trying to use the same concepts to export all structural columns. The node you used (family types) only exports 1 type at the time.

Do you know if there’s a node that lets me export all types of the column family I use in the project?

The node that you want to use to do this is All Elements of Category which you need to feed with your selection from the Categories node.

I thought I would share an example of how I used this node to generate individual type marks for all the columns on the project based off the family name and the level that the column is located on.

Of course generating the mark parameter from the family name means that you need a fairly solid and consistent naming convention in place. You could also use other type parameters within the family, this is just the method that I chose as an example.

Before we get started, I have used the Revit 2015 Sample Structure Project.RVT file and renamed the family types like so

 

The overview of this particular example of the Dynamo Script looks something like this, so let’s step through what it is doing.

2015-07-13_14-07-01

Getting started, we use our Categories node which we use to select our Structural Columns category. As mentioned earlier we feed that into the All Elements of Category node.

2015-07-13_11-12-25

Stepping through the top row, our elements feed into the Element.GetParameterValueByName node, and we’re picking up the Base Level parameter.

2015-07-13_13-49-43

2015-07-13_13-51-31

We then pass through to the Level.Name parameter which gives us the level name as you see it in the project browser as a string, which in this case is “01 – Entry Level”. Using the String.Split node we split the string in half using a Code Block node and entering ” “; into the code block to denote the space.

Think of this as the same as the Text to Columns command in Excel.

This gives us a list that splits the level name into

“01” “-” “Entry” “Level”

From here, run the data through the List.Transpose node and then finally into the List.GetItemAtIndex node, here we need the row at line 0 so we use a Number node to define the index.

You can alternatively use a Code Block node and enter “0”; as the code which works the same as the Number node.

On the bottom row we are taking our family type name and pulling out the type itself from the string that is returned. Even though when scheduling the Type parameter returns just the type, the string that is actually returned from Dynamo is in the format of Family Type: CRC 450, Family Name: STR_CONCRETE_ROUND_COLUMN.

So following a similar sequence to the top row, we split the string down to what we want which is “CRC 450”, to do this we need to split the string twice; first by the colon ( : ) and then by the comma ( , ). As you can see in the screenshot we need to transpose the list and pull the data at each row twice to get what we’re after.

2015-07-13_14-20-45

At the lower right corner there is a number generator. It is simply stepping from 1 to 200 in increments of one. Make sure to run the Number.Sequence node through the List.Transpose otherwise you will cause Dynamo to lock up while generating incredibly long number strings if you feed the sequence directly into the mark parameter.

 

Finally, we use a Code.Block node to concatenate the data we have pulled into a single string. The code block is simply a+b+c+d; which gives as four variables of the same name that we can feed the rest of our data into.

I have then created another list which consists of the Element ID and the string, we then finish up by selecting our string and populating the mark parameter as per my bi-directional Excel post.

Of course there are other options where you can generate the mark parameter from other type parameters in the family, I just chose to use the type name as the example this time around as I could show how you could break down a long string and the data you need from it.

Using Integers for Tricky Titleblocks

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.

2015-06-24_15-45-31

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

2015-06-24_15-55-02

Each of the visibility parameters are then associated with the integer value by simply using the formula KEYPLAN_INT = x where x is the value associated with each level and zone. So for example, KEYPLAN_INT = 24 looks like this

2015-06-24_15-59-10

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.

2015-06-24_16-14-23 2015-06-24_16-18-32

 

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.

 

 

Navisworks Quick Tips

I’ve been focusing a lot on documenting Navisworks procedures at work of late, for whatever reason Navisworks seems to be seen as some black magic witchcraft software package that no one wants to admit that they don’t entirely understand how to drive.

I sat in on a Navisworks session at the Revit Technology Conference last week just to see what others were up to and there was a surprisingly large turn out. The content presented was very much in line with my previous Navisworks articles and quite a few attendees seemed to be new to how Navis..works.

Helpful Tips

So based on that, I have two quick tips for Navisworks users, the first is selecting elements with a mouse click. When selecting elements in Navisworks, you might be selecting faces of elements or even the entire file rather than the whole element.

You can change what you select when clicking by heading to the Home tab on the ribbon and then heading to the Select & Search panel. Click on Select & Search and you will now see a drop down box.

2015-05-26_9-10-01

You can then choose what you want to select with your mouse clicks. If you want to select individual elements, you will want to choose First Object.

2015-05-26_9-09-49

 

The second tip is about the data that you export to Navisworks from Revit. You may remember in my Navisworks 101 series that I spoke about improving your clash detection with selection sets. To create really powerful selection sets, you need the data to drive them but you need to make sure that you’re exporting that data in the first place.

To correctly export Revit parameters to Navisworks you need to make sure you have the option Convert element properties checked – by default this setting is turned off.

You can find this option in two places. The first is Navisworks itself. Head to the application menu and select options.

2015-05-26_9-30-56

In the options dialogue box, in the left hand sidebar find File Reader and then select  Revit from the list, then from the options in the right hand window, check Convert element properties.

2015-05-26_9-30-33

You can also find this setting in the Navisworks exporter addin within Revit itself. Simply head to the Addins tab on the ribbon, then from the External Tools list choose Navisworks 201xright_circular-32Navisworks Settings and then check Convert element properties

The difference between the information you get in Navisworks when you change this setting is chalk and cheese.

With the setting unchecked

2015-05-26_8-53-12

With the setting checked

2015-05-26_9-02-36

As you can see, checking this setting will export additional parameters and properties related to the element including material information, associated level, shared parameters and much more.

Having this information available within Navisworks will allow for more accurate selection sets to allow for better clash detection results as well as time lining and quantities.

Making Revit Work For You Using Advanced Families.

Lately I have found that a lot of the buzz about Revit is 3rd party add-ins and software. Sure they’re great and save a lot of time in our workflow, but what about making Revit itself do some work for you?

Earlier this week I created a box gutter sump family that replaces an Excel spreadsheet that I used to use.

You simply input the data you would normally enter into a roof drainage calculation sheet into the Revit family, I also added a few more inputs to allow further control over the family. The inputs are

  • Catchment area
  • Rainfall intensity
  • Minimum box gutter depth
  • Minimum sump depth
  • Maximum sump depth

From there, all the calculations are built into shared parameters. I decided to use the KG Martin method for sizing (from the CSIRO Experimental Building Notes 1978). Hydraulic designers sizing roof drainage know all too well about h, 2h, Dg and Dmax which were easy to work into the family in a step by step process.

My original effort at creating this family I had devised excessively complicated formulas in an attempt to reduce parameters and what I originally thought to be simplifying the family as a whole. If I had taken advice from my Planning Families post though, I would have started out a little differently. When working through a family, you not only have to take into consideration the 3D elements, but parameters as well. What resulted in an excellent parametric family had absolutely nothing that I could schedule out.

With all the calculations undertaken step by step within shared parameters, I have 17 results I can include within a Revit schedule. The outputs from the family now include data such as:

  • Catchment flow rate
  • Calculated maximum flow rate achievable by sump/outlet combination
  • Depth of sump
  • h (depth of gutter flow at discharge end)
  • Dmax (depth of gutter flow at still end)
  • Dg (Dmax + freeboard)
  • Gutter high and low points
  • Td (total gutter depth)

The schedule includes conditional formatting to warn that either the outlet is too small or the sump too shallow/excessively deep. As a further step, I also included a visual warning in the family itself, displaying a text box indicating the error within plan view.

 

 

 

 

The schedule can then be added to a calculation sheet within the project for design verification purposes.

The data inputs for each sump/outlet can be controlled through the schedule, or the user can double click on the sump within the schedule which will then take them to the family within the project.

The next step is pipe sizing. You would probably know already that Revit does not include a sizing method that specifically applies to stormwater drainage, however I have had some success using the hydronic supply system type with accurate results up to 100l/s which of course uses the data calculated within the family.

For me, being a hydraulic designer and Revit modeller, this family eliminates some double handling in data entry, saving time in modelling and performing calculations. Data entry time is further reduced by creating a fixture tag that pulls the gutter size and sump size from the shared parameters with the family. All for a lazy 90mins development time.