Best Practice for Linked Revit Models and Worksets

[Anonymous]

We are establishing our first standards for Revit and are having an internal debate about linked revit models and Worksets.

One group wants all linked models, say "MEP" and "Furniture", to be one a single Workset named something like "Link- Revit" ( as opposed to Link-CAD).

The other group wants each linked Revit file (or CAD file for that matter) to have its own Workset so the user can pick which he wants to open when opening the host model.  This would result in Worksets such as Link-MEP and Link-Furniture.

Which route, if either, is the recommended practice?

[AJA14 · Accepted solution]

Hi. I would recommend to create a different workset for each. Putting them both (or all) on the same workset may result in very poor performance due to the large amount of linked data. You can easily select which workset to open or close later on while working and adding a couple of clicks later on will not be an issue. Also remember to make your linked models set to (not visible in all views) and override that setting using the VV overrides. This also improves performance a lot. Hope this helps.

[Anonymous]

Thanks. Those were my thoughts and you reinforced them. [Description: Description: Description: image001] Paul Ashley Lead Technical Analyst U.S. Restaurant Design 630.623.7377 | 630.214.5556 | paul.ashley@us.mcd.com McDonalds USA LLC | 2111 McDonalds Drive | Dept 043 | Oak Brook IL 60523 ________________________________ The information contained in this e-mail and any accompanying documents is confidential, may be privileged, and is intended solely for the person and/or entity to whom it is addressed (i.e. those identified in the "To" and "cc" box). They are the property of McDonald's Corporation. Unauthorized review, use, disclosure, or copying of this communication, or any part thereof, is strictly prohibited and may be unlawful. If you have received this e-mail in error, please return the e-mail and attachments to the sender and delete the e-mail and attachments and any copy from your system. McDonald's thanks you for your cooperation.

[GallowayUS_com_RonAllen1]

The link per workset I Believe is a direct hangover from a misused practice in CAD for folks who didn't want to use the xref manager to load or unload or "-la,f,"*xref1*|*" from the command line. Turning off this layer would knock out the link in a view - and make it hard to find out why a particular layer in a link wasn't showing. This is a PITA to back-track items not visible in the current view (Right off adds two 'switches' thac can turn off in view: Workset loaded? Visible?- repercussions for linked file and same-named worksets as well. In short, it greatly overcomplicates things.)

Unloading the LINK in revit has the SAME efficiencies as unloading a workset with the link. Controlling using VG will optimize display performance (from my rough testing on a very large set of file on A360 / C4R).

Now the number of times I have tried to hunt through why something was not visible- I advocate NOT managing LINKS per their own workset. IMO we generally avoid using worksets to control visibility (with some exception for systems in MEP)

Based on this, links should not be placed on individual worksets and the disadvantages to workset-per-link greatly outweigh any advantages of using worksets to load links at startup. Workset 1- leave it on and forget about it (like layer 0)

See attached for some illustrations and times using a average set of models.

[Anonymous]

Ron.Allen,

I find that on large projects (airports) it is sometimes best to have a workset for each linked model. We sometimes get very large files from clients (sometimes as-built scanned models 5 gigs in size) and having them open all at the same time makes modeling cumbersome. I almost always use the specify worksets option when I open projects and load in the disciplines I need as I go. This saves time modeling and opening files.

As an example, when I worked on the Hong Kong airport, if I opened all the worksets and their associated links it would take 30 mins for the project to open (if it did not crash). The only way to deal with this issue was to have separate worksets for links. That is not to say that this method is perfect either. If you do not have all the worksets loaded you may not be seeing the final print conditions when doing sheet work and you have to be knowledgeable about the specific project to know what you need to have open to work efficiently. We usually broke down what worksets you needed open based on what building you were modeling in or doing sheet work on.

I do agree with your method of not using worksets to control visibility though. I also think that when working on a smaller project it would be best to have less worksets and load everything when opening projects if you have the available RAM to work efficiently.

[Viveka_CD]

Interesting thread.

Hi @GallowayUS_com_RonAllen1

Thanks for sharing your workflow.

This will benefit the community seeking similar answers.

Regards,

[GallowayUS_com_RonAllen1]

Why are workarounds needed for MEP systems broken by model separation? Actually, they aren't.

Revit has a means to manage that but it has be usurped by the  CAD hangover of tying links to worksets...

Granted, Some of this breaks will still exist where there are central plants and lugs to attach buildings to  electrical, but once in  the building, workset zones should be used to manage what is loaded or unloaded. When systems analysis needs to be run, all the associated zoned worksets can be loaded and all the MEP systems or structural systems will come in together, intact.

I have spoken with several teams at Autodesk about incorporating a load worksets and load links menu in the front end of Revit's OPEN menu. Hopefully, one day : ), the functionality to unload links on OPEN will be a reality. In the meantime you can eliminate unwanted links by managing work areas, and by saving he project with the links unloaded.

[GallowayUS_com_RonAllen1]

What we really need is a way to manage worksets from a central core, and have hierarchical structures of worksets for loading and unloading.

Looking towards one single giant model (No separate discipline models)  E.G. you may want to load a small wing of the airport, and not load the cloud data. If it had structured worksets:

• AreaA (Arch model)
• AreaA.Pointcloud
• AreaA.Mechanical.Supply  

Each of those could be loaded or unloaded in one big central model.

A way to restructure this so your systems don't break under the federated discipline models approach:

• Assuming you are in the ARCH file and you have files for:
  • point clouds
  • mechanical
• Each of these have an "Area A, b, c, ..." workset

You can choose to ONLY load "Area A" Which will also only lod that workset in corresponding linked files.

When you save UNLOAD the point cloud file so it will be unloaded by default on the next open.

When you first link in a file you don't want loaded every time - unload it on exit.

[Alfredo_Medina]

At the moment, we don't have the option to unload parts of a model before we open it. The only opportunity we have is to close worksets before opening the model (assuming that the model has been saved with the Specify option for worksets).  So, being worksets the only way to close parts of a model before the model opens, I would prefer to continue putting links in worksets. The loading / unloading alternative does not let me do that before opening the file, but after. If the model is too heavy, and there are several people in the team, that time wasted and multiplied several times cost money and hurts production. Beisides that, I have seen some inexperienced users unloading a link just because they don't need to see that content in their views, without realizing that the link is being used in other views. Fixing those errors takes time, too. 

[Anonymous]

You said it better than I could.

[Viveka_CD]

Hi @GallowayUS_com_RonAllen1

I hear you.

As the starting point, it will be best to post your issue in the IDEAS forum to gain visibility, check for votes and add additional comments. Also, keep an eye on the roadmap.

Regards,

[GallowayUS_com_RonAllen1]

@Alfredo_Medina the zoned worksets allow you to do that : )

That is where the practice of unloading the link (rather than unloading the workset) before saving comes in...

Even if you are starting with templates that have pre-backed placeholder links, even those links start from the template as unloaded : )

And under the zoned worksets system- the model is lightened by only loading zones in which to work.

By tying worksets to links it may foul that process completely in the load.

[GallowayUS_com_RonAllen1]

Follow here to vote to make worksets and links loadable on open:

https://forums.autodesk.com/t5/revit-ideas/control-loading-of-links-and-or-worksets-on-open/idi-p/77...

[Viveka_CD]

@GallowayUS_com_RonAllen1

Thanks for sharing!

Please add comments to the idea to gain visibility.

Regards,

[Alfredo_Medina]

Ron, 

How do you prevent this situation with your idea of unloading links:

True story: architectural team and structural team are doing colocation for an IPD project. Both disciplines are in the same model. The model has links for MEP disciplines and civil. A new intern joins the structural team. On his first week of work I discovered that in my architectural views where I was placing some elements in relation to some fire protection pipes, those pipes have disappeared. After searching for my Fire Protection file, I discovered that the file is gone, unloaded. After asking around who unloaded the link we discovered that the structural intern unloaded the link just because he did not need to see those pipes in his views. Question for you: was it not better for the team if he just goes to HIS structural views or HIS structural view template and turns off that link instead of affecting MY views by unloading the link from OUR model?

[GallowayUS_com_RonAllen1]

Been there- done that- mine was Architectural and Interiors.

In a nutshell- the process I outline in my PXP Revit Construction Model Management uses placeholder links in the template to predefined views to get us 85% there when starting. Reloading from for each of the used links.

Every link goes on WORKSET1.

All the graphics are driven through the line weights, line patterns then object styles, then if necessary *for MEP in particular, the view templates pick up what is shown, halftone, on or off,  and coarse, medium and fine.

Users must be educated to use unload link for me only- or not at all, and how the loading of worksets in zoned areas work : )

Over the years I try to remember to look at the loaded files as part of troubleshooting, I am human and do forget : ) Which is why I keep reiterating the process so I don't have to : )

[GallowayUS_com_RonAllen1]

Revit 2022.1 

This shows the memory impact with a large linked file - Close/Open Worksets has about the same impact as Load/Unload links.

TIES: Load/Unload and Open/Close have about the same effect on memory. Either make content in linked file unavailable on Unload or close. Each operation can allocate 100MB or more of memory.

CONS(Worksets):

• All or nothing loaded or unloaded (Pro & Con- is what it is designed to do)
• Not all models are workshared! Non-workshared  files can be uploaded to the ACC/360. No workshare means no ability to unload workset
• Increase complexity - Unloading worksets cascades through other models's worksets, workset naming cannot match I.e. Unload Links unloads in every model with attached links unless naming unique...
• Adds ~100K per workset to memory
• One more item to have to manage for every object in the model (I.e. placed on wrong workset)
• Unloading link completely unloads all links, or multiple worksets multiply chances for displaced elements
• Complicates Visibility/graphic debugging (could be links workset, could be cascading link workset, Could be model workset,  could be template V/G, could be unloaded)
• Conflicts with Zoned worksets for large projects e.g. Airport concourses area A, B, C, D, E... used to keep MEP "systems" intact

PROS(Manage links):

• Works for Non-workshared files
• Fewer places to accidentally displace elements- less stuff to track
• "Unload for me" won't affect other users on Sync to central.
• Select loading of worksets on open for partial loads- I.e. Shell and core only.
• Visibility Graphics more reliant on Templates and V/G settings with less to debug. (Could be model workset,  could be template V/G, could be unloaded)
• Allows Granular control and "Unload for me" options without affecting other users
• Granularity of element control VIA elements VIA linked model.
• Won't conflict with Zoned model areas