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.
Posts
