Getting your Revit Model back to Warp Speed, Scotty!

We ran into some issues with slow loads and regens with some of our shared Revit models recently, and decided to come up with a checklist to help you look for items that can cause a model to have these issues.Your circumstances may vary, but these should help you eliminate some performance issues.

Location of the Files

How many have servers with mapped drive letters to specific folder locations? And the locations could actually be on servers in other office locations?

When a project is loaded into Revit, the program resolves the path locations to the linked files. But if the drive letter mapping doesn't match from office to office, the program can spend an inordinate amount of time trying to locate files. This mainly occurs when drive letters are not mapped to the same server, or if the server is in a different location.

To resolve this, the first step is the use the UNC file name for the server. This can vary widely across firms, but if a server's actual name is SERVERO1, then you want to start your path like this: \\SERVER01\folder name, etc... This helps out tremendously when you have multiple office locations with a variety of servers in the firm where Revit files are stored.

This applies not only to RVT files, but also any lined DWG or image files you may include in your model.

One other option is to set the pathing to Relative, instead of absolute. If you have files stored on different locations (such as office locations, or practice based servers) and you're not planning on moving the files, then an absolute path option using a UNC name works really well. If you may need to move the project files in the future, and keep them all in the same root folder, then use relative. That way, Revit doesn't spend a lot of time searching for the linked files - instead, it will start in the same root location as the file you are opening.

Workset Control

One item that helps speed up opening a file relates to worksets in a central file. When the program opens a file that has worksets enabled, you get a dialog that asks what workset you want to open:

If you don't need to see or use items in a specific workset, select it - under the Opened column, you can change this from Yes to No by selecting the close command. Since one thing we like to do is place linked files, such as Revit or CAD files, into specific worksets that you can open and close as needed.

MEP Issues

This one popped up when we migrated a project from 2013 to 2015. Since it wasn't one we really targeted to get the systems part working correctly, we had a little spate of errors (ok, a LOT of errors) regarding pipe and duct calculations. Since we're running the R2 version with Update Release 3, I found a neat new little feature.

Under the project browser, and families, select a duct system family. Edit the Type Properties, and look for the mechanical settings:

If calculations are set to All or Flow Only, the program is constantly reviewing the duct and pipe layouts and adding sizing values. The old way was just to set this to none, but Autodesk added a Performance feature that helps even more with files have large networks. The details are a bit long, so here's a link to the actual help file.

Another item you can control lives on the Analyze tab. The Check Systems tools for duct, pipe, circuits and disconnects can really help you find errors. These are toggles that I turn on when I want to check, and turn them off when I'm finished. Leaving these off when you leave the file is another good idea.

The last item to check includes the Warning tool, located on the Manage Tab, Inquiry panel. This lists all errors in a file - if there's a lot, the program will be trying to track and resolve them when opening the file. Finding and fixing thse errors makes the file run much smoother, and keeps your model happy - so take the time to review these on a regular basis.

These are just a few tips - I'll add more as we discover them, but consider this your Christmas present. Enjoy the holidays!

David B.

AU 2014 is in the Can…Miscellaneous Thoughts…

Had a great time catching up with everyone, and meeting new people this year. Autodesk University (@autodesku) continues to grow and add value to the attendees, and it’s the best run event I attend every year. This was actually a light year from me from a teaching standpoint, but the feature class on Managing BIM Projects without Going CrAzY was a blast to teach this time. Even with a couple of minor technical hiccups on my part, the online portion seemed to go off without a hitch (with all 6 users watching…grin). It gives me good vibes about the Virtual events for the future, and I think these can easily be expanded…provided the conference location can handle the bandwidth. That was the only real hiccup this year – with so many online applications, and users pinging the AU app like mad, we did bring the whole network down at least once.

A couple of observations – the crowd varies from year to year, and while last year’s event seemed to have more entry level users, there was definitely a more forward thinking and sophisticated user mindset at this event. And Autodesk leaders, including CEO Carl Bass, and CTO Jeff Kowalski, played to the future visions of the users pretty well in the opening keynote.

One item that made me think a little harder was a comment made by Jeff, about how, at some point, our creations need to learn how to work more naturally (is that right?) towards each other, instead of being “dead” creations that symbolize a static point in time. He made his point by talking about how he wants his clothes washer to communicate with the dryer, and know when the wash is finished, so the dryer can pick up the task from there.

It’s a great idea to have this type of vision moving forward, but here’s where the “but” comes in. We, the users, can’t help Autodesk move this vision forward if they can’t get their current products to communicate, much less coordinate, with each other now. There’s a million examples, but the discussion came up in an Expert Elite luncheon on Thursday. One of the users asked Jeff when he could expect to see the same passion for the civil products that he was demonstrating in his explanation about 3D printing, and how computers can handle the tasks of designing structures and parts best.

At that point, I attempted to rephrase the question, by stating that you can’t get to appliances talking to each other if you can’t accomplish the goal of having a Revit pipe recognize and connect to a Civil 3D pipe on their own now. That’s where the technology is now, but it’s doesn’t work in the Autodesk product line.

Part of the problem is the wide variety of solutions Autodesk offers, and the fact that the different divisions within the company now, such as buildings, infrastructure, manufacturing, etc. are still very “silo” based. Here’s a simple example: Right now, in AutoCAD MEP, if you want to associate information from a light fixture to be associated with a space object, you simply add an anchor object. This creates the relationship between the parts, and allows you to link shared information between the parts.

In Revit, mechanical equipment can only recognize limited data that’s embedded into the programming – for example, the circuit name and number is automatically associated with the equipment, but that’s it. You can’t easily tie other electrical data – such as the section number that associated with an electrical circuit for a motor control center – back to the equipment. Other examples include horsepower, circuit ampacity or wiring in an associated conduit that’s connected to the equipment.

It’s not that Autodesk can’t develop, or even have that kind of programming available. It’s the fact that it’s not there is where the problem exists. And with the new Dynamo programming language available, we’re still a long ways off from having the tools we need to get to this level of optimization – whether it’s Autodesk, third party developers, or our own in-house personnel developing the code.

Almost every company I’ve worked for – including ours – still struggles with overcoming these silos, and being able to address the needs of their partners in design without having to take a lot of extra steps. But the fact that Autodesk recognizes the fact that these interconnecting relationships are key to their future is important. It’s just a matter of the company’s leadership to develop and push these goals back to the development teams.

And it’s not for want – Jeff’s key comment back to the crowd was that he was simply a visionist, who was on our side and pushed the same ideas back. At some point, you have to get the roadblocks out of the way, and get the communication and goals directly tied to each other – and develop the features in the products we need day in and day out, at the based product line level.

A360, BIM 360, Field 360, Simulation 360, and other cloud based products represent the cloud-based tools to help make the more complex communications possible. But Autodesk should not get too involved in the development of these present and future applications at the expense of their core product line.

In other words – don’t look past the sliding glass door so far that you break your nose trying to get out of it.

Back to AU – it was one of the best events I’ve been to with Autodesk in a while, and the opportunity to meet Carl and Jeff was definitely a high point (sorry, guys, if I drooled on your foot). But it was just as important to me to meet the people that came into my classes, and participated in the topics that I’m passionate about. It was great share that passion, and hopefully I could help them overcome some of their fears, discover relevance, and change their methods to get the message out (thank you, Mike Lee for those words and ideas – be the change!).

Next year – super excited about being back at the Venetian and Sands Convention Center, my favorite venue. The crowds will be large, and the people motivated – let’s see how far we can get in the next 50 weeks…

Merry Christmas!

David B.