Structural worksharing

[Tom Weir]

Hi all,
I have been avoiding the use of worksets up until now because earlier versions did not seem reliable enough, and there were not enough people in our firm working in Revit to have to worry about it.
But with the release of Revit Structure 3, and with more and more jobs and people working in Revit I am going to start enabling worksharing on most projects.
Reading the tutuorials on the subject it refers mostly to architectural worksets: furniture, interior walls, etc.
I am trying to determine what are appropriate structural worksets that should commonly be created? Anyone with experience in doing this that mignt shed some light on what worksets they have created?

Here's my initial thoughts:

1. Grids and columns
2. Each floor framing view? or all floor framing views?
3. Braced frames
4. Concrete and CMU walls
5. Foundation objects
6. Wood shear walls for that type of building.
7. Typical detail sheets (or the drafting views that comprise the sheets)
8. The analytical model
9. The column schedule (or would that be active with the grids and columns workset?)

Any help would be greatly appreciated.

Thanks and have a great day...

Tom Weir
Los Angeles

[david_peterson]

That seems logical to me. But I would separate out each floor. (depend on building size and team size) As for the column schedule, I think it depends on how you create it. If it's truly linked back to the model, shouldn't that update on it's own, hence it would need to be apart of that workset? Also, with the framing, if you plan on exporting to Ram, you need to make sure that the horizontal members that are with the brace are labeled as horizontal bracing, so those beams may want to be part of that workset as opposed to the framing plan (If you follow me on that on) Just my 2 cents.

[dwickus]

Tom,

you know this is something I've been avoiding myself since we don't have many people on revit in our office yet, but I'd say I know others will be getting some training on it soon and I will have to face this. I like your suggestions. I was just thinking of doing things similarly as I did in Autocad and then make more workset as necessary. The grids and columns would be a good workset and each level would be very helpful. Then details, elevations, legends etc could each be worksets so that. Eventually I think we want to get our engineers involved so I would probably have a workset so they can do their thing. Sorry I can't offer more good advice since I this is the most I've thought about it so far, but I hope it helps for what it's worth.

dave

[Paul Andersen]

Tom, In general I prefer to have as few user created worksets as possible. Depending on project scale and deadlines often times one person can handle the entire model and other team members are brought on board to develop the construction documents and help with detailing. Under this scenario I would argue that no user created worksets are required other than the defaults that are created upon enabling worksets (shared levels and grids and workset1 which usually gets renamed to physical model or whatever). Under this workflow the team member in charge of the model would have both user created worksets checked out. All other team members are just working on views (which by default are already their own workset) and creating sheets. These team members can work as they always have without worrying about worksets at all . . . no need to check anything out. The only thing that they can't do is edit already placed model geometry without placing a request. An interesting thing to point out with this workflow is that should the primary modeler need help with the model there is no need to create an additional workset. For example if a team member was required to help frame the entire second floor, as long as they were only adding members, they would simply make the physical model workset their active workset (which would be shown as non-editable) and they could add all of the framing. After everyone saved to central the framing members would be owned by the primary modeler and would no longer be editable by the team or the individual who placed them.

On larger projects and/or projects with tighter deadlines where other team members will also need to do modeling the workset setup is largely driven by the type of project. We've found that large sprawling multiple wing buildings and campuses work best if they are broken into areas generally along expansion joints. Each area has it's own workset and the owner of that workset works that area of the model from foundations on up. This method seems to produce the least amount of collisions and generally avoids the need for borrowing requests.

On multi-story buildings with a more compact footprint we have broken the model into foundations and superstructure and have also broken superstructure into individual or multiple repetitive floors. This workflow generally results in more borrowing requests or more user created worksets to avoid them than the previous two. For example: a team member who is working on the superstructure may want to adjust the bottom of column elevation to be 2'-0" lower than it currently is which in turn will attempt to push the isolated footing down. If all of the foundations are in a foundation workset checked out by another user this will result in the need for a borrowing request.

The beauty of worksets is that they are very flexible and easy to add, adjust or completely restructure midstream if necessary. In general I think starting with the default worksets and an add a workset as you need it approach is a good way to initially attack it. I tend to bounce around a lot when modeling a project (which may or may not always be the most efficient) and the addition of too many worksets tends to slow me down and get a bit restrictive having to toggle between them. I start to get layer / level flashbacks ;) .

[Tom Weir]

Hi.
<All other team members are just working on views (which by default are already their own workset) and creating sheets.>

I did not realize that....Like you say using the fewest worksets possible is a better way to go.
I think at most we would have 3 people working at one time on a typical project, usually 2.

On multi-builidng projects I have relied on linking whenever possible. For instance I have a high school campus that has a parking structure with a gymnasium and multi-purpose building sitting on top. I have them cross linked and things have gone ok.

So I am going to try to using both methods as required.

But if someone is working as you say, ("make the physical model workset their active workset (which would be shown as non-editable)"), can they still borrow elements and such if they have to edit them?

Thanks.

Tom Weir

[Paul Andersen]

But if someone is working as you say, ("make the physical model workset their active workset (which would be shown as non-editable)"), can they still borrow elements and such if they have to edit them?
In short yes. A team member wishing to edit any of the already placed model elements checked out to the primary modeler will trigger an edit request that will need to be granted or denied by the primary modeler.

Once you get more comfortable with worksets there are a lot of other strategies and uses beyond just breaking it up for multiple users. A couple of examples would be to use worksets to add another layer of visibility control and utilize selective open on larger projects to ease the demands on your workstation or just to focus on your specific area of the model.

[Jos Arpink]

Hi Tom,

We are similarly struggling with this, and have come to the same conclusion as Paul. Less is more. Having gone the route of too many, our current thinking is to start with just 3 worksets:

1, Shared grids & levels
2. Structure (our model)
3. Arch (their model)

The Arch workset allows us to quickly toggle visibility on or off. (Note to factory: Why isn't workset visibility available in View Templates?)

I think it's easier to add worksets only when necessary, to suit team size and project type.

Hope this helps.

[Tom Weir]

Hi Jos,
It sounds as if you are doing both Architectural and Structural together in one model, as opposed to us who are linking in the architectural. Revit Structure 3 has really increased our ability to control the display of the linked model, so we can go a long way with that approach.
The less is more approach though sounds like the way to go...so I am proceeding...cautiously.

Tom

[Steve Mintz]

jarpink brings up a good point. Linked models are objects as well; as such they must belong to a workset.

I believe jarpink is refering to creating a workset (Arch Model) that the linked architectural model will be in (i.e. Arch Model : linked file : TheirArchModel.rvt)

I discovered the hard way that there are 3 objects associated with a linked model, one of which is counterintuitive and has no physical representation that can be selected. The only way to select it is by ID number, which you can find out through error messages.

Its a lot easier to make sure the workset you want the linked model in is the active workset when you bring it in. Its possible, though difficult, to change worksets after the fact.

[Jos Arpink]

Steve, yes, I am refering to the Architect's linked RVT model, or their linked CAD files, as the case may be.

[Tom Weir]

Hi,
But you can't work on the linked model, so why make it a workset?

Tom

[Jos Arpink]

Hi Tom,

You're right. It just gives us a really quick and easy way to turn off visibility.

[Phil Palmer]

You can also selectively open your local file to exclude the linked models at anytime.

[Steve Mintz]

But you can't work on the linked model, so why make it a workset?

Tom
Even though you can't work on the linked model, is still needs to be in a workset. Logically, the best location (aside from its own workset) would be in Shared Levels & Grids.

I discovered a small problem putting it in the "Everything else" workset (or "All Others", "Structure", etc). If UserA owns the workset, UserB cannot create an element related to the linked file by using the Copy/Monitor tools.

Most of the time, this won't be a problem. After all, you can only Copy/Monitor Grids, Levels, Columns, Walls, and Floors. But it will eventually come back to bite you in the butt (it did to me). And when it does, as I mentioned previously, there are 3 objects you must change the workset of. One of them can only be selected by ID.

[Tom Weir]

Hi,
Oh... a linked model needs to be in a workset. What about a 2D Autocad import background? Same thing?

I am just starting a job with a linked model (from super Reviteer Scott Davis' company WLC), so I will do as you say and put that in a grids and columns workset. Thanks fo the tip.

Tom

[Jos Arpink]

Hi,
What about a 2D Autocad import background? Same thing? Tom

Yes, 2D Autocad imports as well. But how they behave depends on how you link them.

In the Import/Link dialog, right below the 'Link' checkbox, is another checkbox for 'Current View Only".

If you check this option, the linked Autocad import belongs to the view's own workset, which can't be changed (as far is I can tell), and the import will not be visible in any other view. It behaves like a detail (drafting) component, and will always display 'on top' of the model, assuming you choose 'foreground' instead of 'background' in the options bar.

If you uncheck this option, the linked Autocad import can be assigned to a workset, and behaves like a model component. It is visible in all views, and its appearance is subject to the quirks of the view's model graphics style...wireframe, hidden, etc.

I think each has its advantages. Unfortunately, I think the workset functionality applies only to the later.