BIM 360 Linked Revit Models use Local Cache Path

We've been running into this situation lately. Linked Revit models start using an individuals collaboration cache location for the path instead of the project's BIM 360 location.

At first it seemed that we could resolve it easily by applying the update for Revit 2020. Most of the active projects I deal with are still based on Revit 2020.

It appears that a fair number of firms are deploying "even" years and skipping the "odd" years. The larger the scope of deployment seems to have some influence over that choice. I've been working with 2021 in smaller situations though, wishing it were true everywhere...I digress.

Autodesk acknowledges the issue and has this ARTICLE to contend with it.

Wishing it were that simple, we are still running into it. Naturally there is another ARTICLE that mentions they are still researching the issue but that using Force Relinquish (BIM 360 Manage Cloud Models option) can cause this situation too. This requires us to clear the collaboration cache for a user who has forced us (haha) to use Force Relinquish. We are still in the diagnosis phase ourselves so we're not convinced of anything yet.

The article also tells us that using Force Relinquish should be a last resort and not recommended for routine use. Autodesk article says, 

"This is happening because somebody has used Manage Cloud Models to force relinquish that user from that link, which breaks the link in the host model for the affected user."

"Note: Force Relinquish is a destructive operation and should be used sparingly! It is intended to be used as a last resort when the user to be relinquished is unavailable for some reason."

"If someone has been forced out through Force Relinquish, then all the changes that they have not synced, become orphaned and lost. While the central model will be unaffected by the use, people can lose work (and have to close and reopen the model which will be slow)."

"It is better for the user to open the model and use Relinquish All Mine to relinquish their permissions rather than using the Manage Cloud Models dialog."

Okay, that's fair. However the new named user subscription based model "forces" this option on us (not haha) at large because we can't pretend to be another user anymore. As soon as we log off to become that user we lose our Revit session too. Catch 22

It would be nice if employees didn't quit and go elsewhere or earn a dismissal. It would be nice if 3rd party applications didn't need to borrow a workset on our behalf and then refuse to return a workset without our knowledge. It would be nice is 3rd party applications that do automation didn't require their own username to run quietly in the background and then fail to return a workset from time to time.

That world is where we can find pink unicorns with diamond encrusted saddles, at least I think that's where they are, I could be wrong?

Right now clearing a workset conflict in Revit Server projects is not nice. BIM 360 at least has Force Relinquish...but now we're told you really shouldn't use it because it might wreck your linked model paths. It starts the kind of internal conversations that make EyeTee license management "heads spin". Nobody wants users to start sharing log in credentials do they?

Additional Collaboration Cache Article

Unloading a Link Deletes Radial Dimensions

I read THIS post at RFO with interest naturally. The thread is about losing dimensions when linked files are updated. A subtle development in the thread is that radial dimension and linear dimensions are affected differently when a link is unloaded. Aaron Maller noticed that, mentioned it (in the thread) and asked someone at Autodesk about it. They looked into it and replied with:

Originally Posted by Autodesk Team

Here are the details. This is caused by the inconsistency between linear and radial dimension internal design.

For linear dimension, it handles “Unload a linked file" as a special case of dimension references not visible in the current view, while for radial dimension, it handles the unloading as invalid dimension reference, and thus it requires deletion of the radial dimension when unloading.

We will see how we might improve the radial dimension to follow a similar behavior pattern.

The emphasis was added by Aaron. Okay, good to know. For now, radial dimensions are at great peril if they are referencing a linked project. Best bet is to avoid dimensioning to linked elements anyway but especially so with radial dimensions. 

Linked DWG Xref Overlay vs Attached Bug - Part Two

Two options exists to work around this situation (last post). One is easy and Revit focused but depends on the AutoCAD user a little and the second is impractical and depends on the AutoCAD user entirely.

• Xrefs on their own layer
• Xrefs always unloaded

If we can count on the AutoCAD user being consistent to assign all of the file's xrefs to a unique layer not shared by any other elements then we can still turn off the overlay xref when it shows up. This shouldn't be too difficult to achieve and many firms already have that standard for xrefs.

If the xref's are always unloaded before closing a file then they won't show up in a Revit project. That's pretty unlikely. It's inconvenient for AutoCAD users and forgetting just once and the system fails.

Linked Details - 3rd Party Tool Options

This is an update to a much earlier post after getting a couple comments on that thread. These are three companies I'm familiar with that are providing solutions that contend with sharing details between projects and multiple model projects.

Revolution Design - Revit Workflow

26 Degrees Software - ViewAQC

Parallax Team - Parallax Linked Details

Check them out!

Remember Linked Files Have Two Workset Parameters

I find this overlooked regularly. Each link has an Instance AND Type parameter called Workset. If we select a link (RVT) in the Project Browser we can see the Type parameter for workset, even if the link isn't loaded.

If we right-click and choose Select All Instances > In Entire Project we can see the Instance parameter value, unless there is more than one instance (copies of the link).

The best way to ensure that both parameter values are assigned to the same workset is to make sure the Active Workset is set correctly first, before we link the file. If not then we have to check both values.

Why are there two parameters?

The Type parameter governs the existence of the link in the database while the Instance parameter governs the actual instance you can see in the model views. The linked file can be copied, for example House Design A can be copied so we can show that it will be located on several lots within a development, each likely oriented differently.

The instance parameter allows us to assign each copy to a unique workset while the Type parameter affects all of the copies. That means closing the workset assigned to the Type parameter will close all of the copies of the link, none of them will be visible.

If we close the workset assigned to just one copy then only that linked file won't be visible.

If we experience erratic issues with linked file visibility it is the first thing I check. I'm also in the habit of looking at all the linked files every time I get introduced to project. This also applies to other linked files (CAD,Point Cloud).

Cannot Publish Coordinates

I've run into this with a couple clients recently, this warning message appears:

Quirky work-around warning...

• Building Model: Make sure you have a Local File for it (I save to my own PC)
• Site Model: Change the saved path to the Building's Central File to your own Local File instead
• Site Model: Publish Coordinates
• Site Model: SwC (should succeed and get a prompt to Save changes to the linked file)
• Site Model: Close
• Building Model: Open your existing Local File SwC (passes shared coordinate data to central)
• Building Model: Close
• Site Model: Reset the path for the Building to the central location

Any future Publish Coordinates, if necessary, should work after that.

The error message is tied to linked files (DWG) that are actively changing. Revit would notice those links were different than the version it had a record of during a SwC, even though it does not reload links during a SwC. I imagine it takes note of the file date or something high level that defines the DWG in the database. The solution then was to reload those links before using SwC.

I have found since that it has been possible to avoid the warning if any linked DWG files are unloaded prior to using Publish Coordinates. In at least one situation we had to go through the steps above even when there were no DWG's linked/imported. Autodesk documentation says in some cases it can be associated with file corruption.

Quirky...     

Revit Coordinate Systems Video

A lengthy exchange at Autodesk's User Forums about this subject reminded me that I've meant to create a short video to describe how they relate to each other for quite awhile. This morning I saw our cutting boards drying next to the sink and realized they could serve as metaphorical coordinate system planes (Project and Survey) work in Revit. I am curious if readers find it helpful.



The original post at the forum dealt with a few projects that had been modelled very far from Revit's Internal Origin/Startup Location. I looked at one of the project files and found the Survey Point and Project Base Point had been moved very far away while unclipped. The modelling started there, really far far away. They started to experience some of the negative symptoms that can occur and started looking for solutions...thus the original post. The short answer is they needed to move their model closer to the origin. No other way around it.

Link DWG and Named UCS

Working through a couple support issues recently it turned out that the presence of a Named UCS prevented us from linking a DWG using By Shared Coordinates. Revit would force the DWG to link using Center to Center instead. We tried all the things to resolve it first until we remembered to check this too.

This has been a part of Revit for a long time, the "REVIT60" in the name is the Revit version when it first appeared, Revit 6.0. When we use Publish Coordinates on a DWG file Revit creates this UCS so it can be used from within AutoCAD to ensure any external references that need to align with it will do so. We can delete the Named UCS in AutoCAD by right-clicking on the name.

We have more than one site related DWG for each project to align within Revit. We used Acquire Coordinates on our benchmark file. When all the related DWG files share the same WCS origin we can tell Revit to use By Shared Coordinates when linking them.

An obtuse but factually correct message appears telling us the files don't share coordinates.

Aligning the file based on its WCS is precisely what we want so each of the files align in Revit, possible, again, because we used Acquire Coordinates on the benchmark file first. That aligned the Shared Coordinates with it so the other files could stack on top of each other properly when we linked them.

There are many subtle things that can affect the linking process with DWG files, add this to the pile.

Shared Coordinates - Autodesk Reference Information

It's September already...no posts in August...time flies.

This post is brief, merely a referral. If you struggle with understanding Revit's coordinate system then THIS LINK, at Autodesk's Knowledge Base (KB) site for this subject might be helpful. I like the images and some of explanations or interpretations it offers.

Check it out, it may help!

Edit: I wrote this on Sept. 7th originally, received an unflattering comment about it, returned it to draft, revised it, and restored it to published on Sept. 14th.

I was lazy. I thought the information was an addition to their formal help documentation. When I saw the comment I read through the KB article again and realized that it was written by an Autodesk User Group member and submitted to their Knowledge Base system, which happens to be curated by different people than the product documentation group. I might quibble with some subtlety of it here or there but its approach may help someone get a grasp on the bigger picture. Just keep in mind that its claims are not gospel, nor written by Autodesk's own people.

20 Mile Threshold on Import

This is a follow up to my earlier post this week regarding the 20 mile threshold. A comment to that post mentioned that the governing extent is equivalent to a 10 mile radius sphere whose origin is at 0,0,0. In my own testing I've observed the threshold is more closely defined as a cube.

This image is a 10 mile radius sphere with a line segment that travels beyond the edges of the sphere but within the boundary that a cube would have.

You can see the highlighted square is the extent of the DWG file and line extends outside of the sphere at each end but is still inside the boundary of where a cube would lie instead.

This image is the same file but the line is altered to extend beyond the edge of the sphere/cube extent.

This is the message that appears when I reloaded the file after altering the line's extent.

The warning can be avoided if we ensure that the DWG file doesn't have any elements that extend beyond the 20 mile cube (10 mile radius). The cube can be quite far from the origin of the DWG file but nothing can be outside the cube's boundary.

Publish Coordinates and Inter-related Linked Files

I frequently have models that are organized in/by what I call a Master Site model/file. This file is the Parent in the shared coordinate relationship for all the children/siblings models/buildings that I link into it.

When model positions are changed in this parent file I find it is sometimes (often) necessary to use Publish Coordinates on all the linked models, even those that have not been altered. I've observed inconsistent results where sometimes the location of a linked sibling does not adjust (update) when viewed (as a link) within another sibling model. Using Publish Coordinates seems to force these linked files to refresh properly when a model is opened, even though it might seem unnecessary for those that didn't change.

As such, it is possible that seeing other linked files appearing to be out of alignment for this reason may motivate us to try to reset everything. Pause, breathe...try using Publish Coordinates on all the links first.

Multi-Discipline Shared Coordinates

In the past I've written that using or invoking Shared Coordinates is not required to keep project files aligned with each other. It only becomes an issue or necessary when each discipline's files are expected to align with models that are produced with software other than Revit and then viewed with other software like Navisworks.

It's my observation that the most common reason for invoking shared coordinates is trying to orient models with the site conditions. Civil and survey data doesn't come from Revit so that practically guarantees that the architectural model will need to deal with shared coordinates. It's only slightly less guaranteed that the other trades have to deal with it.

I briefly dealt with (a short summary) the inter-disciplinary relationship before in the second of these TWO POSTS and it's reasonable advice until the architecture team has to move their model again, relative to the site model. The Master Site and Building Model linked file strategy I prefer becomes tedious when the building has to be relocated; tedious more so for the other trades remaining aligned with the architecture model that is.

The root issue for this tediousness is the Acquire Coordinates tool. Once the trades use it on the architectural linked model any changes to the building location don't propagate to the trade's models well. The position of the architectural model shifts being respectful of the shared coordinate relationship instead of ignoring that and remaining in the same position based on the Project Origin, the way it was linked to begin with.

Coping with this tediousness, we can fix the alignment of models after the building has been moved by taking these steps:

• Remove the architectural link
• Reset shared coordinates
• Link the architectural file again
• Use Acquire Coordinates again

Alternatively the trades can avoid using the Acquire Coordinates tool in the first place. I did write about this in another POST before. It is a long post, and mostly words, so I'll take another run at describing it here with some images too.

The most important thing to do is mark a known location in the architectural model so the trades can adjust the location of their own Survey Point and then use the Specify Coordinates at Point (SCaP) tool. By known I mean, the North/South and East/West coordinates based on the survey data.

When the architecture model is relocated on the site the new Survey Point information needs to be captured to pass along to the team. In the images that follow I've used the same model (Tiny House) I used in the posts I provided links for at the beginning of the third paragraph.

In the following image we see a first pass at the location of Tiny House A. This image is taken from within the Tiny House A model after having used Publish Coordinates on it from within the Master Site model. In Tiny House A I opened the Location Weather and Site dialog to capture the rotation of the model (wrote it down). The coordinates I'm using are based on coordinates defined or determined in the survey by looking at the corner of the property boundary. In this example I made them up so the coordinate values were easy to remember.

Imagine now that the HVAC designer has already linked the architectural model into their own project using positioning option: Auto - Origin to Origin and started working.

The reference plane cross-hairs you can see under the Survey Point in the image that follows are in the architectural model. That's what I used to mark the corner of the survey's property boundary so I'd be able to tell the HVAC designer where that location is. Yes, I linked the Master Site model into the architectural model so I could see that location to mark it.

Earlier while preparing to start work they moved their Survey Point (un-clipped) to the intersection of my reference planes. Then using the coordinate values and rotation information I also sent them they use the SCaP tool to define the shared coordinate relationship it should have relative to site and the building (see following image).

In this case we also need to enter the elevation of 20'-0" because the building has been raised that much in the site model. Keep in mind that we will find that the building and HVAC model both are still at the project elevation of 0'-0". The shared coordinate relationship is where this elevation is defined.

Now we need to imagine that something caused the architecture team to decide the building must be in a different location. The model was moved in the Master Site file and its new location saved when prompted. Now I've opened up the Tiny House model again and I can see where the Tiny House is. I capture the rotation values like I did before. I moved the Survey Point (un-clipped) even though it wasn't necessary. I do need to move the reference planes to mark where the common benchmark is located now.

I've posted the revised building model for the HVAC designer and sent them the new rotation information. The coordinates of the benchmark remain the same...the site hasn't changed after all, just the building's location relative to the site. Using SCaP they enter the new information after moving the Survey Point (un-clipped) to the intersection of the reference planes.

From all three models (architecture, HVAC and site), I've exported NWC files from Revit for use in Navisworks to see how they line up. In the first design iteration they were all on the other side of the site and in this image I can see they (building and HVAC) have moved together to the new location. I've hidden the wall and roof so the duct is visible. The green sub-region is just to mark the property boundary.

If the design requires the building to be moved again, once it has been moved in the Master Site file it is just necessary to repeat the adjustments I've described. This way each discipline's models stay aligned with each other based on using the positioning option: Auto - Origin to Origin.

A summary of the process:

The architecture team is in charge of positioning and they:

1. Create Master Site
2. Link Building
3. Position, orient and elevate the building (or Reposition)
4. Publish Coordinates (or Save Change)
5. Identify a bench mark in the building model (or adjust to mark new location)
6. Capture (record) and then provide coordinates and rotation/bearing information
7. Share model with trades

If the building location has to be changed repeat 3-7 (differences noted with parenthesis).

Trades take the following steps:

1. Link architecture model using Auto - Origin to Origin
2. Place un-clipped Survey Point at agreed upon bench mark
3. Enter Coordinates and Rotation (bearing) using SCaP

When building is moved on site trades repeat steps 2 and the rotation part of step 3. Remember to use/specify Shared Coordinates when exporting from Revit.

It is important to note that ALL of the above is biased for separate firms managing model relationships.

When all the trades work in one firm the Acquire and Publish Coordinates tools work better because all the files belong to us and we have concurrent access to them on our network. This allows us to link trade models to the architecture model and then use Publish Coordinates to pass along the information we have to manually keep in sync using the approach described above.

In the single firm the process and position logic can play out like this:

Files:

• Master Site > Acquire Coordinates from Site/Survey
• Master Site > Publish Coordinates to Architecture Model
• Architecture Model > Publish Coordinates to Trade Models

Positioning:

• Master Site - Survey positioned using Auto - Center to Center
• Master Site - Architecture Model positioned manually
• Architecture Model to Trade Models positioned Auto - Origin to Origin
• Trade Models to Architecture Model positioned Auto - Origin to Origin

Selection Box and Linked Models

I was just thinking that it seems unfair that the Selection Box (reasonably new feature) goes to sleep when you select just a linked file. Maybe I want to crop the 3D view down to just that link? That's when I realized that I happen to have a scope box around the link already. Select the Scope Box and then use Selection Box - et voila!

Yeah, I'm writing as if I didn't just go two months without so much as a by your leave...things have been...hectic, yeah. That's my story...

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.

A Case for Worksets - Opening Linked Files

It is common to choose to avoid enabling Worksets when we don't need to let more than one person access our project at the same time. If we rely on using linked files then we can benefit from not avoiding them. For example, if you've ever wanted to open a linked file at the same time as the file you are currently working in you've seen this warning message.

Revit doesn't like opening a linked file in the same session, without unloading the link in the current model first, but it won't mind doing so if you open a second session of Revit. Revit uses separate memory allocation for each session. That means it isn't possible to use Copy to Clipboard with Paste Aligned when we are using two sessions. If you let Revit unload the link instead you won't see any changes in the host project until you save, close and reload the linked file. A good many users regard that cycle of steps to be annoying.

When we enable Worksets we have a Central File but work in a Local File. If all the project files we use have enabled Worksets then when we open any of the Linked Files we are creating a new Local File. Here's the tricky part...technically that's not the SAME file we Linked. The Linked File is (should be) based on the Central File (it's name and location)...the Central File is linked, not our Local File.

Yes this means you can now open a linked file in the same session of Revit. You can make changes in either file and use Synchronize and Modify Settings to store the changes in the Central File(s).

Now before you get too excited, you still have to use Reload on the Linked File that's been changed. That's not really any different than having another user making changes to the Linked File and having to use Reload to see their changes. It does make it easier to go back and forth between models quickly; eliminates the open/close part. Eventually you have to use Reload to see any changes regardless.

If you are a sole user and still intimidated by Worksets; just remember you only have to have one Workset for it to be enabled, for Revit to work. Revit creates two default Worksets for us to use (Shared Levels and Grids and Workset 1) but we don't have to be too concerned with assigning elements to any but Workset 1. That's assuming we don't really need Worksets for its fundamental purpose; allowing concurrent access to the same data by more than one person.

Something to consider if open/closing and unloading/reloading links is annoying.

Oh, I should mention that this starts to disintegrate if you are opening more than two files that are inter-related, linked into each other. For example, imagine a Host Model, Linked Model 01 and Linked Model 02. The Host Model has linked both of the linked models. If Linked Model 01 is also linked into Linked Model 02 and we then open both of them as well as the Host Model we will encounter this kind of message when we make changes to Linked Model 01 and then attempt to reload it in the Host Model.

The file in question is also present in the other open Linked Model and that is what Revit is objecting to. We'll also find that the file is unloaded automatically. We'll have to close the other file that it is visible in before we can successfully reload it. As such my habit is to limit my use of this technique to two open files at a time.

Clearance Subcategory in Linked Files and Families

You've linked a model that has families which include clearance elements. That's excellent for doing clash detection. However you may not really want to see the graphics they've provided for this in all of your own documentation views.

Hopefully the clearance elements have been assigned to a unique subcategory that you can control by overriding the link's Visibility/Graphics.

If so and you'd like to control the subcategory without overriding their linked file you can use Copy to Clipboard on one of the families (TAB to select it) with the clearance elements in them. Then paste a copy somewhere in your model. Now the family's subcategories are part of your own model. You'll be able to control it via V/G without overriding the link, assuming the link is assigned to By Host.

You probably realized that doing the above is a shortcut to creating a matching subcategory assigned to the correct category in Object Styles ourselves. It is a shortcut because we probably won't know what subcategory the family is using without examining the family more closely, by opening the linked file and editing the family directly. Using Copy and then Paste provides us with a copy we can interact with directly instead and any subcategories it has are brought into our project for us.

Families are prone to inconsistency because they can be obtained from a variety of sources. Consider that even the families from Autodesk aren't entirely consistent from one to another. It may still be necessary to crack open a family to find out how their clearance elements are controlled. For example, the lines that form the "X", and the "box" around them, in this family are assigned to the Hidden Lines subcategory, not Clearance.

In 3D there are forms to indicate clearance requirements and they are assigned to a Clearance subcategory but they also have their Visible parameter unchecked which means we can't see them in the project at all, anywhere.

This family does not intend for us to turn off the clearance "X", at least not via its Clearance subcategory. It has a subcategory called clearance and the solid forms for its clearance zones are assigned it but then it was decided they shouldn't be visible at all. By the way, doing so does not prevent Revit from seeing the clearance forms when using its own Interference Checking. However in Navisworks they don't show up. That might be considered bad form (pun intended). From a family editor perspective (and user), it would have been more flexible if the Visible parameter had been associated with a Yes/No parameter to allow us to turn it on or off if necessary. Unfortunately, keeping in mind that this post began about families in a linked file, it wouldn't make any difference for us.

Consistency is easier to manage and achieve when it is your own content library and your project files. It can be a bit trickier dealing with the content that is part of the linked files you need from other disciplines. It's easy to create a family that makes me happy, or my team. It may not make the other consultants happy though. Something to think about while you're being happy making content.

Feature Request - Tell me Link Files Have Changed

Working with a group of people today several echoed a request I've heard quite a few times over the years. They'd like Revit to let us know when a linked file (Revit/DWG) has changed so they know to use Reload to see the changes. The precedent for this idea is...yeah AutoCAD.

I suspect that it might negatively affect the user experience when Revit pauses to check for changes, assuming it can't be done as a background process (or multi-threaded). In that case I'd prefer Revit stay nimble and leave it up to me to decide when to check for changes. If it could be done without harming performance then I'd welcome it too.

Something for under the Xmas tree...

Revit 2016 R2 - Positioning by Auto - Project Base Point to Project Base Point

This is an interesting development for reconciling the misalignment of models. This gives us the option of linking a RVT model according to the location of its Project Base Point (PBP) and aligning it with our own.

Let's imagine a scenario where our structural engineer decides to mock-up a preliminary model but does so without the benefit of having the architectural model linked in yet. This new feature allows the engineer to either move the PBP un-clipped (see warning below) to an agreed upon grid intersection or to start by placing their grids at the default PBP location in their model.

All I have to do to get their model to align with my model properly now is make sure I move my PBP un-clipped (again see warning below) to our equivalent grid location or be grateful I was lucky to have guessed that we'd start our grids at the same location to start with. If I didn't guess correctly then moving it un-clipped puts it in the correct location and the link lines up nicely.

Being able to move the PBP un-clipped is helpful for Revit to Revit alignment. It DOES NOT address exporting to DWG however (nor appending to Navisworks). If each model is exported using Coordinate System Basis: Project Internal they will not line up with one another because the model's file origin is not altered. If each trade is careful to start modeling the agreed upon grid intersection at their templates's default PBP location (not moved at all) then they'll line up when their exported files are opened in AutoCAD or Navisworks.

I'm not sure we can rely on that if we can't count on them waiting for our model to use as a linked reference first? Still it is an interesting development. Hopefully it doesn't just contribute to the existing confusion regarding linked RVT file positioning.

My recommendations?

• Make sure all trades agree to begin their work referencing their own PBP with the same understanding. For example, agree in advance that the bottom left grid intersection shall occur at the PBP location (like shown in my images). This will ensure that exported data will have the same file origin.
• Don't move the PBP un-clipped to reconcile the PBP location IF you want to be able to export using Project Internal.
• Only move the PBP un-clipped if you will rely on Shared Coordinates to deal with external model alignment in other applications.

Filter Linked Grids and Levels

As soon as we rely on or need to use linked files we are confronted with the presence of their grids and levels. Some people use Visibility/Graphics to interact with the linked files and override them so they can shut them off. I like using a Filter for each instead.

Since I have control over the naming of my grid and level types I can make them unique enough that it is unlikely to compete with the naming used for those that are in any of the linked files. Naturally, the last thing I want to attempt is to get the other trades to align their grid/level names. It's a lot easier to just deal with my own naming.

For example let say there are four linked files; Structure, HVAC, Plumbing and Electrical. They all have grids and levels that use different names. As long as mine are distinctly different from theirs I can filter them all off with one filter for grids and another for levels...since I may want to restore one or the other at times, separately.

Here's the Filter dialog configured to filter out all Grids but mine; I called it Not Local Grids. My Grids have a type name prefixed with AEC, but a firm's own acronym or something else that makes it unique works too. This can change from project to project easily too...if necessary.

Now I just add the filters to my View Templates and all the views that are going to get put on sheets and printed will behave with minimal input from me here on out. For coordination I'll use working views that don't have the filter applied or temporarily override the view template so I can toggle either of them on if necessary.

Here's a bonus Filtering tip that was shared at RTC (sorry I don't recall whose session it was). If you are filtering with a specific criteria but can't recall if the first letter is capitalized or not just leave that letter out. For example if you aren't sure if it is Concrete or concrete just enter oncrete as your critera. Pretty subtle and clever!

Worksets for the Small Project

It is not uncommon to hear that people who are able to work on projects alone choose to ignore using worksets. Choosing to avoid adding any unnecessary complexity to the experience is one reason I hear. Another is, "Worksets are only required (and therefore useful) when people have to work on the same model together at the same time." It's true, I have written as much.

If this person is you, there are a couple of subtle benefits you might want to consider.

1. Opening inter-linked files in the same session
2. Selectively loading worksets while opening the file

Regarding #1 - It is not uncommon to work on projects alone and have multiple buildings involved. Revit does not like it when we choose to open a file that is already linked and loaded in a model we already have open. We get the message that the file needs to be unloaded first.

One way around this is to open more than one session of Revit. Each Revit session uses a separate Windows Clipboard, in memory set aside for each session of Revit. That makes it harder to use Copy/Paste to pass things back and forth if necessary.

If we use Worksets instead we are working in a Local File. We link files based on the central file though. The consequence of this is that we can open any number of other linked files in the same session of Revit now because we'll be opening a Local File, not the Central File. Revit doesn't object to that condition. NICE! It's enough reason for me to enable Worksets on every project, at least every one that will be involved in linking with other RVT files.

Regarding #2 - Choosing which worksets to open when we open a project is quite helpful because we can be creative with worksets and linked files and find ourselves able to choose which linked files should be opened too. Otherwise we have to wait until the file opens and then use Manage Links to Unload them or frequently use Visibility/Graphics to turn them on/off as required.

The trick is to create a unique Workset for each linked file we'll be using. Then we can choose which one to open when we open the project itself, demand loading of linked files via Worksets...since we can't manage links until the file is fully opened and all links are loaded. It starts here when you open a project (see image below).

When Revit begins to open the project the first thing it will load is the Worksets dialog which will give us a chance to decide which of them should be opened or closed. Anyone who has worked on projects with several (or many) large linked files knows how each file increases the initial opening time required for a project. Why put up with that at all?

Have I convinced you to give it a try? I hope so!