Thursday, June 5, 2008

The "I" in WALLS

BIM is supposed to put a lot of emphasis on the "I" - Information. Unfortunately, walls in Revit miss out on the "I" when it comes to spanning, support locations, scheduling/filtering Wall Function, displaying/scheduling attachment information (top of wall), displaying fire rating information graphically and tagging heights.

Spanning

Walls are made up of various components and their span characteristics vary. For example a stud wall built with a 24" on center spacing spans less than a similar wall built with 12" on center spacing. Currently, we can add a "Span" parameter to the wall category in a project or template. However, this on its own is not enough, as we'll see below.

Supports

Span and support locations are directly related to each other. Just because a wall is 30 feet high and it can span 16 feet, doesn't mean that it will fail, as long as it has intermediate supports that break spans at or less than the allowable span. Currently, we do not have the ability to model these conditions (unless we model each span as a separate wall, which is unproductive and not a realistic representation of how things are built), which occur a lot in our buildings such as high corridors, atria, etc. This applies to both walls and curtain walls. I envision this parameter being input in a graphical way in "sketch mode", where by default, the top and bottom sides of the sketch are "pinned" and the user would then sketch a "support path" with lines (pinned would be more typical) to break the span as required. In case a wall is spanning horizontally, the user could change the sides to define support locations and make the top and bottom as "free". When cut in section or plan, the wall would then display a user-defined "symbol" or graphical representation of a clip/support. A filter to highlight problem walls would also be required to check for span issues, with similar functionality to schedule and filter for span infringments.

Wall Function

Currently, we cannot filter or schedule Wall Function, which renders this parameter next to useless. We need this ability very badly. There have been many instances where I wanted to export a 3D model of Exterior walls and components only, and it is very frustrating to know that the model KNOWS which walls are classified as Exterior and which ones are classified as Interior, yet I have to go through each wall again manually one by one, and assign them to a unique workset so I can gain control over their visibility. EDIT: In Revit 2010, this is now scheduleable. Thanks factory!

Attachment

When you attach the top of a wall to a roof, ref. plane or other element that it can attach to, the parameter "Top is Attached" is checked (read only). Similarly when the base is attached, the parameter "Base is Attached" is checked (read only). Once more, these parameters are not scheduleable or available for filtering. When documenting how walls are to be built, firms have come up with various ways to communicate intent, so I'm pretty sure there is no consensus over how it's done! So I can only relate to our rationale. We like to document how tops of walls are to be built on our code review sheets. These already outline fire rated walls (more on this below), which obviously go to deck. We are then left with walls that go to deck for acoustic reasons and others that only go to 8" above the ceiling. So we chose to tackle the latter with a note that says something on the line of "Undesignated walls go to 8" above the highest ceiling on either side of the wall" and then we designate a "fire tape" for "Unrated walls to deck". In some rare cases, we reverse this reasoning if there are a lot more walls to deck for the sake of keeping the drawings devoid of excess clutter. Currently, Revit does not allow for a BIM way to document this and we desperately need it so we can model every wall how we want it to be built, with the graphical representation becoming a direct extraction of what we model. Currently it is very hard to justify the extra effort since we would have to supplement this information via "2D drafting" techniques, regardless of how we model the walls.

Fire Rating

Walls do have a parameter for fire rating, but once again they fall short of letting us communicate this on paper documents correctly. If we used color prints, then this would be less of a problem, however we're not there yet. Users have used filters and special cut patterns to communicate this information in a BIM way. However, this mostly works on small buildings. If you have an overall plan on a code review sheet with a scale of 1/16" or smaller, then it becomes hard to see what the rating information is if you use the cut pattern technique (especially on 4" walls). Obviously, the "fire tape" method is a pure drafting technique. I'm not an advocate of trying to force drafting vernacular on BIM, but we probably all agree about the need for a clean, graphic way to communicate this information. Unless we're offered a good alternative, we're stuck with doing this in an un-BIM-like fashion, which doesn't do us any good for progressing the BIM cause. We will be experimenting with a number of techniques such as tagging fire rated walls and halftoning all those that are not rated. This still leaves the issue of non-rated walls to deck unresolved.

Heights

Wall heights are difficult in Revit, especially when wall tops are attached to multiple roofs at varying heights. It's not an easy problem, but needs resolved nonetheless. Revit currently reports the Unconnected Height in the Properties Dialog, which in the real world of construction has zero relevance! It cannot schedule this parameter and the closest one can get to finding the Height of a wall, is to schedule the Area and Lenth and add a calculated parameter that divides Area by Length to find an average Height. Unfortunately, when wall tops and bases are attached, the Unconnected Height becomes a worthless parameter, as the reported information is of no use. At the moment we can be disciplined and model each wall separately if the height varies, and then give an explicit height (unattached top). The problem is that we lose the productivity gained by attaching the top of a wall so that when the attachment point moves, the wall adjusts accordingly and is then able to potentially identify whether it violates span limitations (see above). It is next to impossible to estimate quantity and cost if you cannot determine actual heights!


Share/Save/Bookmark

0 comments:

Post a Comment