Scheduling the Unschedulable

The more we venture into BIM (taking real advantage of our Revit models), the more this subject is starting to tick me off. You’ve been warned!

Let’s take a look at what caused this “rant”.

Here you can see the family parameter “Structural Material Type”. I want to use this really bad because I’m doing quantity take-off schedules for all elements, which include structural framing elements residing in a linked file. So I want to create a framing schedule for steel and another for concrete. The reason is that I want to find the total weight of each material in the job and as you know, concrete and steel have different densities.

So to calculate this, one can create a calculated parameter in the schedule and voila. I would prefer to expose the density used in the schedule (so everyone can see it. I don’t like to bury assumed values in formulas if possible). However since the families reside in a linked file, you cannot add this information to your project via a project parameter, so you can only have one formula with a fixed value (one density value). So the only way to do this is to create schedules for framing members with different densities. I know, I can get into the linked file, but that’s beside the point.

Unfortunately, you cannot schedule the above highlighted parameter, which would typically raise the question, then why the %^&**&?!!@? do we have it? How can I filter views/schedules of my insanely intelligent model? I cannot even filter by family name or type either!

This is only one little thing I came across and is very irritating. I found more issues when calculating volumes, but that will be another very lengthy post, so stay tuned.

Scheduling the Unschedulable

Rooms

In Architecture, one of the most important parts of the whole process is to decide what to build. In the US, we call it “Programming”. In Europe, we call it “Briefing”. And I’m sure in some other region around the world it’s called something else!

Essentially this is a process by which we ask questions about the spaces we’re designing for. Questions such as, “what size”, “what finishes”, “what height”, “what equipment”…once we have this information, then and only then can we design something. We can later assess and gauge whether we did a good job by ensuring that at least we met these agreed upon requirements.

Arguably, the most important “what” question is about size: the “Program Area” or “Target Area” of a room. Why isn’t this a built-in parameter in Revit rooms? This is becoming increasingly frustrating as we start looking at API tools to enhance our workflow. For example in the SDK, there is a handy “Room Schedule” tool (thanks for pointing this out Guy!) and the example Excel file has a column for “Room Area”. This example is “flawed” if you ask me, because that column should be called “Target Area”. It’s not “Room Area” until the room is placed in an enclosure This API tool can create Revit Rooms from an Excel workbook and can also update the workbook from the Revit Room data.

Assuming the column was called “Target Area”, the only way to really populate that parameter in a project is to add it beforehand to your project/template file as a Project or a Shared parameter and customize your code to write to it. But WHY NOT have it already built-in? The act of programming is central to Architecture, and the information collected during this process should be easy to record in our B I M. It should not require additional custom parameters. Because of this, we cannot exploit the full potential of this SDK tool as it needs further customization to have it copy the “Target Area” column to our version of “Program Area” in a project.

Another example where we have to deal with this same issue is when using Trelligence Affinity with Revit. Even in this case we have to customize our installs to map to the correct Program Area parameter. These are totally unnecessary pains that both 3rd party software developers and us working in this field have to endure. We’d all rather direct our energy to more important parts of our respective projects instead!

Rooms

Text Notes

So in Jumpy Text, we looked at a technique that we can employ to alleviate the well known deficiencies of text in Revit. Now you know how to use Key Schedules for this purpose, but I wanted to take this a little step further after a great tip I learned from a discussion with my good friend Daniel Hurtubise of RevitIt.

I mentioned the problem of the schedule title being the same as the name of the key schedule in the Project Browser (PB). So if you prefix the names to group them nicely in the PB, you’ll have a problem with your title. To get around this, we can disable the title and group the headings. Then we can type in our new “title” in this new space, independently of the name!

The problem though is that for notes on documents, we don’t need the headings, so this solution wouldn’t be very clean as we don’t want to see the parameter names and if we turn them off, so does the new group “title”. However Revit lets us edit these names and to my surprise (and here comes my little contribution), it lets us make them blank! So by unchecking the option Blank row before data, we can still end up with a separate title, a blank row and our text notes indented with a number for each paragraph, as you can see below (click to see larger animation). This is without a doubt a better solution than typing text for the title. Enjoy!

Text Notes

Jumpy Text

This is one of the most annoying behaviors in Revit. I can’t believe that we’ll have to deal with it for at least another year. Pretty sad.

We need text, don’t we? Unfortunately creating project notes in Revit is a frustrating endeavor. Text re-formats itself depending on the zoom factor, which is totally insane if you ask me. Take a look at this animated gif.

So how do we deal with this issue? You could link in a dwg that contains your text, but this can potentially result in more headaches as mtext boxes are sometimes ignored by Revit. And honestly, I want to stop using DWG files altogether. Another huge limitation is the inability to indent text so you can number each paragraph and be able to adjust the column width of your text without resulting in a formatting do-over.

Back at AU2007, I learned a tip which I’ll be employing from now on. I feel really dirty using it, but there’s no other solution I can think of. I’m not sure where it originated but I learned about it through a hallway chat with the “Rock-n-Roll Architect”, aka Steven Shell. If you know who contributed it, please post a comment. Here it goes…

Create a Key Schedule for a category that you never use. No, the Roads category is not available ;) In this example I chose the Sprinklers category but you’re free to pick anything you want.

Notice the Name field. That’s the name of your key schedule in the project browser, and will also be your Title when you drag this onto a sheet. It’s not necessary to change it in this dialog since you can rename it later in the Project Browser. I named my example “GENERAL NOTES”. Next, type in a Key name and click OK, which leads us to the Fields tab.

Add a new parameter to house your text notes; I used “MyText”. In the Sorting/Grouping tab, sorting will be set by default to the Key Name, which is exactly what we want. This will contain the numbering of each paragraph. To finish up, set your appearance preferences. In my case, I wanted a wide outline and turned off the option to Show Headers as we don’t really need them. Once you click OK, you’ll be in schedule editing mode which will just show the title (If you choose to not have a title, you’ll get a blank page). The next step is to add rows to your key schedule. Let’s use Revit’s new interface to illustrate (click animated gif for larger view).

Now you just drag this onto a sheet and make final adjustments there. This should eliminate the problem of Jumpy Text. A couple of issues that you’ll face are the fact that you don’t have Project Browser sorting/grouping capabilities and that you cannot use the same schedule name twice, so you’ll have to get creative. One option is to have these key schedules named with a prefix so they’ll be grouped together in the Project Browser and separate from “real” key schedules (ex: txt_Roof General Notes). Then you would turn off the Title and just type in text directly on your sheet as seen below.

PS: Autodesk, PLEASE, this needs fixed. Seriously.

Jumpy Text

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