Revit MEP: Strategies for Memory Management
A Whale of a Job
So your firm has been fortunate enough to land that whale of a job they were going after. Great! Now you are tasked with making sure you have the resources to handle that job without wasting all your time standing around the coffee pot waiting for your files to open. There are several potential bottlenecks, both software and hardware related, that need consideration. With the right strategies, you can stretch your resources farther, without breaking the bank with IT upgrades.
The Files Get How Big?
Autodesk Revit’s approach of an all encompassing file can create some behemoth sized files.
“How big?” you might ask. Very big. The file size you see on the disk is a compressed file format. When that file is opened in active memory, the RAM used is about 20 times the file size. You can check that using Windows Task Manager. From the first submission (typically Design Development or DDs) to 100 percent Construction Documents (CDs) expect a growth factor of about three times the DD file size.
Let’s put some numbers on this. My office is currently working on a large university student union project—about 300,000 Sqft. The architectural and structural files that are each linked into the project represent the MEP model’s memory overhead. Together these two files measure about 200 MB. Well, 200 MB X 20 = 4 GB of RAM in use. Then there are the MEP models that are currently about 160 MB X 20 = 3.2 GB. We are currently at our first submission, and are totaling 7.2 GB of RAM being utilized. By CDs it will likely be about 7.2 x 3 = 21.6 GB. That is a lot of memory to have open at one time. Does this mean you can’t open a Revit file if it requires more RAM than is installed in your computer? Not at all. It will do its best to open the file. First it will fill up your available RAM, and then start caching to your hard drive. That is when you watch the “busy” wheel in Windows start grinding away at your profits. So what strategies can we employ that will enable us to manage large files without spending most of our time standing around the coffee pot waiting for the file to open?
Strip the Models (Architectural & Structural)
When the architect submits a model for use as a background, it is their working model. It has lots of sections, elevations, drafting views, 3D views, and schedules that are not needed as a background. So open the model and delete as much as possible. Delete every 3D view, section (unless you have a view linked directly to that section view), schedule, drafting view, and legend view. Make these models as stripped down as possible. (By the way, if any programmers out there would like to make an add-on to expedite this, I would be immensely grateful). The same applies to structural. In fact, you can delete every view, leaving only one view in the project and all the geometry remains. Now that all this has been deleted, purge the files. Purge is found under the Manage tab. It removes any family and family types not currently in use. Typically after this process is performed the finished file size is almost half the size of the original.
Worksets
Worksets not only enable multiple people to work in one file at the same time, they also make nice neat containers for objects—containers in which you may want to include different views. By unloading those containers from the project, it frees up the memory those objects would have held. So if you don’t need to see the lights to work on the duct plan, and the workset can be unloaded, then the duct plan will run faster because it has more available memory. Not only can objects be placed on worksets, but linked files can also be put on worksets. This leads into the next strategy, divide and conquer.
Divide and Conquer
The ‘when to divide’ and ‘how to divide’ topic has a million shades of gray. The process does have some overhead time required to set up. There seems to be three schools of thought on how to divide a project. The first is across the match lines; the second, by floor; the third is by discipline. For architecture it makes sense to be able to divide by the match lines, but not for MEP.
As of Revit MEP 2012, system information cannot be passed through a linked file. Yes, you can tag through a linked file, but that is not the same as passing system information along. If the electrical panel that serves an outlet is in a different file, then it can’t be added as a load to the panel. Air Handling Units in one file can’t add CFMs from terminal units in other files. This approach just does not work for MEP. The second approach of “by floor” has the same limitations. If the systems need to be able to connect vertically though the building, they won’t be able to. This leaves only one viable option left, dividing the model by discipline.
On large projects, dividing the models is a must to gain efficiency, but on smaller projects, where is the cut-off for a return on the time investment? Buildings 30,000-50,000 Sqft and smaller are generally manageable as single project files. For larger projects, it makes sense to create separate Revit MEP models. We prefer to divide them per trade (Electrical, Plumbing, and HVAC), then interlink each into the others by placing them on separate worksets unique to each linked file. Finally, set up the central file to inquire which worksets to load upon opening. If the workset for electrical is not selected upon opening the HVAC model, then none of the electrical objects will be loaded into active memory. This can free up huge chunks of memory. Dividing worksets into logical chunks helps with linked files even more. Let’s say the electrical model is linked into the HVAC model. To coordinate the ceilings, the workset for lights can be the only workset loaded into the HVAC model. To manage the worksets within linked files, use the Manage Links tool shown in the figure below.
Family Files
All too often I have seen flat plumbing fixtures and objects created from AutoCAD® loaded and used as Revit families. Sure, it works in a pinch, but from a memory perspective, it can quickly become very wasteful. Yes, AutoCAD line work can be loaded into Revit families, with visibility parameters used to manipulate the different types. For example, one instance of a Revit Parametric family can be placed dozens of times with dozens of different types and it will use very little memory. That same 2D symbology from AutoCAD loaded into the Revit family will need several visibility check boxes, and many redundant line work objects that will bloat the file size for each type. Accordingly, when Revit creates each instance of the family file, it will use the same amount of memory for each instance of the 2D family. So don’t build them like that. It’s just not efficient.
Hardware
Okay, if the above mentioned strategies aren’t enough, perhaps it’s time to talk to IT about some upgrades. Where will you get the most bang for your buck? On a per-workstation basis, RAM. At least 8 GB to start with. If that isn’t quite cutting it, look into getting some solid-state hard drives. Remember after your RAM gets full, it caches to the hard drive. Today’s solid-state drives have data transfer rates of 3 GB per second and faster. If all of that doesn’t work out, it might be time to consider looking for new workstations. All the aforementioned hardware recommendations still stand. Revit is now multithreading for opening and synchronizing process, along with some others, so the more cores on the processor the better. This makes for huge time savings. Finally, if IT doesn’t already have a gigabit network throughout the office, make plans to get one.
Looking Forward
The one, all-encompassing Revit file is not the reality of today’s models. For one, there are not many projects that have Architecture, MEP, and Structural all in the same office. Secondly, there are not many PCs that have the horsepower to handle the large projects. Revit Server and cloud computing may offer solutions to some of these hurdles. So there is the potential that one day none of this memory management will be critical as it is today. Until that day comes, I hope this article gives you the tools you need to handle jobs of any size or shape.
David Raynor is the Mechanical Designer/BIM Specialist for Stanford White Inc., a mechanical, electrical, plumbing and fire protection consulting engineering firm in Raleigh, North Carolina, USA. He has worked with AutoCAD since 1997, AutoCAD MEP since 2001, Revit MEP since 2008, and Revit MEP beta tester since 2010. He is responsible for training and implementation of Revit MEP for all disciplines. He has been an AUGI member since 2004 and an active member of the local Revit user group, NCRUG.
