Views to uppercase

Standard architectural documentation convention dictates that all notes should be in uppercase. When working in Revit, if a team member hasn’t followed this convention, it can be a major task to fix, especially if you have hundreds of views and sheets. Rather than updating these manually, it is possible to use a plug-in such as BIMlink to export the values into Excel where they can be modified using the UPPER () function, before being imported back into Revit. This is somewhat tedious and can be further expedited with the use of Dynamo.


As part of the BVN Dynamo package (v1.4.3), there are three custom nodes: ‘View.NameToUppercase’, ‘Sheet.NameToUppercase’, and ‘Schdule.NameToUppercase’.

The ‘View.NameToUppercase’ uses the ‘View.IsViewTemplate’ node from the Clockwork package and will update both the view name and “Title on Sheet” parameter.

The ‘Sheet.NameToUppercase’ will update both the sheet name and sheet number parameters.

The ‘Schedule.NameToUppercase’ is a little more complicated because we need to exclude the revision schedule which are nested into title block families. Once this is done, it will update the view name.


Despite being super simple, these custom nodes are highly effective and may save you loads of time.

Rotate & swap values

When spatial planning, some practices prefer to use proxy Revit elements to speed up the design iteration process. At BVN, we have developed a suit of families which we call ‘Push-it’. We use this methodology for the early stages of healthcare projects where the schedule of accommodation is critical.


In this workflow, an architectural column family is created which represents a ‘real’ Revit room. It contains various instance parameters including the width and length. This allows users to easily flex the family without fear of the room ‘breaking’ due to a missing wall. Hence, it is a quick and dirty spatial planning tool before we proceed to substituting these families for real Revit rooms and walls.

The family has a 2D door family nested into it. Using instance parameters, the user can decide where the door is to be placed. However, to ensure fast computation, only two adjacent walls are available for the door to be placed. If the door is required to be in the opposite wall, the family can simply be flipped using the instance hands. Sometimes when placing the family, users will not set the rotation correctly, resulting in doors not opening onto the corridor. To fix this, since only two door locations are possible, the family must be rotated 90 degrees, flipped if required, and then the width and length parameters swapped.

Obviously, prevention is better than cure but if some families do manage to slip through the gaps, you can use the ‘Family.RotateAndSwapParameters’ custom node available in the BVN Dynamo package (v1.4.2). The node will rotate the family 90 degrees and swap the width and length parameters. By default, these parameters are named ‘SP_Width’ and ‘SP_Depth’ but they can be updated to suit your own shared parameter names. After running the script, the room should look exactly the same but with the door on the adjacent wall.

The custom node first calculates the existing rotation of the family. Known as ‘Facing orientation’, the rotation is actually expressed as a vector within the Revit API. If you simply try to rotate the family 90 degrees using the ‘FamilyInstance.SetRotation’ node, it will override the facing orientation rather than adding 90 degrees to the existing rotation.

Therefore, we need to use the ‘Vector.AngleAboutAxis’ node to compare the existing facing orientation to the Y-axis to calculate the existing rotation in degrees.  Once calculated, we can set the rotation to equal the existing rotation plus 90 degrees. After that, it is just a matter of swapping the width and length values.


Rename working views

Revit’s Project Browser allows you to sort and group views and sheets within your project. Each practice will generally have their own preferred project browser configuration embedded within the project template. Despite their differences, many practices adopt an approach of separating documentation views from working views. Documentation views are generally views which reside on sheets. They will generally be ‘locked down’ with the use of a view template. This ensure the views appear as desired when you go to print the sheets.


To avoid the temptation of working in the documentation views, separate working views can be generated. Note that this isn’t essential and some practices/projects prefer to utilise the ‘enable temporary view properties’ command. However, from experience I find this method more cumbersome and prefer to have my own working views.


When creating the working views (View > Create > Plan Views > Floor Plan), you have the option of setting the view type. By creating a dedicated working view type for each team member, view templates can be applied automatically when the new views are created.

To maintain flexibility within the working views, the view templates should only include values for how the view is to be organised within the project browser. All other parameters, including model categories, can be excluded from the view template.

During the view creation process, Revit will typically suffix each new view with “(1)” to distinguish it from the main view. Having views named “LV 00(1)” is not very descriptive. At BVN, our convention is to rename these views so that the suffix is your initials, for example, “LV 00_PW”. Depending on how many working views you have, this can be a time consuming process.


To automate this process, I have developed the ‘View.RenameWorking’ custom node as part of the BVN Dynamo package (v1.4.1).  The node allows for two levels of view filtering. The default parameter for the first filter is “Design Stage”, which is set to “Working”. The default parameter for the second filter is “BVN Alphabet”. The second filter value is the new suffix, typically your initials.

By running the script it is possible to batch rename all of your working views. Note that if you have a copy of a copy, for example, “LV 00(1) Copy 1”, you may receive an error message within Revit saying “the name you specified is already in use. Enter a unique name’. In this scenario, the view will be excluded and will not be renamed.

Rename grids

When creating grids in Revit, Revit will name/number them in the order that they were created based on the naming convention last used. If you haven’t been consistent in your creation of grids, you’ll more than likely need to rename them. This can prove problematic as Revit will not allow you to have two grids identically named. If you try, Revit will return an error saying, “the name entered is already in use. Enter a unique name.”  As a workaround it is necessary to temporarily rename the grids before naming them as intended.

To speed up this process I have developed two custom nodes available in the BVN Dynamo package (v1.4.0).  ‘Grid.RenameAlphabetical’ will rename grids alphanumerically from A to ZZ, excluding “I” and “O” as per convention. ‘Grid.RenameNumerical’ will rename grids from 01 to 99. The sortAxis input requires a string, either “X” or “Y”, which relates to the axis the grids are sorted along. This affords flexibility in deciding which values (alphanumerical or numerical) you want to run from left to right, and bottom to top. The tempPrefix input is a string which can be used if other grids are currently using the same mark value. The toggle will update the temporary mark values to the final mark values.

Flux Dashboard

Dashboard is an app developed by Flux and can be launched from your Flux home page. Unlike some of the other apps developed by Flux, it is not yet open-source. To create a Dashboard:

  • Create your Grasshopper or Dynamo script with the usual input components to verify the script is working as intended.


  • Create a new Flux project .
  • Add in all the data keys that you’ll need, matching the Grasshopper/Dynamo inputs and outputs. For example, in our ‘twisty tower’ example I’ll need to create 10 as follows (6 input, 4 output):



These are currently empty keys. We’ll assign a value to the keys later.

  • Back in Grasshopper/Dynamo, replace the input slider with Flux components. We’ll need to use the ‘Flux Project’,  ‘Select from list’ and ‘From Flux’ components. These components will pull data from Flux. When removing the input components, be sure to take note of its function so that you can match it up with the relevant Flux key in the ‘Select from list’ component. Since the Flux keys don’t have a value yet, you will likely get an warning errors. This is OK.


Similarly, add in the new Flux output components to send the data to Flux. We’ll need the ‘Select from list’ and ‘To Flux’ components. Note that Flux only supports the following data types.

  • In your Flux home page, click the ‘Launch’ button under Dashboard.


  • Create a new dashboard by clicking on the plus button.


  • Add in new dashboard panels as required. Generally you’ll need a ‘slider’ panel for an input, a ‘geometry’ panel to visualise the geometry, and a ‘value’ panel to report a value such as Gross Floor Area.


  • When creating the dashboard panel, select the key to be paired with and give the slider a name (usually the same as the key). The min and max of each key is controlled here as well as opposed to Grasshopper or Dynamo, which is somewhat frustrating.  Rather than adding multiple individual sliders, it is often better to ‘add a slider’ within the slider dashboard panel to create a multi-slider. The sliders will be structured in the order that they were created. Currently it is not possible to re-order the sliders once created, something I’m sure will be fixed in the near future.

  • Once created, each dashboard panel can be scaled and moved as required.


  • Modify the Flux sliders as required. There will be a short lag between adjusting the sliders until the geometry is updated. This is because data is flowing from Flux into Grasshopper before being send back into Flux. This process could be sped up by creating the entire script within the Flux Flow app, thereby eliminating Grasshopper or Dynamo altogether. Also note that unlike Dynamo or Grasshopper, it is not possible to double click in the slider and enter the desired value. You must use the slider by sliding it which makes achieving the desired value difficult.


Overall Flux’s Dashboard is still in an embryonic state and has some development to go before it is sophisticated enough for what most architects need. Plug-ins like HumanUI or Conduit offer much more advanced user interfaces if using Grasshopper. If your using Dynamo then there are less options. While the dashboard example above can be shared via a URL, it requires the recipient to have both Rhino, Grasshopper, Flux and any other plug-ins installed to run as expected. Therefore, in order to harness the full potential of Dashboard, the underlying script really needs to be written in Flow, Flux’s visual programming app. This would allow easy URL sharing, cloud computing and eliminate any software installation. The obvious problem with this is that Flow uses a completely different language to that of Dynamo or Grasshopper. Any existing scripts would need to be rewritten completely from scratch within Flow which is not necessarily practical nor desirable. Having said that, I’m sure Flux is aware of its limitations and I look forward to seeing the product evolve to reach its true potential.

Calculate golden mean

If you like your classical architecture and proportions, you will be familiar with the concept of the golden mean. Also known as the golden ratio or golden section, it has fascinated architects and artists for centuries. The golden rectangle is thought to have the most pleasing proportions of any rectangle.


When spatial planning, it may be useful to first start with a room’s ‘ideal’ proportions, before adjusting it to suit the various project’s requirements. One example of how this could be used is in healthcare where the schedule of accommodation is critical.


In this workflow, an architectural column family is created which represents a ‘real’ Revit room. It contains various instance parameters including the width and length. This allows users to easily flex the family without the fear of the room ‘breaking’ due to a missing wall. Hence, it is a quick and dirty spatial planning tool before we proceed to substituting these families for real Revit rooms and walls. The family also contains the briefed area and actual area for instant visual feedback.

Since we know what the area should be and the equation for the golden rectangle, we can calculate with simple algebra the width and length. To automate this process, I have created the ‘GoldenMean’ node as part of the BVN Dynamo package.

Note that the area input, and the width/length output, will be of the same unit. Therefore, if you are modelling in millimetres but your area schedule is in metres, you’ll need to use the ‘Convert Between Units’ node.

Sheets from Excel

When developing a project document list, the most convenient way is to create the information within Excel. The formulas and formatting in Excel allow for a lot of mundane document management tasks to be expedited. The next step is to get the document list into Revit and generate sheets from that list.

For a simple document spreadsheet containing sheet number and name information, we can use a simple Dynamo script as follows.

The title bock family and file path of the sheet list needs to be assigned as the inputs for the script which then get sorted and any redundant spreadsheet data removed before the sheets are created. There are 2 possibilities for sheet creation within Dynamo:

  • ‘Sheet.ByNameNumberTitleBlockAndView’ – This is a standard Dynamo node that requires, Sheet Names, Sheet Numbers, Title block Family Type, and View inputs. If the project is in very early stages the views for the sheets are generally not created, so they cannot be used as an input without generating an error.
  • ‘Tool.CreateEmptySheet’ – This is a node from the SteamNodes package that requires, Titleblock Family Type, Sheet Numbers, Sheet Names and the refresh inputs. The good thing about this node is that you don’t need to have the views in your model already created for it to work, as it will create empty sheets.


For a more complicated spreadsheet, we may have multiple worksheets and additional parameter information. For example, BVN utilises an organisation method for assigning different trade packages in a document set via the ‘BVN Alphabet’ parameter. This allows us to group and easily identify views and sheets in the Project Browser and group trade package documentation together. In the example below, the Excel document spreadsheet is identifying Sheet Number, Sheet Name, BVN Alphabet series, Sheet Issue Date, Design Stage, as well as having multiple worksheets corresponding to the different BVN Alphabet series.

Although these additional fields allow for greater functionality in Excel they add complexity in how Dynamo extracts the data. The enhancements to this script allows for the additional sheet tabs in excel to be read.

Elements on worksets

When converting a non-workshared model into a workshared model, all elements apart from grids, levels and reference planes will be automatically assigned to the default workset ‘Workset1’ (unless of course you renamed it something different). This is not very useful and depending on how far progressed the model is, it can take significant time manually assigning elements to the respective workset. Historically, BIM managers have utilised the Ideate Explorer add-in as a way to speed up the process.


To assign elements to a particular worksets, it was necessary to sort by ‘category’, and then possibly use the Ideate Query function to further refine the selection process before modifying the selected elements Workset parameter in the Properties Pallet.


Once assigned to a workset, it is possible to sort by ‘workset’ and then find any offending elements and change their workset parameter in the Properties Pallet.

This can be a very time consuming process, especially if you need to repeat multiple times. However, we can use Dynamo to automate this process.

As the worksets created are to an office standard they can be pre-programed into the Dynamo script for element assignment. The ‘Element.AssignToWorkset’ node utilises the BVN workset naming convention to automatically assign model elements:

  • 00_FACADE:
    • Non-structural walls, floors and roof whose type’s ‘Function’ parameter is ‘External’.
    • Windows and doors whose type’s ‘Function’ parameter is ‘External’.
    •  Walls, roofs, floors who has the ‘Structural’ instance parameter checked.
    • Structural columns.
    • Note that this process takes precedence over the façade workset. Therefore, if a wall is both external and structural, it will be placed on the ’10_STRUCTURE’ workset.
    • Ramps and Stairs.
  • 30_INTERIOR:
    • Room
    • Non-structural walls, floors, roof, windows and doors whose type’s ‘Function’ parameter is ‘Internal’.
  • 40_FF&E:
    • Furniture, Furniture systems and speciality equipment.
  • 50_SITE:
    • Topography, planting, entourage and parking.
  • 60_MASSING:
    • Masses.
  • 99_LEVELS & GRIDS:
    • Levels, grids, reference planes, reference lines, and scope boxes.


Again this node is highly specific to one particular workflow but it can be easily modified to suit your specific needs.

Create & rename worksets

This tutorial will present how to create and rename the default worksets using Dynamo. Note that before you create worksets you will need to enable worksharing. To do this in Revit 2016 or earlier, it was possible to click on the ‘Worksets’ button in the bottom ribbon or alternatively, go to Collaborate > Manage Collaboration > Worksets.


However, for whatever reason, in Revit 2017 it is no longer possible to activate worksharing via the Workset button. It is only possible via the Collaborate > Manage Collaboration > Worksets.

If you are using Revit 2017, you will be asked how you want to collaborate: Collaborate within your network; or, Collaborate using the cloud

Once worksharing has been enabled, Revit will create default worksets and assigns elements and settings to these worksets. The default worksets are as follows:


  • ‘Shared Levels and Grids’ – Contains all existing levels, grids and reference planes. Note that if you choose to collaborate using the cloud via BIM360, the workset will be named ‘Shared Views, Levels and Grids’.
  • ‘Workset1’ – Contains all existing model elements in the project. Once created, this workset can be renamed but it cannot be deleted.


Worksharing window using Collaborate within your network


Worksharing window using Collaborate using the cloud


If you have an office naming standard for worksets, we can automate the creation of them. For example:

  • 00_FACADE
  • 40_FF&E
  • 50_SITE
  • 60_MASSING
  • Etc.


The Dynamo script utilises the BVN Package node ‘Workset.CreateAndRenameDefault’ to add the new worksets and rename the existing default worksets.


At BVN we have decided to do something a little tricky with the default worksets. Since ‘Workset1′ cannot be deleted, we figured it was best to rename this workset to something which we would always have in every project. That is, it would never be deleted. We concluded that the most logical workset was actually ’99_LEVELS & GRIDS’. Therefore, as shown in the screenshot, the ‘Shared levels and grids’ is renamed to ’60_MASSING’ (or whatever will be your most dominate workset) and ‘Workset1′ is renamed to ’99_LEVELS & GRIDS’. If you don’t want to follow this protocol, simply reverse the inputs. Once the script has run you should see something like this in the workset window.

Parametric Monkey reaches 100k views!

When starting Parametric Monkey, my aim was to accelerate computational literacy within architectural design. The genesis of this idea was simple. Over the course of my architectural career, I continued to come across technical issues when working with digital design tools. Parametric Monkey was created as a platform so that I could share this knowledge with others. I had no idea the impact it would have.

I am humbled and proud to announced that Parametric Money has now passed 100,000 views and 40,000 visitors from over 100 different countries. This is a major milestone for us and I would like to thank everyone involved for making it such a success.


As evidenced by the three most popular posts, Parametric Monkey focuses on the intersection of parametric design and BIM:

  • Construction Communication – The outcomes of a BIM course I ran at Hong Kong University (HKU) where students were asked to encrypt and codify what are otherwise complex architectural effects into clear methods of construction.
  • Rhino to Revit workflowThis is a list of best practice workflows to follow when generating Rhino massing for importation into Revit.
  • Dynamo for GH usersA *PDF primer which contains tips and translations to help migrate your Grasshopper skills to Dynamo.

The most commented tutorial was Renumber Doors by Rooms which demonstrates how to automate the renumbering of Revit doors based on the room in which it is located using Dynamo. With now over 80 tutorials covering Revit, Rhino and numerous plug-ins, 2017 promises to be even bigger and better for Parametric Money.