Wall Quirks

Got very busy around here, hence my extended silence. To make matters worse, there’s Euro 2012 now so…while Zach Kron continues to chirp away at funky forms, nodes, divided surfaces and adaptive component families, I think I’m going to continue pointing out the Quirks of Revit Walls^{TM .}

When you unlock the bottom of a wall layer, you can extend it past its bottom constraint (and vice versa for the top). This functionality has been in Revit for as long as I remember. Nowadays we get a lot more control through Parts functionality if we want to fine-tune for panel joints, thickness, extents, etc. Layer unlocking is very handy when trying to rest the base of masonry veneer on a brick ledge or when you want the gypsum board layer to stop below the top of the stud layer for example.

However there is a peculiar condition that we’re presented with when we edit the profile of a wall to create an opening. I totally understand the programming logic of why, but from an architect/builder perspective, this does not make any sense at all. When the profile is edited, the bottom-most horizontal line is still recognized as the base of the wall, so if you edit the Base Extension Distance, you end up with that same extension happening at the “opening head”. And as you might have guessed, the programmer and I just don’t see eye to eye on this one as I don’t believe it should behave this way. Anyone else agree?

So in an effort to outsmart Revit, I inserted an opening instead. As you can see in the middle example above, it seems to solve the issue. However this only works if there is a positive offset value for the opening and as you can see on the right example with the opening having a negative or no base offset, the opening head is messed up once again…#fail3.

By now you’re ready to stop using the unlocked layer functionality; but wait a minute, there is a way (as always!): start an in-place wall family and create an opening in there (Revit will ask you to pick a host).

I know, it shouldn’t be this hard. We see eye to eye on that one.

When working on my first Revit project, I dealt with this same issue only to have it resurface years later while helping another team. It was actually the same exact design scenario: an exterior wall with varying “panel” finishes and continuous stud backup. The team edited the profile of one wall and nested the other in. However when the layers were subsequently unlocked and the masonry lowered to rest on the brick ledge, all head conditions messed up and started overlapping the layers of the nested wall. In such a case, your best option is to not even mess with openings and just embed one wall within another using the Cut tool in plan view, since it’s easier there.

Now when you need to adjust the size and location of the embedded walls, you won’t have to chase around the project correcting the openings as well. And the unlocked layers won’t give you any heartburn either.

Wall Quirks

Missing panels in contextual Modify tab

This has been happening sporadically in Revit 2011 and I believe it’s been fixed in 2012. Basically you would be editing a profile sketch such as a wall through Edit Profile, you switch your view to a standalone RFA family and upon switching back to the project environment, the contextual panels disappear and the contextual Modify tab switches to the usual Modify tab only, leaving you stuck in sketch mode with no apparent way back to the project.

The first way out is through assigning a keyboard shortcut for Finish Edit Mode: all 8 of them in 2011 (and 9 in 2012!). Honestly, I think there should only be one as the user doesn’t care which particular sketch mode is active: they just want to learn one shortcut that gives them the ability to finish any sketch mode. I sympathize with the technical reasons why there’s more than one, but if that is truly necessary, why make them look identical with no way to distinguish them except through endless hours of trial end error?

The second method makes the panels reappear so you can continue editing the sketch or finish/discard; here’s how you do it:

1. Start a new family, pick any one;
2. Load it into your project;
3. Once you get the error that it cannot be placed in this mode, hit Ctrl+z to undo.

For some reason the panels come back. Obviously, do not switch back to the open families or you’ll lose them again! This has happened to me several times now, especially when I open a profile family to “steal” the linework and paste it into the profile sketch of a wall. So if this happens again in 2012 in one of the 9 sketch modes, one of these methods might help you get out of a bind.

Missing panels in contextual Modify tab

iWall

I want walls to work as good as an iAnything. Seriously.

One of the fundamental checks an architectural team needs to perform is a simple span check. Trying to do that in Revit is next to impossible. There are other things we need to do with walls, such as life-safety plans, and we all know how easy/elegant that one is (not).

Walls have an Unconnected Height parameter that is unschedulable. Why? There is probably a logical reason, but we are really not that sympathetic towards anything that doesn’t yield what we want! The only reason I can think of is when attaching a wall to a sloped floor/roof/ceiling/ref. plane: the height now varies along the length of the wall. What we really need is an Average Height parameter instead. Or separate Minimum Height and Maximum Height parameters.

Despite talking about these needs, nothing seems to happen and Revit has not changed much on this front in the last 5 years that I have been involved in it’s use. I have no doubt that the developers are very well aware of these limitations, but trying to come up with reasons why this has seen no further development would be nothing more than speculation.

So in trying to focus on the current toolset, I tried various methods and will explain the pitfalls of each in this post. Now I’m sure an application/plugin can be coded through the API, but that is just not an acceptable solution for the majority of users, myself included.

Method 1 – A schedule

First, you’d need to add a Limiting Height project parameter (type) for the wall category. Now for each partition, you can add the span limit value for that wall. You can then build a schedule that auto-populates with walls that violate the Limiting Height value. This is possible through the use of some filtering criteria and calculated parameters and is especially relevant to fire-rated walls. Non-rated walls are difficult to check because they can usually be braced above ceiling and we have no way of telling Revit where bracing occurs. Even though it’s possible to brace rated walls, it is probably a best practice approach not to do so, so checking the span is even more crucial.

The major pitfall with this method is that you have to calculate the wall average height as it cannot be scheduled. The math is easy….Area/Length, both of which are schedulable parameters. However there’s a major pitfall: openings. As soon as the wall area is reduced by openings, the average height goes down. So now you’re checking unreliable information. “So this method is busted, Jamie!”.

Method 2 – Model Review

It is possible to access the Unconnected Height parameter programmatically through Model Review (available as a plugin for Subscription customers). However there are other pitfalls associated with it. If you manually type in a value for this parameter or you set the Top Constraint to a level, everything is fine. But once you attach the wall to a floor/roof/ceiling/ref. plane, the Unconnected Height becomes useless as it ceases to do anything to the wall.

The other problem with Model Review is that when building a check (Standards>Parameter Requirements), you can only check for a range of values and cannot specify another parameter as the value, even on the Filter tab. This means you have to build separate checks for each partition type as they all have their unique span limitations! It would be a lot more useful if we could write an expression that includes other parameters. EX: Unconnected Height>Limiting Height. If this were possible, we would only need a single check for all partitions in a project. So sadly, “this method is busted too, Jamie!”.

PS: You can probably write a plugin to use in Model Review for this purpose. But I’ve already made my thoughts quite clear on that.

Method 3 – Filters

To use filters, you have to have access to certain parameters. So this method isn’t really a method at all, because we cannot calculate the wall’s average height outside of a schedule (and that calculated parameter exists only in the schedule…how frustrating is that?). We also don’t have access to Unconnected Height. So once again, “this method is busted too, Jamie!”. The use of filters would be the preferred method as it could provide a clear, visual check that some walls need attention, such as if problem walls are filled in solid red in a plan view or non-problem walls are half-toned.

iMethod

I’m not saying that Apple does everything perfect, but they come pretty darn close it seems. I think it’s clear that a solution is lacking. There seems to be no plausible workaround. Do we need one? Absolutely. Walls just have too many unresolved issues and I think it’s time they’re given some serious attention.

iWall

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!

The "I" in WALLS