Sunday, April 21, 2013

Bloated Revit central files

NOTE: This is a re-post from the HOK BIM Solutions blog

A couple of weeks ago I was asked to take a look at a project that the team simply couldn’t open up. The file wasn’t giving any errors and the progress bar sat there at 99% and would not finish opening. To put things in context, this was an FF&E hospital project with about 12 floors and contained links to various other files that housed the building core & shell geometry.

Right off the bat I noticed the excessive file size (about 595MB). By closing the worksets that contained other linked Revit models (about 11 of them), the project finally opened. File size is typically one of the first things to look at when faced with projects that won’t open. In some cases the issue can be easily rectified through a purge of unused elements and a compaction during a sync with central, typically resulting in a reduction of 30% to 50%. Sometimes users fail to realize that if bloated files exist across the board in their project and they load these files as links, they can easily suffer serious performance issues as they run low (or out of) RAM. This is one of the most avoidable problems that BIM Coordinators should watch out for on their projects and can be easily prevented through regular file maintenance.

However in this instance, a purge and compaction only resulted in trimming about 90MB off the file (not bad, but not enough). So it was time for a much more in-depth analysis of the file contents.

My first suspicion was that the project might have contained imported CAD files. A quick search with Ideate Explorer did not reveal any so then I started looking at groups of elements with large quantities. A good troubleshooting strategy is to delete these large group of elements, save a new file (as a new Central) and see how much space is recovered. I took out all furniture families (about 16,000 instances) but the file barely lost 40MB. The families in question were very lightweight and contained mostly plan symbolic representations, which was a smart move for this project’s purpose.

Next I noticed there were almost 7,000 rooms, but did not suspect these would be the source of the problem. After all, they just contain some data, right? Well, it turns out rooms were to blame for this bloated file but I couldn’t figure out how to get this excess amount of bits and bytes released.

After filing a Support Request with Autodesk, I did some more testing based on their recommendations and saved a series of files after deleting rooms by floor (about 8) to try and identify if rooms on a certain floor were consuming more file space than others. Averages revealed that rooms on some floors were using a bit less (ex: 20KB/room) when compared to others (65KB - 83KB/room). However this analysis still led to nowhere and I did not receive further suggestions. Usually Autodesk is eager to take a look at the project file itself but this was not the case this time, even though the SR was filed as Urgent. We were running out of time, so it was time for some drastic measures.

After a purge and deletion of all rooms, the file went down to a very reasonable 65MB. That gave me a goal to work towards. Rooms were consuming about 300MB and if placed rooms were copied and pasted into a new project, they resulted in a 100MB file, which is about 17KB/room. Deleting 800 unplaced rooms from a room schedule did save 23MB, but somehow, about 200MB of space was being held hostage by the remaining 6,160 placed rooms.

Here are the steps taken to fix the file:

  1. Opened a detached copy of the original project and deleted all rooms. The file was saved as a new central, no purging (155MB);
  2. Opened a detached copy of the original project and deleted all model elements, links, families, sheets and views, leaving just placed rooms. The file was saved as a new central, no purging (108MB). Note that deleting model elements is easier to accomplish by going through the Family tree in the project browser. Since Revit does not let you delete the last type of a system family, you need to create a duplicate of the family and then delete the original one. This ensures that if any elements exist in the project with that type, that they are deleted. Sheets and views are easily deleted through a sheet schedule and view list respectively, both set to not itemize every instance. This allows you to pick the single displayed row and delete them all at once;
  3. Opened the central file created in step 1, created workset “Rooms” and set as Active;
  4. Linked the file created in step 2, Auto – Origin to Origin;
  5. Selected the link and bound it, turning it into a group (did not select levels and grids to be inserted). When prompted, removed the original link as no instances were now placed;
  6. Selected the resulting group and ungrouped it. All rooms were now placed exactly in their original location, with the exception that their workset was now “Rooms”.
  7. The new central file was saved (255MB) and those 200MB were finally released. By purging, this file should ultimately end up as a 170MB project, which is much more reasonable.

You might not be faced with this exact same problem on any of your projects, but I hope it outlines the systematic approach to troubleshooting and resolving issues with bloated files.



Steve said...

You did not mention warnings. I am curious about how many warnings were related to room boundary and conflicts. Such as wall overlaps, room separation lines, rooms in same boundary and so on. It seems possible to me that the data increase could be related to multiple warnings affecting rooms and the elements that define their boundaries. One room affected by two walls overlapping could create two warning records. With seven thousand rooms a small percentage of them could result in a significant number or dependent errors.

JB said...

Great post Dave.
Interesting workflow and troubleshooting.
Keep it up.


Dave Baldacchino said...

Hi Steve, in these projects there were actually no walls. All geometry was coming in through linked files and then rooms and furniture were placed in this host project, with the addition of room boundary lines as well.

I can tell you that there are only a handful of warnings about redundant rooms (100 or so). The resulting "fixed' file is in essence identical to the first one in terms of where everything is located, so the same warnings should exist between the two. I didn't make a comparison side by side because in the original file, I couldn't even open all links so there were obviously more room bounding warnings since these models were not loaded (the links are huge as well...we're trying to clean them up by inserting them into an empty file, binding and ungrouping, and using these new files as the links instead).

Alfredo Medina said...

Great post, Dave. Thank you for sharing. One question: do users usually take care of the lower and upper limits of rooms? If they don't do that carefully, the rooms will overlap, not in plan but in section, maybe causing a significant part of the problem. Do you think this could be the reason? If that is the case, that would be a good topic for the next in-house lunch seminar.

Dave Baldacchino said...

Thanks Alfredo. Volume computations are disabled and the rooms are placed at the default 8'-0" upper limit, so the only overlaps that are happening are just in plan. There are a total of 300 warnings and the team needs to resolve those.

However for some very bizarre reason, the file size went back up to where it was (and even higher!). After the merge process, rooms couldn't find their boundaries and to come to their senses, I had to change the room computation height for all levels to 0'-0" (I re-set it to 3'-0" just to get back to where we started). I think that when room bounding is determined through linked file geometry, that more data/space is consumed, resulting in these massive files. The project is performing quite well and opens quick (if no links are loaded) and rooms still know where they start and stop. I'll post back if I find out more.

KyleB said...

This post caught my attention in my RSS reader, so I decided to query our Revit brain trust on the matter.

Our code expert in this area was pretty certain that the culprit here is the 3D face geometry that we serialize into the RVT file to represent the Room Boundaries.

From your description of the geometric setup of this model, there are likely many, many 3D faces generated from your mishmash of linked geometry and room separation lines.

The one suggestion that our developer had to isolate the problem, is to turn off 3D room calculations and detach and save as a new central, and see if that makes a significant impact. If not, then your culprit is the 3D face geometry we maintain for the 2D room boundary you see in Plan Views.

Nonetheless, interested troubleshooting process, and glad you got things worked out.

Kyle Bernhardt
Product Line Manager
Building Design Suite

Dave Baldacchino said...

Kyle, my sincere thanks for your time in digging a bit deeper.

As I posted just a few minutes ago in a comment reply, I *thought* volme computations were turned off, but somehow they are not! The file crept back up to the same size (and higher) a couple of sync's with central later. So I turned off volume computations and recreated the central file, and we're back to the smaller file size of about 250MB...yeah!

After the merge of rooms into the file, rooms didn't recognize their boundaries anymore and I had to tweak the level properties to have them "wake up". I think the file size increase was exactly due to the 3D computation/faces you mentioned...about 200MB or so of data.

Brian Beck said...

Great post Dave. I'm going to save this in my bag-o-tricks. One of the more insightful set of comments from a group of people I have serious respect for.

Anonymous said...

wow, I want to send this post around to some staff...
(I picked this up off a Linked-In notice...)

But let me ask a slightly off-topic question since you seem like such an expert...

Is there anything available in Revit world for Landscape Architects? Thanks in advance.

Dave Baldacchino said...

You can make Revit work typically for Landscape Architecture. The main issue is content, which is solveable (ex: buying pre-made family libraries, or something like LandCadd and Siteworks plugins from Eaglepoint). Witha solid template, including a system of properly sub-categorized families and filters, floors with model patterns for showing different types of ground cover etc. (also schedulable), it works.

Mikey Stix said...

I just went through and deleted every room from the project and started over again. The person put in charge of this completely fubar'd the rooms. Anyhow, I have been systematically and cautiously placing rooms, naming and numbering them as to tally 0 warnings in this process to which I thought I was successful. I got out of the basement levels and up to level 11 when I saved to central for maybe the 6th time that day...this was day 3 of room placement. When I saved to central I got a warning that I had 65 warnings about rooms upper and lower limits crossing each other. I thought maybe the warning dialog slipped past me while I placed rooms so I didn't think anything of it and fixed the overlap warnings. Back to room placement, I get up to level 24 an hour later and I save to central and up pops 50 room warnings down in the basement one else is working in the model. I attempt to fix them to no avail, some of the rooms are not even close to each other so I have no luck with adjusting the levels to relieve the warning. For giggles I saved to central again and my room warnings doubled. I am very frustrated at this point cause I am only about halfway through this room placement task. I do the old trusty "close Revit and re-open" look at the warnings and the warnings halved. I am really at a loss here. Revit, one of these days you will put me in a home...

Dave Baldacchino said...

Yikes Mikey, that doesn't sound right. I never had that issue before. Might want to consider sending some journal files to Autodesk Support.

Post a Comment