Local Save Does Not Work - Follow Up

 After speaking with an Autodesk developer we now know that our issue is related to past eTransmit use. Revit mistakenly retained a flag it uses to mark that file as such.

If we can successfully use Synchronize with Central and we get that message when we use Save then the correct response to the warning dialog is the top option: "Save this model as a central model in its current location - Revit will remove this message and allow users to create local copies of the model."

Remember, the message is accurate for files that have been created via eTransmit too. In our situation the files were working fine on BIM 360 but they retained the flag that should have been removed when they were added to the cloud.

Info Added 6/4/2021: The warning is triggered ONLY in the following scenario:

The warning is triggered ONLY in the following scenario: The model has been transmitted and then upload to BIM 360 from Revit using the option “Work temporarily”.

To eliminate this warning for future project, please make sure you choose “Save as a central model in its new location” when uploading the models to BIM 360 from Revit.

BIM 360 Sync Failure Retry

Lately we've been experiencing some poor performance accessing BIM 360 projects. The primary cause eludes us at the moment, but Location Services, Windows Updates and Anti-Virus systems appear to be factors for now. Most of the time it works great but then...it doesn't.

Today I'm having trouble syncing changes with a project and this dialog has been stuck on my screen for about a half hour so far.

It's the fourth cycle of trying to Reload Latest... I think after a second failure to sync it should exit more elegantly. At this point I'm wondering how many times will it try before giving up? There is no option to quit or cancel...just stuck with forcefully quitting Revit at this point? That's polite.

How Often to Synchronize with Central - SwC

Grist from a recent support conversation..."How often should we use Synchronize with Central (SwC)? We have some users doing it every minute."

Well....every minute seems a bit much...but...

The number of people actively working on a file affects the truth of the statement too. Every 30 minutes, for example, is too infrequent in my opinion. My own habit is to SwC as often as I complete any given task. I tend to take small bites, tasks that are 1-10 minutes, and SwC as soon as they are done.

More frequent SwC is less data transmission than every 30 minutes, potentially. Replacing or reloading a title block for 1,000 sheets is not a small task and probably ought to be done at lunch, advising people to create new local files afterward. Otherwise each sync will need to needlessly update each local file's copy of the sheet's title block too, for everyone. If that is done while they are all away they just inherit the new version of the project with their new local file.

It's all relative though because the transaction comparison between syncing that kind of change and closing a model and opening it later is subtle. In fact opening a file again might be slower, but reasonable, depending on how many people are involved. It can be justified though, especially if they are out of the project anyway such as out for lunch or after hours etc.

I think it is more important to be aware of other users also using SwC, than imposing a specific time requirement. When more than one person uses SwC at the same time Revit has to parse those changes and it does so, more or less, in a single threaded manner, not like a multi-thread OS (though they are improving that all the time) doing simultaneous tasks. It has to reconcile changes and move to others once it is satisfied it can finish successfully. The more people forcing Revit to do that at the same time the slower it gets for everyone. That's where the advice to schedule or increase the time between SwC came from. One client decided to build their own tool so users can see if someone is syncing. A button on their Quick Access Toolbar parked next to the SwC button is red when someone is syncing and green when nobody is. Green means go for it.

Any sort of "Every 30 minutes" rule is often an over simplification, a rule meant to be easy to implement. In practice it can be just as harmful as helpful. If I slip and go 60 minutes or longer then that starts to slow down SwC times for everyone else too. Pushing and pulling data through a pipe takes time, smaller chunks of data generally take less time and less time to reconcile with the model too.

I'd focus on developing awareness of other users syncing as the priority and it's increasingly important the more users that are working on the same project file.

Tags Dimensions and Linked Files

I've mentioned this subject in the past. I'm writing to bring it up again and to focus on how Revit deals with tags and dimensions differently when we apply them to elements that are in linked files.

First as a reminder, when a linked file changes and a user reloads that link in their Local File other users are not necessarily seeing the same version of the Linked File. That's because reloading a link is a local change, a personal action, that doesn't get passed along to the Central File when we use Synchronize with Central (SwC).

Let's imagine User A has reloaded a linked model and they've placed tags on doors and rooms that they observe are now present in the link. User A uses SwC to share this new tagging effort. Now User B, who already has a Local File open, decides to use Reload Latest or SwC to share something they've done or see what work other users have contributed.

It's important to note that User B did NOT use Reload in Manage Links or via right-click on the linked file in the Project Browser FIRST. As a result User B gets the warning in the next image. Don't be confused by the mention of Coordination Monitor which can be confusing. It can make us think we're dealing with something that has been involved with the Copy/Monitor tools.

The Tags are Orphaned, they've lost their relationship with the linked file's elements they are supposed to identify. You can see one tag is highlighted in orange in the image above. In the next image we can see what the floor plan really looks like in the linked file (and what User A sees). It's not quite the same as what User B thinks it looks like is it?

Let's now imagine that User A continues to work by adding the dimensions you see in the image above too. After they finish doing that they use SwC.

User B now decides to use SwC or Reload Latest, AGAIN without using Reload on the linked file. Their reward is a larger collection of warnings (see next image). The first three warnings are dedicated to the dimensions User A added to their Local File. There are no equivalent elements in the version of the linked file that User B sees so Revit's only recourse is to delete them ... or ... choose Cancel ... which is actually a better choice. If User B cancels and then Reloads the linked file first that will eliminate the warnings entirely.

The remaining warnings are focused on the newly orphaned door and room tags that can't find their parent elements. If we select one of the orphaned tags we can either use Pick New Host or Reconcile Hosting. The former will need us to pick a door to associate the tag with. The latter will open the Reconcile Hosting browser which shows us everything that has been orphaned so far. We can select individual items and right-click to use Pick Host or Delete the tag if that's a better choice.

Keep in mind, once this orphaned status occurs it sticks. Merely reloading a linked file afterward isn't going to fix it. We'll be forced to deal with Reconciling Hosting. In some situations it might be faster to delete the tags and use Tag All to place them all over again.

This might be an opportunity for an enterprising developer to write a routine that looks at orphaned families and picks the closest possible host? Better still...Autodesk?

My recommendation, if you MUST use tags and dimensions on linked files?

Develop the habit of reloading the necessary linked files BEFORE using SwC or Reload Latest.

If you get the warning messages in the images above, use CANCEL. Make a note of the elements the warning(s) is(are) focused on. Most likely the warnings are being issued because you need to use Reload on the linked files first.

I'd also consider a moratorium on applying tags or dimensions to linked elements while the link is being changed aggressively. For example, if we know that the link is going to undergo some massive redesign we should just agree to stay away from tags and dimensions until it settles down again.

It's also a good idea to let other people know that you have changed an integral linked file so they can all use Reload (link) to catch up together.

Synchronization and Disconnected Systems

This is a bit idiosyncratic but if it helps sort out an issue then its worthwhile to echo it (based on a discussion at the Autodesks NG).

Imagine this scenario:

• An Air Terminal has an 8' elevation. A Duct rises from the Air Terminal to a elevation of 10'-0" and connects to a horizontal run (also at 10'-0" elevation), running parallel to the ceiling.
• User 1 raises the Air Terminal to an 9'-0" elevation. The vertical piece of duct connected to it changes in length, but no user is recognized as Edited by (owning/borrowing) for that element.
• User 2 decides to lower the horizontal duct (at 10'-0") to 9'-0". It is necessary for Revit to change the connected vertical Duct between the Air Terminal and the Duct to do so.

There are no warnings or alerts as these users do this. If a user decides to modify the series of elements, then a warning appears. A warning appears during Synchronize with Central only if this additional attempt to modify the element is made.

At the beginning I wrote idiosyncratic because it is easy to avoid if we agree not to work on each others elements. I would not ordinarily expect another user to decide to lower a duct that is connected to elements that I'm already working on. If we don't discuss what areas in the model we are focused on then it can easily happen. It is important to be aware of what others are working on. The Worksharing Display features can help us see what others are currently working on, if you don't really want to talk to your co-workers...but it's still a good idea.

Regarding the workflow above and not getting an error message, an Autodesk support person replied that they find an error message appears earlier to warn of the inconsistency when trying to reproduce the situation in the latest development build that will become Revit 2016. That means it is pretty likely Revit 2016 will prevent a duct element from being altered by two separate users when they interact with different elements that are both connected to it.

Rooms and Synchronization

Have you seen this error message before (images from 2012)?

It is followed by its grumpy brother.

The more complicated the project, the more likely that it uses some sort of linked file strategy. If so then it is pretty likely that Revit will fail to complete a Synchronize with Central (SwC) the first time you try, thus the message.

If you are like me you enter a comment each time (using SwC) for tracking and troubleshooting purposes. It is a pain to get a message telling you your SwC didn't work. It's worse that what you typed is lost. I finally got slightly smarter. I try to remember to copy the comment text to the clipboard before clicking OK. This way I can just paste it back in if/or when the error pops up.

I thought I hit on a sure thing by using Reload Latest before using SwC. It seemed to work for a bit but then it returned anyway. Still haven't pinned down the exact cause in this situation. It would be great if Revit could figure out that it can't resolve a SwC beforehand, probably a catch-22 situation though.

Synchronize with Central - Twice?

I frequently work with my computer connected to a client network without actually having it added to their domain. This means that we map the computer to a shared folder by entering the path and supplying the correct credentials to access the resource.

With 2011 I'm seeing a recurring theme where I must synchronize with central (SWC) twice to actually commit changes so that the other users can see them with Reload Latest. In the same way this afternoon I found that a user needed to double their SWC so that I could see their changes.

Just to add another wrinkle to the situation, the class is a mixed XP and Windows 7 operating system environment, some laptops using each. Their computers are mapped to the network as members of the domain. I'm not sure if these conditions have anything to do with the double SWC or not but it seems to be recurring when I am connected this way. Any corroboration from readers?