Dynamo is a great platform for developing custom tools in Revit. Dynamo’s visual interface makes it easy for non-programmers to access the power of the Revit API and develop tools to suit their needs. Coupled with its open-source nature, Dynamo has quickly become the tool of choice for automation and computational design in Revit.
Yet many of the things that make Dynamo such a success hold back its widespread adoption by firms. Dynamo graphs or scripts need specific knowledge to run. Dynamo Player, released with Revit 2017 and further enhanced in Revit 2018, went a long way toward improving the usability for non-Dynamo savvy users, it still falls short of providing the seamless user experience available from a custom built add-in or macro.
Likewise, the open source nature of Dynamo, with its user-created packages of nodes, makes standardizing node libraries on each user’s computer an onerous task. If a user has a different version of a package installed, the particular graph may not run correctly. Troubleshooting the issue requires opening the graph and parsing the errors to determine which node failed, not a task a non-savvy user is likely capable of.
Shortcomings aside, a Dynamo library can provide users with a host of custom-built tools specifically crafted to the firm’s workflow. Unlike pre-built or even custom add-ins, Dynamo’s flexibility means that tools can be easily modified and deployed quickly. Also, Dynamo’s shorter learning curve means that firms can develop expertise in-house rather than relying on external specialists.
But exactly how can a firm develop a useful Dynamo library? What steps are needed to put one into place? Engineering firm IMEG provides a useful case-study on how to implement Dynamo on a large scale.
Using Dynamo at IMEG
IMEG is one of the largest consulting engineering firms in the US, with 40 offices and over 1,200 employees. IMEG provides engineering services for nineteen disciplines, including civil, MEP, structural, and technology. The firm was an early adopter of Revit, beginning with the structural group in 2006. MEP followed close behind, beginning use of Revit MEP in 2009.
IMEG’s use of Dynamo began as a grassroots effort. John Cook, a VDC specialist at IMEG’s Naperville, IL office, began using Dynamo three years ago to automate repetitive tasks he was encountering on a regular basis. Besides working on healthcare projects, John is also responsible for setting up and managing Revit projects within the office. “I was getting hammered on every day, doing manual tasks, “ John says. “I started building these really bad Dynamo graphs. But at the time, they were getting the job done.”
IMEG provides employees with personal folders on their network. John stored his Dynamo graphs in his personal folder, which was accessible to other users as well.
Sarah Garthaus, BIM Manager at IMEG and based out of the firm’s Rock Island, IL office, happened upon John’s stash of graphs. Seeing the potential for more widespread use, she cornered John at a BIM conference in the summer of 2016.
“So when I saw that John had this folder, my eyes got real big. I said ‘Hey buddy, want to make some more for us?’ That’s what kick-started the whole thing.”
Since that initial meeting two years ago, John and Sarah have built IMEG’s Dynamo library to 40+ graphs and deployed it to all their offices. The process has not been without challenges.
Here are five key things IMEG learned in the process of building their Dynamo library:
1. Use a development process
IMEG uses a three-step process to roll out new Dynamo graphs to the library. All new graphs are considered “alpha” graphs and their use is limited. John tests the graphs internally but they are not used on actual projects.
“I use ‘alpha’ as a testing ground. I have an idea but I have to spend hours researching and putting together. It’s going to fail a lot,” John says. “Once I think I have it pretty much solidified and it’s working in a specific environment, we move it to [the] ‘beta’ phase”.
Beta scripts get tested by a group of Dynamo savvy power users. As John describes them, these users are innovative and forward thinking. “They’re not afraid if the script breaks,” John says.
Dynamo graphs stay in the beta phase for anywhere from 30 days to 6 months, going through testing by the power users. Once John and Sarah feel confident that the graph works, they move it to “Gen Pop” or general population. These graphs are made available to the entire IMEG workforce through the firm’s Dynamo Player library. Though the process is rigorous and time-consuming, John reasons it’s the right approach.
“You throw a script out there [without testing], and the engineer or modeler that goes to use it will never use it again,” he says.
2. Build a user interface
While Revit 2018 added the ability to input values directly through the Dynamo Player, John prefers to build his own user interface using nodes from the Data-Shapes package. “We found out early because we didn’t have prompts. People had to go into the script and run them and they were like ‘Whoa, I don’t know what to do,’” John recalls. “And then we had another group who was like ‘Oh, I’m going to tinker with this now.’” Realizing this, John and Sarah put the project on hold and rebuilt their existing graphs using Data-Shapes.
The Data-Shapes package provides nodes to create a user interface for the Dynamo graph. When run, the user interacts with graph through the Data-Shapes controls, much like they would if running a macro or add-in. “Data-Shapes has been a game changer as far as usability of the graphs,” says John. “It gives [the user] a dialog they’re used to from other applications. It’s lowered the bar for who can use the graphs.”
3. Centralize access
IMEG stores all the “gen pop” graphs in a centralized folder on their network. All users have access to the library through the Dynamo Player. That was the easy part. Managing which packages are installed for each user was a more difficult task.
“Part of the reason it took so long is that there are so many different ways you can get [the packages] out there, ” Sarah says. “And there are pros and cons to each method. We took a long time to vet each solution since there are multiple parties that key into the process.”
In the end, IMEG settled on an internal IT solution that deploys the correct packages directly to users’ computers. John and Sarah determine which packages need updating and the system takes care of the rest. Users no longer need to manually update the packages themselves.
As for which packages to use, John says “I usually stay away from anything not in the top 10 for packages.” If any of those packages get updated, John says it’s a dead giveaway to him. “I use Dynamo every day so as soon as a graph doesn’t work, I open it up and look around. When I see red, I know I have a problem.”
John also tries not to use too much custom code in his graphs. “I try to stay away from it as much as possible. If I get hit by a bus, it’ll be difficult to backtrack if you’re not familiar with Python. The times I’ve used Python, I’ve kept a copy off the network and clued Sarah in on what I did.”
4. Collect data
Every graph in the IMEG library contains a group of nodes that reports data on who ran the node and when they ran it. This data is saved to a centralized database and provides John and Sarah with up-to-the-minute analytics on graph usage. This information has proved to be extremely valuable as they continue to improve existing graphs and roll-out new ones. “We can curtail our education to what’s not being used as well as what’s being used a lot,” John says.
Additionally, the data is used to encourage further use of the library. “We also have a user of the month. Every month we announce who used Dynamo the most. They get a coffee cup and gift certificate,” John says.
The usage data also provides insight into the company’s Revit use. “We have a script that gets used every time we update a model,” Sarah says. “Now I know exactly how many models get updated every month. We can start to apply that knowledge across other tasks, other training resources.”
The usage data gives John and Sarah the justification that the investment in time has been worth the effort. “It’s one thing to put a tool out there,” says John. “With the database, we’re able to track the extent it’s being used. We have scripts that are going over [usage] milestones that I never thought we’d hit.”
5. Don’t forget training
Before John and Sarah roll out new graphs for general use, they develop the documentation and training material to support the tool. The documentation resides on Compass, the company’s intranet, and is accessible by all the offices.
More importantly, the training material can be accessed directly from the graphs. The Data-Shapes interface provides links directly to the documentation. “If they run the graph and they don’t particularly know what they’re doing, they can click on that IMEG link and it will take them to the education page for that graph,” says John.
The IMEG library also contains a graph where users can provide input to the Dynamo team. Users select the graph they’re having issues with, enter their comment or problem. The input is logged in the database and routed to John and Sarah.
Likewise, the beta group provides input on improvements to the graphs or new ideas. The rest of the company is chiming in as well. “Because we introduced Dynamo to everyone, people are coming out of the woodwork with new ideas,” John says.
Next steps for IMEG
Sarah and John have ambitious goals for the next phase of the Dynamo project, with a slate of graphs in the alpha phase and more ideas coming in on a regular basis.
Many of the scripts in the current library are geared toward general tasks, such as creating print sets, adding revisions, exporting schedules. “The goal is to take away all the tedious, repetitive, error-prone tasks, the tasks that take us away from being actual consulting engineers, and do a better job at the human piece of it,” Sarah says.
With those productivity graphs well covered, John and Sarah are working on more discipline-specific graphs. One of the first MEP specific graphs generates plumbing material lists from the Revit model and formats the data in Excel. “This one was really exciting for us because it’s proof of concept for the Revit to Excel back to Revit round trip. It lets us take advantage of what each tool is good for,” says John.
One area where IMEG sees more opportunity for Dynamo is in the early stages of the project. The company is starting to use Revit more as a design tool, especially for MEP. As Sarah states, “We’re transitioning data from other sources, data we need for design or calculations, and keeping it in one place in the Revit model. We’re then going to automate as much as we can in the model, especially the early modeling.”
Sarah believes this type of design level automation will help IMEG be more consistent in their modeling. “As we start to get into more modeling tools, it’s going to give us more opportunities to do BIM checks and confirm that everything has been modeled in a standard way and is coordinated,” she says.
One challenge facing the team is the open-source nature of Dynamo. “Open source is good but some aspects aren’t so good. I’d prefer to pay for some of the packages we use just to know the developer is going to be around,” says John. That said, he’s optimistic about the future of the platform. “Some of the add-ins available don’t fit everyone. With Dynamo, we have the ability to customize exactly what we want to do and when we want to do it” he says.
As for Sarah, she’s excited to be developing something new in Revit. “I love the story of Dynamo,” she says. “It reminds me of the early days of Revit. Everyone wanted to help each other out and use this cool new tool. We’ve kind of stabilized in Revit. A lot of people are experts. We don’t need all the day-to-day help that we used to. Dynamo is a new and exciting thing that we’re trying to figure out together. It’s brought back a lot of the community aspects of Revit and BIM that I enjoy a lot.”