Saturday, June 27, 2009

Compound Walls - How Much?

While attending a Revit user group meeting a month or two ago someone mentioned that they prefer to use generic walls to keep their model size (file size) down. It seems reasonable that a compound wall might carry a bit heavier burden on a model but how much more of a burden? The poor scientist that I am I tried the following.
I saved an "empty" template file with no walls placed which resulted in a file of 2076 kb (used Default.rte, the stock Revit template). I then created 19 walls, 4 exterior and 15 interior walls using Generic 12" and 6" respectively. When I saved this file it was 2216 kb. Then I created another but used compound walls (Exterior - Brick and CMU on Mtl. Stud and Interior 5-1/2" Partition(1 hr)) instead with a resulting file size of 2452 kb for an increase or difference of 236 kb. I used the exterior wall type because it is more than just a wall with extra layers, it has embedded sweeps and reveals which should account for some of the difference as well.

A small number of walls. I thought I'd use more this time. I created another pile of walls for a total of 152. This is the result.

The generic walls file came in at 3184 kb and the compound version came in at 4092 for a difference of 908 kb. Here's a spreadsheet breakdown for you "column and row" types.

It seems to me that this means that modelling walls in bulk results in less cost (in kilobytes) per wall. The more walls the more economical their impact is. Not that more walls doesn't mean more...just not a literal 1:1 file size relationship. It also means that compound walls do have a "heavier" impact on the project file size too.

Since I increased the number of walls by eight (8) times I was curious to see if the kilobyte increase was literally eight (8) times as well. The How Close? column in the spreadsheet shows that the generic walls were nearly so but the compound walls were a bit more economical when the quantity increased, just a little over five (5) times as many kilobytes.

To make it more interesting we could edit the profile of walls, attach walls to roofs, embed curtain walls, disallow joins, add views to sheets using different Detail Level settings, place various hosted elements on/in walls, use the Opening Tools, compare curved versus straight impact...and on and on.

Do I have a point? Well...file size isn't really the only measure of a project's performance nor is it even really reliable to use to predict project performance. I've seen rather large projects that perform quite well apart from waiting for it to open initially. Conversely I've seen "small" projects that perform poorly. My interpretation of my results is that I shouldn't really need to worry about using generic walls only, at least not using just file size as a measure. Much more likely that how the walls interact with other elements in the project will affect performance more than just file size.


Anonymous said...

I well always question generic over specified types (especially walls). Although there may be a small benefit to performance the wall will never look correct in elevation in later stages of the documentation.

Do it right once is what I tell my Reviteers.

Unknown said...

Interesting discussion, Steve.

A few thoughts:

1. Too often these days i see people migrating to Revit and obsessing over file size. Whilst in the past it was an issue, Storage appears to be the cheapest of the infrastructure woes we face, with the prices still dropping. When Revit models climb neary of 200 MB, that some people still worry about deleting backup files and deleting extra views here and there boggles my mind.

2. I wonder if you can even make the direct size correlation that youve tested. Here is why: Information is in those Compound wall types, that is not in those Generics. Now there is additional overhead that has to be added to the file with the generics, to demonstrate the same "detail." How many sections are the generic walls in? How many lines/detail componenets/filled regions need to be included to capture the same information as the wall makeup? Are they detail grouped for multiple wall sections, so you have to maintain the detail group? Or (worse) are they not?

Dave B (i think) did another size comparison on a detail component with 4 lines, versus 4 lines in the project file. Makes me wonder how much bloat that model will get when the wall definition needs to be demonstrated in the drawings...

3. It also begets an organizational nightmare. I believe in using Generics, and i use them when things are still undefined (SD). Then as they get more defined, they change to Specfic elements. This is great for QC as a schedule of elements can tell you how many undefined you still have. But USING generics brings up an interest issue: Is every 7-1/4" wall the same? GB one layer each side, or two layers one side? Do you use the same generic wall for each? If so, what are the implications of managing it? What if someone goes to edit a wall type... How many "different" wall is each generic encompassing?

A great conversation, one im still having in house as well... :)

archshrk said...

We're still trying to optimize our Revit workflow but have implemented custom generic walls to speed up the Schematic Phase as Malleristic-Revitation described but our generic walls include color-coded exterior faces to help visual the design.

What I'm really curious about is how do stacked walls compare to one wall on top of another wall?

Anonymous said...

I'm glad I'm not the only one thinking about these questions.
A year ago I was asking similar questions, but in regards to Columns and Dimensions.

With Columns, I tested the differences between copying Groups between Levels, and spanning Columns across levels. I did the test on a 10 x 10 array across 10 levels. What I found was that the Grouped method produced a filesize which was 26% larger.

With Dimensions, I tested the differences between using single instances (i.e. point A to point B), or using a long string (i.e. point A, to point B, then C, then D, etc.). In this test there was only a 12% filesize increase with using single instances.

What I concluded was that the small increase of filesize was fairly minimal. But as expected, there was a much more noticable difference in the graphical performance of the Revit model. The increase of single objects had a more significant impact when working in the project, than what the filesize increase did.