I'll borrow a concept from "You May be a Redneck if..." comedian Jeff Foxworthy.
"You may have too many worksets if..."
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.
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.
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).
"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
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)
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.
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).
No comments:
Post a Comment