Wednesday, April 18, 2012

How Many Worksets Do I Need?

I'll borrow a concept from "You May be a Redneck if..." comedian Jeff Foxworthy.

"You may have too many worksets if..."
  • You have to scroll the Workset Dialog
  • You have a regular Tuesday morning Workset meeting
  • You have a workset for Sheet A101, A102 and so on
  • You have a workset for Doors
  • You have no idea what Workset "XXLLR21LRX" is for
  • You don't know the difference between Owner and Borrower
Okay enough humor. How many worksets is enough? Too many? You probably realize the answer is truly, "it depends". Worksets are meant to make it easier to collaborate. If they turn into a weekly Tuesday morning meeting then they aren't really working for you or the team.

Technically just one workset will suffice for Revit to function. Several will make it easier to define what your computer is loading into views and RAM. The whole model is still there, just not visible, that'll provide some relief for performance sake. How tangible or detectable that performance gain really is will depend greatly on the scope of your project. Recently I was working with a team, their building is a million square feet overall, and opening the whole file took considerably longer than selectively focusing on a single sector's workset.

This means each project should have its own workset structure based on its own conditions. There may be some worksets that many projects have in common, but it isn't the same thing as a Layer standard.

These are some examples of worksets. They might end up in your project or not.
  • Building Shell or Envelope
  • Vertical Circulation
  • Grids - Structure
  • Grids - Architecture
  • Wing West
  • Wing East
  • Wing South
  • Wing North
  • Floors Retail
  • Floors Condos
  • Floors Rental
  • Floors Residential
  • Floors Examination Rooms
  • Floors Laboratories
  • FFE (Fixtures, Furniture and Equipment)
  • FFE NIC (by owner that may be easier to manage alone)
  • Mechanical AHU1 (all connected equipment related to AHU1)
  • Mechanical AHU2 (all connected equipment related to AHU2)
  • Telecom
  • Security (this scope usually has "need to know" restrictions)
  • Linked Files - Architecture (Revit)
  • Linked Files - Structure (Revit)
  • Linked Files - Mechanical (Revit)
  • Linked Files - Plumbing (Revit)
  • Linked Files - Electrical (Revit)
  • Linked Files - Telecom (Revit)
  • Linked CAD - Architecture
  • Linked CAD - Mechanical Contractor
  • Linked CAD (etc... a separate workset for each intrisically related DWG file may be advisable)
Obviously you don't need all of these in one project, they are just a sampling of some you could use or consultants might be using. My intention is to focus on connected relationships. Who is working on this stuff (workflow)? Is this part of the building separated obviously from another part and could easily be grouped separately? When I mention performance I don't necessarily mean that the file will suddenly be 10x faster. I mean that Revit won't waste any time displaying information that I don't need to see right now, not here in this view or any view until I choose to Open that workset(s) again.

You don't need a workset for something that is already assigned a category, like doors or windows. That's what the category is for. It is rare you don't want to see any doors. It is more common to think I don't really need to see the doors on the west side of the building. The exception would be levels and grids. There is a little known technique for managing these using worksets when dealing with linked files and their levels and grids.

Worksets aren't meant to be fixed or rigid. You can expand their number if necessary and you can collapse into fewer if the need no longer exists. I let Revit and a team "speak" to me. The conversations I hear help guide me into more or less.

Time to transition to the other thing that worksets get used for, Visibility. This purpose causes a fair number of worksets, even some of those in the list above are motivated by "seeing" elements or not. In my case I'm interested in closing their worksets, "hiding" their elements globally until I need them again which is still "seeing" but not from a documentation standpoint.
    The visibility control over elements that Worksets provide is really a collateral benefit. It is not their purpose. Their purpose is to allow multiple users to concurrently work on the same project.
Filters were added for controlling visibility of elements on a view by view basis. You'll get a lot more mileage and options with them than using Worksets for visibility. If you reach for a workset to manage element visibilty you owe it to yourself to consider a deeper look at Filters.

For Revit MEP users Filters are much more necessary because many disciplines share a few categories that each other don't wish to see in their views. A water heater for example is Mechanical Equipment. I may not want a water heater visible in my HVAC floor plan and the plumbing views probably don't want to see a condensing unit in them. Both are assigned the same category. Filters will let us deal with that reasonably well, assuming the content is organized well. A workset might be tempting but we've got to remember to assign every element to the correct workset for it to be reliable. I've been using Revit a long time and I still forget to do it.

The single advantage that a workset has over a Filter is the ability to affect an entire project with a single change either while you are opening a project or when you need to transition to completely different portion of the project. The effectiveness of worksets hinges on users remembering to correctly assign the Active Workset as they work. Easier said than done.

With Revit 2013, and the changes to View Templates, Filters get sharper teeth because of the greater integration between Views and their Templates. Aaron Maller describes a method for controlling linked files with filters that begins with putting placeholder linked files in your project template (really just a project file to get started with).


Brian Payne said...

What's your opinion on Worksets by level? I have had issues in the past organizing everything given that a lot of architectural elements span multiple floors.

Steve said...

I resist that tendency but I've been involved with projects where it was the logical thing to do. I look for building design separation and programmatic cues to help decide where to assign worksets. Also who is responsible for things..

My priorities are: Performance, Workflow and then possible compelling visibility benefits. Not just visibility in Visibility Graphics sense, but opening and closing worksets, which may enhance performance and/or workflow.

ShawnF said...

It seems more and more are moving away from Worksets altogether in favor of element borrowing...are you seeing that trend?

Steve said...

The larger the team, the larger the project the less likely that will work...but yes to some degree element borrowing can let you ignore the worksets.

There is a bit more interruption and transaction time lost for each borrowing sequence. Selecting multiple elements and making them editable first can get permission once, more efficiently and have fewer transactions with central.

PLawton said...

Good info, thanks for the discussion.

As an MEP shop, we find that we can minimize the need for worksets by breaking mid-sized and larger projects (< 25k SF) into separate central files for each discipline (M, E, and P), then link in other disciplines as necessary for coordination.

A separate thought occurred when RMEP 2011 was still young: I can see where it would be nice to have an 'isolate workset' button, along with an 'unisolate workset' button, of course. I know this would violate autodesk's TINA policy (This Is Not Autocad), because that program already has the Isolate/Unisolate Layer function, but this functionality has grown essential in the design process for a good reason: we need it.

Thanks again

Steve said...

The Gray Inactive Worksets feature has the spirit of what you mention in make it more obvious that you are working on a specific workset.

plawton said...

Mr. S.:

Well, I've never used that feature, so thanks for the tip.

However, it doesn't 'grey' so much as 'halftone', really, which could be helpful to someone, I guess. A more useful function would be that halftone visibility control, along with a 'lock' ability, which would prevent folks from inadvertantly selecting elements of other worksets. It would also help with reducing the placement of components on the worng workset, which would also be nice.

With those attributes, it would become the same (very useful) thing that 'lock layer' is in Autocad, post-2008. Therefore, it will never happen, unfortunately.

MXM said...


First, a little background. My ofice is multi-disciplined where we all work in a single revit model. One question that is currently making the rounds deals with eliminating disciplined named worksets in favor of filters and view templates to control visibility. Also, it was stated that "element borrowing" in a single workset with many users should suffice. Red flags went up when I first heard this. Discipline defined worksets, I feel, helps users to clearly define which elements they should place and more importantly which elements they can edit. For instance, a beam on a structural workset should not be edited by an architect, etc. And what can be easier to control visibility in your views than hiding an entire workset?

(one of your 2006 graduates)