Opening Linked Models for Editing

NOTE: This is a re-post from the HOK BIM Solutions blog

One of Revit’s annoyances is the inability to open a linked model for editing and keeping it loaded in the host project, all at the same time. This leads users to believe they need additional sessions of Revit in order to refer to the fully aggregated model and edit the link/s at the same. Doing so causes various problems, such as reducing available RAM consumed by the additional sessions (0.35 to 0.4GB/session observed) and the potential to run out of network licenses for other users.

Revit’s UI gives us the option to open a link but at the same time, forces us to unload it. Somehow Revit seems incapable of having the same file in memory (based on filename) both as a link and opened independently in the same session. To make matters worse, most of our linked models are workshared, so opening a link in the way shown above is highly discouraged as you would be directly opening the central file. Revit does have safeguards for situations like this and does not let you directly do a Sync with Central if another user has synced since you opened the central file. Regardless, the current workflow of dealing with linked models is highly problematic and not sufficiently well-developed by the Factory.

Luckily we can work around the current limitations when the linked files needed for editing are workshared. We can in fact achieve this in the same session without unloading or requiring the user to open a separate Revit session by following these simple steps:

1. Make sure to not use the right-click option shown above (obviously!)

2. Navigate to the original linked central file and open through Revit’s Open dialog in the same session. If it is a valid Central File, Revit will automatically create a Local File by appending your username to it and happily open it for editing.

3. Alternatively, use the Revit Launcher (an HOK custom tool) to create a Local File for the linked model in question and open as usual.

NOTE: If the link to be edited is not workshared, you are out of luck and need to open it in a separate session if it is important to you to keep it loaded in the aggregated model.

Commentary

There is no doubt that this functionality needs to be polished further. The current implementation might be a reflection of various technical reasons/limitations, but should not be a reason to leave things in their current state. Here are some thoughts:

• Revit should be capable of opening non-workshared links directly and leave them loaded in the aggregated (host) model.
• If the link is workshared, Revit should recognize this and serve a UI that offers the same options when selecting a workshared file in the Open dialog so we can 1) open a detached copy, 2) create and open a local file so we can make changes and sync them with central (default), and 3) offer the option to open the central file directly.
• Give users the ability to edit a link in-context (in-place), whether it is workshared or not. This is not necessary functionality, but would be very nice to have.

Opening Linked Models for Editing

Some thoughts about Revit files

So now with the new feature built into Revit that recognizes the “DNA” of a central file and automatically checks the option to create a local file with the appended username, adding the word “central” at the end could actually cause confusion when your local file is named myproject_Central_dbaldacchino.rvt. This is why we’re probably going to stick with a script for creating local files like in the past, so we can control the naming conventions, besides some other benefits. Hopefully we’ll have an even better user-friendly version, which is still in the works.

That brings me to the purpose of this post: Why don’t the developers implement a file extension system that identifies what type of file we’re dealing with? Perhaps .rvc for Central files, .rvl for Local files and leave the .rvt for non-workset enabled files. This would make it totally clear what you’re dealing with, eliminating the need for arcane naming conventions. A unique, easily identifiable icon for each file type would also be a very welcome addition.

Some thoughts about Revit files

The Backup folder

A while back I wrote a post about a problem we had when trying to STC (Save To Central). The same issue re-surfaced again a few minutes ago, and similar to last time, we were a bit baffled. The network wasn't seeing anyone as accessing the central file, yet no one could STC or create a detached copy for that matter! Everyone working on the project (about 6 structural staff) were shown to be accessing some files in the Backup folder.

So we reluctantly asked IT to close out those people from the Backup folder. You know the feeling....you're just not sure if this is going to solve the issue or cause a major disaster! But we had no other option really. Well lucky for us, it worked once more. Everyone was able to safely STC with no loss of work. Now on to some Yoga....

The Backup folder

Who's in the CENTRAL?!

Haven't you ever heard someone yelling that phrase across the office? Well today I was more collected as I tried to solve a problem that popped up in one of our Revit projects. And oh by the way, there are cases where you could work in the central file, but unless you REALLY know all the nuances of worksharing in Revit, I wouldn't risk it (talk to your local BIM Manager for details...)

A user was complaining that he couldn't Save To Central (STC). I went to take a look and found that he was getting a dialog with a Cancel button and a key symbol, saying that the Central is being accessed by someone else (don't you wish it would also tell you the username?). This dialog typically disappears after a while and can pop up if two users try STC'ing or borrowing elements simultaneously, or if your network is really slow. For some reason, this dialog was persisting and would not go away.

My first instinct was to see what the Worksharing Monitor tool was reporting. The tool wasn't installed so first, we saved the local file, exited Revit and installed the tool (by the way, if you have an early build of RAC 2008, this tool will report and recommend that you install a newer build as it is not compatible with the June 2007 build). The Worksharing Monitor reported that two users where working in the Architectural Central file.....both where in the Structural group. Let the blame begin!

A few seconds later, one user dropped off the list and I could swear that the remaining user knew better. So I go to his desk and as expected, he wasn't in it (Revit wasn't even open). I tried opening the central file from this machine and auditing it, but the same dialog popped up. Even a Detach from Central resulted in the same thing. Next I tried to rename the file to confirm it wasn't physically open on some machine and it let me, which confirmed that no one had it open. This started to hint at a network problem.

I called up our Network Administrator (another David!) to see if anyone was accessing the Central file, but no one was. Interstingly enough, the Backup folder in the Central File folder showed up as being accessed by the user that raised the flag the first time, even though he closed out of everything. So David worked his magic and forced him out. We tried opening the Central and....ahhh...it worked! We were able to re-open the local file and save the work back to central.

The Backup folder contains a lot of rws and dat files that Revit writes so it can keep track of permissions etc. You should never mess around with this folder. So if something like this happens in your office, take a deep breath and lay that brick sample down (ouch!) and troubleshoot for any network issues before assuming that the central file has become corrupt.

Who's in the CENTRAL?!