Shrinking down a file

[s.messing]

Executive Summary:
What takes up space in a Revit file?

Details:
I have a detached from central file that is being used for a few specific tasks and needs information from only certain levels of the 10 story building. So, after the file has been successfully detached, I want to make it as fast/ efficient as possible. I removed unnecessary CAD and Revit links, Purged all unused families, deleted a whole bunch of drafting views, and deleted a ton of information (building elements) from the floors that I don't need. These are the "clear" big spenders in terms of file size. After all of this (which took a good chunk of time), my file shrunk by almost 1/3. That's great, but I am wondering what other big ticket items I can purge/ remove/ unload/ incinerate? I know views are not space takers, for example, so I have not bothered to delete extraneous ones. I know that design options and topography are big.

Conclusion:
I think I know a lot about how to make a file run smooth, but I am interested in hearing what other people have done in this situation. How are people making huge, old, unruly files serve specific purposes down the road [in parenthesis: I am kinda ticked that I can't get this 150 Meg file under 100 Megs considering all of the work I have done to it.]

Any ideas and help would be greatly appreciated.
Thanks,
Stephen

[aaronrumple]

From what I've found - it isn't the size, but other issues. Lots of constraints and relationships take time. Groups take time. AutoCAD imports take time.

[twiceroadsfool]

After cleaning all of those items out, did you do a Compact Central File when saving it? I try to do that IN the central file once a week, it tends to make the file considerable smaller. My files have been shrinking by about half.

Also, going in to Tools > Review Warnings and cleaning out the warnings before saving and compacting has had a huge impact. I purged/saved/compacted a central file, then made NO OTHER CHANGES other than clearing out the warning dialogues, and saved/compacted again.

The differences in 3 models were as follows:

"Model 1": 253MB 104MB

"Model 2": 269MB 113MB

"Model 3" 214MB 121MB

Im not sure if it makes a documentable difference (maybe someone from Factory can answer?), but those are the hard numbers we experienced with NO other changes.

[s.messing]

I'll tell you where I am going with all of this (besides the reason I have already given). I am interested (for myself and everyone else) a list of priorities in terms of cleaning up a model (ideally at all stages of the game). In my office and across the globe, people are taking shortcuts that might save a few seconds but will eventually cost a few hours. Furthermore, many of us do not know the best practices about many facets of designing and modeling using Revit. Where we end up (some of us in worse shape than others) is with large, unruly files with inaccurate information. Many projects have hundreds and even thousands of warnings under the review warnings dialog. Lots of us leave dwgs floating around and design options long after they have been removed from the actual design. I can't tell you how many times I have gone investigating a problem and fixed it by deleting some buried room separation lines. So, what's better to fix first (hypothetically): Room separation lines overlapping or room tags outside of rooms?

So, my goal is to help all of us with these common problems. I am looking to create a list, organized by priority, with the most heavy, painful, file slowing errors, warning, and general malaise at the top. I will appreciate the feedback of everyone from factory to faculty. I will compile, tally, organize and then post the master list for everyone to see after it is deemed complete.

The purpose here is to create a simple guideline to help all levels of users, managers, and offices. This is especially beneficial because, if the list is organized accurately, then at any stage of the process we can improve performance.

CAVEAT: Clearly this is not a 100% perfect science. I am not trying to squeeze perfection out of this process. I know there can be a debate about whether it is more important to clean up overlapping room separation lines with walls or clean up insert conflicts with wall join. This list is not about exact answers. It is about the big picture...

So: here's an example to get you all started:

In my estimation, in order from most detrimental:
1. Purge Unused
2. Compute Room Volume On
3. Unnecessary design options
4. Extraneous DWG links
5. Unused Groups
6. Any combo of: Overlapping room separation lines/ walls

What do you think??

Cheers,
Stephen

[dbaldacchino]

I found that compacting the central through the option when STC'ing, and compacting locals (do save as and select the compact option....wouldn't it be nice to be able to compact BOTH central and local from the same friggin dialog?!) significantly reduces file size and keeps them running fast. So do this on a regular basis.

As for families, actually these don't get as small as they should just by compacting them. I recently filed a SR about a family that was about 450kb with absolutely nothing in it.....no geometry, no materials, nothing. Their response was that families save histories with them. These histories don't go away except after lots of saves. To get the smallest possible family size, load it in a project and save it out from the Project Browser. Try it out on some of your families....you'll be surprised!

[twiceroadsfool]

In my estimation, in order from most detrimental:
1. Purge Unused
2. Compute Room Volume On
3. Unnecessary design options
4. Extraneous DWG links
5. Unused Groups
6. Any combo of: Overlapping room separation lines/ walls

What do you think??

Cheers,
Stephen

I try to do the combo of purge unused / clean up worksets / Compact File once a week.

Also important (IMHO), im not sure how many users out there employ the "new local file every morning" technique. We do, and ive found it solves a lot of problems. I do our file maintenance after hours, that way i can go right in the central file, check the worksets for misplaced members, purge, save, etc... Ive found after doing that, peoples local copies start acting verrrrrry sloooooow, and often experience failures with the STC. We also get failures with STC if people work for way too long (in our 200 MB 7 person project) and try to STC. For that reason, we implement office wide that EVERYONE gets new locals EVERY MORNING when working on a project. That way, there isnt a danger of youre computer needing to Reload Latest on 8 hours of work someone did while you were on another project.

Weve also found the warnings create failures with STC. So far, the rough estimate is when we cross 300 Warnings, we seem to experience random errors like "cant keep elements joined" when STC'ing, and above 500 (lol) we start getting rediculous times for STC... Upwards of 5 or 6 minutes for a 200 MB file.

Ive HEARD number of views and number of DWG's is a factor, but we import a TON of DWG's (current view only) for coordination with the leasing agent on our project, and we arent having many problems. Weve got almost 200 floor plans in one model, lol.

The overlapping room separations thing is a bear though... Area boundary lines too. And whats worse, ill let Revit pick the Area Boundary lines when i click walls, and theyll STILL overlap.... :(

[davidcobi]

As for families, actually these don't get as small as they should just by compacting them. I recently filed a SR about a family that was about 450kb with absolutely nothing in it.....no geometry, no materials, nothing. Their response was thet families save histories with them. These histories don't go away except after lost of saves. To get the smalles possible family size, load it in a project and save it out from the Project Browser. Try it out on some of your families....you'll be surprised!

I'm assuming Revit removes family history when the family is loaded into a project file not when it is saved out? In which case Revit is already optimizing a family file as it's loading it in.

[dbaldacchino]

That is probably the case Dave. I guess one could verify that by loading a family into a project, opening it up for editing in the Family Editor and saving it from there instead. If the resulting size is smaller than the family rfa that was loaded into the project, then it would mean that Histories are being removed when the family is loaded in the project environment, and not when the save occurs through the Project Browser.

[s.messing]

Does anybody have any idea if certain warnings are worse than others? For example, some projects in the office have tons of warnings in the review warnings dialog box (up over 1000 of them on more than one project). So, I can't possibly ask the team to fix them all, but I could help them fix some. If I knew that I could ignore Lines slightly off axis and focus more on Room separation lines overlap, I might be able to achieve some tangible results. Similarly, some warnings are more prone to cause strange errors and other problems. For example, room separation lines overlapping walls can lead to incorrect room designations in doors, incorrect room volumes, and many other problems. So this might stand out a warning that should be fixed first...

Thoughts?

[dbaldacchino]

I would definately fix issues that can impact area calculations. The "line is slightly off axis" might not be a big deal but if there aren't a lot ot them, I'd check anyway since that warning typically appears for lines that arr off by fractions of a degree.

EDIT: And oh, yes, I would ask the team to fix those issues! I have begun to stress the importance of reviewing warnings on a regular basis. We cannot have "janitors" go clean up messes and the teams need to become more responsible for their actions.

[twiceroadsfool]

Does anybody have any idea if certain warnings are worse than others? For example, some projects in the office have tons of warnings in the review warnings dialog box (up over 1000 of them on more than one project). So, I can't possibly ask the team to fix them all, but I could help them fix some. If I knew that I could ignore Lines slightly off axis and focus more on Room separation lines overlap, I might be able to achieve some tangible results. Similarly, some warnings are more prone to cause strange errors and other problems. For example, room separation lines overlapping walls can lead to incorrect room designations in doors, incorrect room volumes, and many other problems. So this might stand out a warning that should be fixed first...

Thoughts?

I disagree that you cannot expect to fix them all. I had a file with 1600, and as you start to go through them, you will find that a lot of them vanish with a broad stroke of the brush:

Identical instances in the same place. Aside from workset organziation, it doesnt really matter which one you delete, now does it? Duplicate type mark and duplicate mark value ones go rather quickly... Wall does not intersect its target (detach all)...

I was very sad the day i had to start the 1600 warnings we had, but it only took about 16 hours of work to get rid of them. The model performance difference was staggering..

[MTristram]

I disagree that you cannot expect to fix them all. I had a file with 1600, and as you start to go through them, you will find that a lot of them vanish with a broad stroke of the brush:

I was very sad the day i had to start the 1600 warnings we had, but it only took about 16 hours of work to get rid of them. The model performance difference was staggering..


1600 warnings is nothing, we have a team here complaining about model crashing when STC and have just found out they have 2200+ warnings along with 90+ detail groups mainly consisting of part autocad details.........

[s.messing]

The model performance difference was staggering..

Question:
1. Can you document or measure this difference with an example? How fast did it get? How much smaller did the file become? Etc.



Identical instances in the same place. Aside from workset organziation, it doesnt really matter which one you delete, now does it? Duplicate type mark and duplicate mark value ones go rather quickly... Wall does not intersect its target (detach all)...

Questions:
1. Does detach all create other problems? Is it dangerous as far as best practices go?
2. Are there other handy tricks? (for example, what about line slightly off axis or room separation lines overlap)?
3. Wouldn't it matter which instance you delete if one is embedded with lots of information and the other is not? Is there a trick to sort with a schedule or something to be able to choose the ones that are information laden and delete the ones that are mostly empty? Can you even schedule warnings?

Thanks for any light you can shine on this subject. I have been wrestling with it on projects and throughout the office.

Cheers,
Stephen

[swalton240189]

I'm assuming Revit removes family history when the family is loaded into a project file not when it is saved out? In which case Revit is already optimizing a family file as it's loading it in.

I just tested loading in a family into anew project from our template.
The project started as 14,876KB.
I loaded a 936 KB family in.
and the file became 15,844 KB.
That's a change of 972KB.
I then did a save as, compacting the project file and it only went down to 15,840 KB
When I save that family out of the project file it is only 436 KB

This seems to indicate the Revit family is optimized when saving it out but not when loading it in or compacting the project file.

Opening the family directly and compacting made it 932KB
Opening the family compacting and regenerating the thumbnail made it 944KB

I then tried loading the 436KB saved out family into a fresh project file 14,876KB It made it 15,696 KB. A change of 820KB.

I'm starting to wonder how much time I should spend making my family file size smaller.

[dbaldacchino]

As a rule (suggested by Autodesk Support after a support request filed a long time ago), I now always load a finished family to a project and then save it out from there. That's the smallest family size you get because it sheds all the history about that family. Some background about the support request....I had a window family that I edited for a long time and it was about 1.5MB. I was like...huh?! As a test, I deleted EVERYTHING out of it, purged it and all, saved and compacted it and the file was still over 1MB. That's when support told me to load into a project and save it out form there. The window family went down to about 500kb.

[davidcobi]

I took the family upgrade journal file and modified it to optimize the size of family files.
But I get an error. Can anyone who's any good with journal files guide me here? Thanks.

' 0:< At line number 44 of source journal
'DBG_WARN: Could not figure out which family is selected: line 2336 of .\MFC\MFCdocUI.cpp.

This was written for 2009.