Insert From File and a Worksharing File

I bumped into a subtle conflict this evening. I created a new file from a stock template. I then used Insert from File > Insert Views from File to acquire a few drafting views. When I closed this new project and decided to open the file the harvested drafting views are stored in this message appeared.

Keep in mind that no files were actually open at the moment. I was looking at the Recent Files list yet when I attempted to create a new local file for the project I just used Insert From File on the message popped up. This means that the file is technically still open in RAM as far as Revit is concerned, it's just not open for me to interact with.

I had to exit Revit so it could relinquish its hold on the file before I could start Revit up again to get back to work.

Load and Place a Family

Perhaps it isn't obvious enough but Revit is designed to deal with loading and placing a family according to context determined by our actions. Did we start a placement process or an admin process?

The component tools like Door, Window, Component, Detail Component, Air Terminal and so on provide Revit with placement context. The Insert ribbon tool Load Family is an administrative task which does not presume placement as a priority.

IF we start the Component > Place a Component tool first. Choose Load Family from the ribbon. In this context Revit knows we intend to place something but using Load Family tells it we need something that isn't already loaded in the project yet. If we choose to load multiple families it is ambiguous to Revit so it chooses for us which family to offer as the family to place now.

When we use Insert ribbon > Load from Library > Load Family separately it is regarded as an administrative task, i.e. "I need to load some things so they are available to everyone." Personally I have had many situations where I need to load families in this way, not place them immediately. If I do want to place a loaded family right away then I start the Component (or Door, Window etc.) tool first.

The Family has been Renamed

This warning message is probably familiar, troublesome and annoying.

I was reading a couple threads at RFO; THIS ONE and THAT ONE.

Apart from workset related issues I've written about before, I believe the underlying cause of renaming is that Revit perceives a family as different. That's not very surprising but I think that the actual difference is the result of different versions (2016 vs 2017) or having Save As used on the family (to put it in a different folder)...AND any operation that involves Copy/Paste, which includes the Insert from File tools.

When Load from Library > Load Family is used I only see it occur when worksets are being used (see the links at end of this post). The families merely having some different parameters (either instance or type) generates the dialog asking how we want to deal with the existing definition.

Using Revit 2017.1 and passing a family from one project to another I observed the following:

Family is renamed but no warning message:
If the family being introduced is an older version (upgraded) of one already in the model
If the family is same version but has had Save As used on it, i.e., to put it in a new folder location

Family is renamed and the warning appears:
If the family is an older version or Save As version AND Insert from File is used

Family is not renamed:
If the Family is copied from same library folder to a new folder
If the Family is from the same library folder
If the Family (existing) is reloaded from older version before using Copy/Paste or Insert from File.

The issue can be avoided if we are meticulous about using families from the same library and version. If we load office details from a detail library project file using Insert from File and the families (some or all) involved are based on older versions while newer versions are already present in the project we'll incur the renaming penalty.

The detail library should be updated, have the newer versions loaded first so they will be the same as those in the active project. If we need to keep the detail library in more than one version then we'll have to decide how to manage that and for how long. Merely upgrading the detail library model does not appear to be sufficient to avoid the issue.

I ought to mention that I can load a family and let it upgrade. Then if I use Copy/Paste to pass it along to another project file it does not get renamed unless the existing family in that project is based on a different version than the one I just upgraded. Upgrading a family does not seem to create the same problem that using Save As does for a family, at least not in the context of Revit treating it as a rogue family competing for the same name/existence in the project.

Regarding the workset issue I wrote three posts about previously, they describe how families can get renamed when worksets are being used and more than one person loads the same families and synchronizes their work in a specific way. The posts are:

FIRST post
SECOND post
THIRD post (references the first two as well)

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.

Revit Viewer and Worksharing

Reading a thread at Autodesk's Revit Community forum David reminded me of the quirky issues related to the Viewer when worksharing is being used. If someone launches Revit Viewer and then tries to open a project that has enabled worksets they'll get this warning.

When the file is opened and they try to print, export or save they'll get this warning even though they haven't DONE anything...but Revit has made changes to the file in order to create a new local file.

Okay, let's follow the instructions in the first warning message. We'll open the project using Detach from Central. Sorry, "Do not pass Go, do not collect $200". That process also changes the file. Still no export, save or print for you!

The ONLY way we can use Revit Viewer to open a project with Worksets enabled is to open the Central File itself, by un-checking the option to Create New Local. This means that user is now working on the real central file with Revit Viewer.

If you do this you will likely encounter several of the messages shown in the first image. The projects I've done this with all have linked files and it seems to pop up for each link (RVT) used and once more if there are any linked/imported DWG files.

To the good, they won't be able to synchronize their work nor will it prompt them to Save when they close the file. They won't be able to edit much of anything though because they can't borrow elements. The notion of using Revit Viewer to poke around the model, do some experimental stuff within the model is off limits to Viewer mode. We are able to print or publish to DWF, because those formats don't create an editable version of the data/model.

It seems to me that the notion of Revit Viewer for workset projects is fundamentally flawed, if we're thinking of it as a way for Project Managers to poke around, do anything other than JUST LOOK at views. If we'd like them to be able to cut a section view or hide things, do anything that requires temporarily borrowing something, that's all off limits to the Viewer.

For that we'll have to show them how to use Detach from Central AND to be careful not to save that file overwriting the original project.

Open Sheet - Equal Rights for Panel Schedules

This new right-click choice exists, within the Project Browser, for views that are on sheets. Views that are real that is. Schedules are special views, they can be placed on more than one sheet (like Legends). Electrical Panel Schedules share this distinction but unlike other schedules they are not nearly as likely to require being placed on more than one sheet. Their schedule-ness makes this right click option invalid for them too.

I realize it probably isn't easy or perhaps even possible to segregate this schedule-ness from Panel Schedules but I would have found it very handy to be able to use the Open Sheet concept for them several times today. In this instance it would have been faster than navigating through a very long list of sheets. I suppose it is also possible that some firms do need to be able to put Panel Schedules on more than one sheet, in which case...bummer for me and my wish...

Getting Started with Collaboration for Revit (C4R)

Below are a couple of links that describe the process for getting your project started using Collaboration for Revit (C4R).

It all begins with creating a project using your A360 account/subscription. Naturally you've got to create an account first so this assumes you've done that. The linked page also explains how to upload your current project to the A360 project if necessary.

If you're responsible for putting your active file on the A360 Project, READ ME, it has a video too.

There is a ton of information lurking at Autodesk, just use your Google-fu.

Revit 2017 - Enabling Worksharing

The process for enabling worksets has changed with this release because Collaboration for Revit (C4R) has been incorporated into Revit directly. This allows someone to subscribe and begin using it quicker. They might even be able to do so without any (or much) EyeTee intervention.

The first evidence that there is something different is on the Collaborate ribbon tab; there is a Collaborate button next to the disabled Worksets button. There is a new Communicate panel too.

In the past enabling worksets began with clicking on the Worksets button but now we start by clicking on Collaborate. This takes us to the fork in the road necessary to permit sharing the project via A360/C4R whether we are able to use it or not, just in case. If the file hasn't been saved before clicking Collaborate we get a message asking us to do that.

Then the Collaborate dialog appears asking us to specify which method of sharing the project we need; Collaborate within your network or Collaborate using A360.

When we choose Collaborate within your network Revit enables and creates two User-Created Worksets called Shared Levels and Grids and Workset1 (like in the past) but it doesn't open the Worksets dialog (like it used to). This allows us just to get on with our work using the Active Workset (Workset1 by default). If we need to create additional worksets then we'll find the Workset button is enabled, just click it to open it (Workset dialog, as in the past.

The Communicator button is tied to using C4R. It is a separate window (dialog) that can display information about your project team activity, if you're sharing the project using A360. Imagine concepts from Worksharing Monitor combined with Instant Messaging features and that's what you've got. FWIW, it used to be able to dock inside the Revit UI but it doesn't do that now. If you've got two or more monitors you'll probably prefer it on one of them instead anyway. This is what it looks like if I'm not logged into A360 and not using it to share this project.

At some point we'll need to Save the file and like in the past we'll be warned that this is the first time we've done that since we enabled worksets; click Yes.

Remember, if you'd like to set the default Open option to Specify remember to use Save As instead of Save. You only get a chance to do that with Save As. This allows us to choose which Worksets Revit should load before it opens the project entirely. This can have a significant impact on how long it takes to load a project.

At this point we are still working in the Central File, which isn't practical to share the project nor is it advisable. I can determine that by looking at the Save icon on the Quick Access Toolbar (QAT), it is disabled and the Synchronize and Modify Settings button next to it is enabled. The project's file name listed on the Title Bar doesn't include my user name either. By the way, we need to SwC to relinquish our ownership of the User-Created worksets properly. The only way to do that is to use SwC (Synchronize and Modify Settings), via the dialog that appears. The Synchronize Now button does NOT do that.

Now that worksets are enabled and relinquished we need to close the project so the team can get started by creating their Local Files. When I browse to the Central File to start work I need to make sure that Create New Local is enabled and double check the Open option is assigned to Specify.

Remember doing so will cause this dialog to appear before Revit begins opening the project further.

Okay, now get to work; in your Local File!

Did you Load a Family - Synchronize NOW

ALWAYS use Synchronize with Central (SwC) immediately after loading new families or types (or duplicating system family types). Don't place any instances until you have!

This post is tagging on two earlier posts on the subject of loading content, restating the punch line to emphasize it on its own. If you're inclined to just take my advice just reread the first two sentences and behave accordingly. If you're a bit curious, need more convincing, you can read the FIRST and SECOND posts for more background info.

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.

Copy Monitor Wall Location Line Selection

I mentioned in a previous post that 2016 quietly introduced a parameter that lets us choose which Location Line is important to reference when we use the Copy part of the Copy/Monitor features.

Now that I've been trying to use it regularly I'm running into a quirky situation since installing R2 (I can't say for certain it doesn't happen in the previous version too). When I select a wall it works on the just the first wall. When I choose additional walls I get this warning.

Initially I thought it was happening because I thought it is important to assign the Location Line of the walls in the source linked file to be the same as intended in the host file, but then I don't remember having to worry about that earlier...pause...

Then it occurred to me that whatever Location Line setting I used for the last wall I sketched, in the host model, might somehow influence the process. I tried that and I don't think that matters at all; and it shouldn't in my opinion.

After experimenting a bit further it only works reliably when I use the Multiple selection option to choose all the walls I want to use Copy/Monitor on. I've repeated this using stock content (Imperial) and Architectural and Structural templates. If you'd like to corroborate my findings please try these steps:

• Start a project with the Architectural template
• Create six walls with: Basic Wall Exterior - EIFS on Mtl. Stud
• Use Location Line: Wall Centerline
• Save the file as Test CM

• Using the Structural template link Test CM
• Create a Stud 2x6 wall type (6" because the stud layer in the linked wall is 6")
• Start Copy/Monitor
• Map the linked wall type to the host's Stud 2x6 wall type (in Options)
• Choose Location Line: Core Face: Exterior (in Options too)
• Start Copy and select one wall (no message)
• Select another wall (Error message yes?)

I suspect the nature of wall joins is affecting whatever method they are using to evaluate the wall for the C/M process.

• Use Undo and Start again before using Copy/Monitor
• Set Options again, just to be sure
• Start Copy
• Select Multiple
• Select all six walls
• Click the little Finish button (no error?)
• Click the big Finish button

Earlier I mentioned being concerned about the Location Line setting of the walls in the linked model. I tested for that by starting with walls in the linked model assigned to Location Line: Core Face: Exterior. It didn't make any difference in my testing (see next image). Fwiw, when I first saw this new option appear I did think that was what they intended us to do but Revit just places our version of the wall according to the chosen Location Line position, not according to what the source wall is actually assigned to.

Thinking about it further I realized that if we really could influence this by changing the value in the linked model it should have already been easy for us to use C/M; if they just allowed us to swap wall types based on their setting. Revit was biased to only use Wall Centerline, ignoring the others.

I was nearly convinced that all I had to do was make sure to select the walls using the Multiple option but then in another file it didn't seem to matter or help regardless. Then I noticed any wall I was successful using C/M on (picking them individually) but was touching a wall that generated the error message also needed to be eliminated so I could start again clean. When I used Multiple after getting back to a clean slate I was able to use Copy/Monitor without an error message.

I conclude that the safest way to ensure Copy/Monitor doesn't generate a confusing warning is to isolate all the walls we want to use C/M on and choose the Multiple option. Remember the little Finish button before using the Big Finish button!

Also remember that anytime C/M gets ornery we can just use Stop Monitoring on the affected elements. Fix the problem elements and then use the Monitor part of C/M to let Revit start watching them again.

Revit Schmevit

Plan, Section and Elevation...the bread and butter of architecture. Why would anyone want to work on these three kinds views of a project and not find that the elements (doors, windows, walls, etc) they present don't match? If I create an enlarged plan shouldn't it match the plan it was generated from, but have greater detail? Shouldn't the windows called out in a plan match those called out in an elevation? Even if you get it perfect at the first submission I guarantee you'll miss stuff when the next design submission is due. By the time you get to the fourth...faahgeddaboudit.

BIM... I don't care if you ever learn what those three letters mean...

PLEASE, in the year of Two Thousand Fifteen, finally abandon your disconnected ways and use Revit (or ...Archicad).

Seriously, because the people that have to read your drawings aren't impressed.

Survey Point - Post 3 - Five Minutes with Shared Coordinates

I created a video that goes through the process I described in the previous two posts. It is set to a four and half minute song by Michael Lee Firkins called "The Window". If you've never heard his music I believe you owe it to yourself to check him out, very talented and unique sounding guitarist and song writer.

Survey Point
Survey Point - Post 2

Detach from Central versus Save As - Make this a Central Model after Save

Both techniques allow us to create a new central file from an existing file that has enabled worksets already.

Save As - Make this a Central Model after Save - respects the Edited By information the project has stored. This means if other users have borrowed elements then you'll find those users among the Owner/Borrower column in the Worksets dialog after creating your new central file.

This distinction means it may be possible (though unlikley) to allow users to synchronize their work with the new central file. They'd have to use the Browse button in the Synchronize with Central dialog to point Revit to the new location of the central. I used italics on may be possible because there are so many variables that could prevent it from succeeding that I don't want to provide false hope. If people have not continued to alter or create new elements in their own local files, while this new central file is created, then it may be possible, worth attempting perhaps if you are in some sort of recovery mode.

Detach from Central - completely severs the relationship the file had with the file it came from (usually a central file) and any local files that may exist, as well as ALL ownership information (stored in Edited by parameter). It is a fresh start, utterly.

Btw, this post was prompted by a question at RFO this afternoon. It became evident that this subtlety is something I've not written about, I thought I had.

Revit MEP - Piping Offset from other Elements

When we sketch a wall we can provide an offset value on the Options Bar and then use the Space Bar to flip the side of the reference points we provide during sketching.

That flows pretty well (pun intended). It's not so fluid when using the Duct and Pipe tools. The Offset feature is hiding in the Justification Settings dialog AND the Space Bar concept doesn't work. We have to provide a negative value or be careful to start sketching in a specific direction to get the opposite offset.

This makes sketching pipe with a specific offset value relative to walls and other elements tedious. I think it is very likely (even much more so) to want to create pipe and duct taking into account adjacent elements like walls and structure AND provide an offset while doing so...it would be a lot more fun if there wasn't this extra little dialog hassle to do so.

Gray Inactive Worksets

This feature is often overlooked but it can help ensure you are setting the Active Workset as you transistion between tasks. It is located on the Collaborate ribbon tab > Manage Collaboration panel and right underneath the Active Workset drop down list.

Let's say I need to start working on the interior partitions next. If I click to enable Gray Inactive Worksets it becomes more obvious that the exterior walls are still my focus.

If I change the Active Workset to Interiors then everything else becomes a light gray color instead.

Now all the interior work I do takes a visual priority compared to the rest of the model.

Such a simple yet easy to overlook feature, try to remember to take advantage of it.

Changing Column Types and Copy Monitor

Using Copy/Monitor Revit does not complain when we change column families or types. It does complain if the column is moved. This is different from other elements like grids and levels. My understanding is that the way they expected Architects and Engineers to use the feature is a little different for columns, something like this:

• Architect places schematic architectural columns (different from structural columns)
• Architect sends model to engineer
• Engineer uses copy/monitor to create structural columns where the architects schematic columns are
• Engineer sends their model to Architect
• Architect adjusts their columns to be masking only (unless they are left uncovered)

The disparity between column types is intentional because an Architect's needs for the column are often different, masking a structural element versus designing/engineering the column itself. It can also be argued that it would still be better to complain when the column family is changed or swapped for another type (size). Even if, as the Architect, I've shifted my focus to wrapping structural columns it is likely worth being warned if the structural column has changed.

To be warned requires me to have a copy of the column to monitor, which I'd prefer to avoid ordinarily. In general, I encourage Architects to remove their own columns (structural or otherwise, if they use them) in their model as soon as the Engineer is hired and they send them their structural model. Now the architect can focus on using walls to wrap columns as required by Design Development and Construction Documentation. I resist the natural temptation to have my own copy of elements if at all possible, striving to avoid redundancy. Using copy/monitor (the monitor aspect only) can still alert us to major changes to location of the grids/columns.

For now Revit doesn't complain if we change the columns, as long as that change isn't its position/location. If that doesn't fit our model view then we need to let them know.

I wrote this post in part because of a thread at the Autodesk Revit Structure online user group. I wrote this suggestion to work around the lack of warning.

Since Revit is sensitive to movement, we could agree to move columns that are changed like this. If the architect is redesigning a column they can swap out the type for a new type but also move it off grid by a specific value. This will prompt a coordination review when the file is refreshed in the other discipline's file. When they examine the column they'll see the change is more about the size than position. They can respond to the change and move the column back into position, which will prompt coordination review upon return. We could agree that such trigger movement would always be East to West and always a specific distance or something like that so each team knows what to expect.

Shared Coordinates and Worksets

Ordinarily we are not permitted to save changes to a linked Revit model. The lone exception is when we use Publish Coordinates. Any time we makes changes to a model that we've published coordinates to we are attempting to save a change to the linked file. For example when you publish coordinates for the first time you'll get this message.

When we get around to saving the host project file we'll be greeted with this message.

That message is the one that is indicates Revit is going to change data in the linked file. If this file is open by someone else already we'll be politely rejected, though the message is a bit oblique.

But then this message will likely appear right after you click Close for the previous message dialog.

Followed by a repeat appearance of the previous message, "Failed to open document". This means Revit couldn't save the change to the shared coordinates because the file is currently open (read only). This means to be successful we need to make sure nobody is working on the linked model, at least for long enough to let us publish or update the shared coordinate information.

When worksets are being used this changes because Revit can still reach into the file and interact with an individual workset instead, unless someone already is doing that. It is recommended to Import/Link a central file, not a local file. Users should not be working in a central file so it is less likely that publish coordinates will compete with someone. Local files are usually created on the user's PC. This means using Import/Link on a local file will likely fail to work for everyone on the team. We aren't usually mapped to user's computers for file sharing. Let's come back to worksets in a moment.

We'll get the following message when we decide to change the position of a linked model that we've previously used published coordinates on.

This gives us the opportunity to commit the change to the linked file immediately (click Save Now) or postpone that action till we are really done adjusting the link (click OK). Yet another message can appear if someone has changed the linked model since it was loaded or publish coordinates was used.

As the dialog suggests, Reloading the linked file will resolve the situation easily. If we are dealing with worksets again it is possible to have a similar message appear, related to the situation where other users have used Synchronize with Central recently.

This too can be resolved by Reloading the linked file, as long as we cancel the action. If we click OK then Revit will allow us to leave the modified linked file in its new position. After we reload the link Revit won't prompt to Save the new position, a quirky outcome. We need to use Publish Coordinates on the link again, we can just leave the location name the same to publish the revised data.

In the past we could find another user listed in the borrower column for the Project Information workset when someone used the Publish Coordinates feature on a linked file. With 2014 I find that Revit seems to be able to resolve this transaction more reliably. When I am working in my local file and another user publishes coordinates I don't find any other users listed against worksets in the Project Standards group.

To reliably publish coordinates to a linked model:

• If it isn't a workset project I need to
• ask any other user to save and close the file temporarily
• Reload the link (Insert ribbon > Manage Links dialog)
• Publish Coordinates 
• If it is using worksets I need to
• Reload the linked model (Insert ribbon > Manage Links dialog)
• Publish Coordinates

Foundations and Insulation Calculation

I got involved in a thread at RevitForum.org that asked about calculating the total bitumen insulation required to cover concrete foundation surfaces. The original post described using the Paint tool and how much time it took. I always wonder if people are responsible for the calculations or just curious whenever I read such requests. Sometimes I ask. Intellectual exercises might be interesting but they can waste a lot of time if the results don't actually get used by someone.

Since I put the effort into it already I decided to use this post to share the example project I created in response. I shared an earlier version in the thread but this one has more ideas expressed.

I'm inclined to try to use schedules and formulas to calculate/predict the insulation material required instead of using paint and a material takeoff. The Isolated Foundations (footings) have one form (most of them) so there aren't compound layers like foundation slabs, floors or walls.

It isn't as simple as just reporting all the surface area of each kind of foundation. It isn't even simple to do just that. The surface touching the ground doesn't get the insulation (my understanding in this situation). No insulation is required where a column sits on a footing so we need to subtract the column base area from the top of footing surface area. No insulation is required where a wall sits on a footing either.

We also have parameter inequity. Isolated Footings don't have a "thickness" parameter. Foundation Slabs and floors do. Inconsistent application of dimensional values is the sort of trouble we face when we use the provided family categories (as their naming/behavior implies we should) and try to compile their information using the "same" notion of dimensional criteria. They just aren't all equal, they don't have the same "beliefs".

My approach started out with a foundation schedule that includes footings and slabs, a schedule for walls and a third for columns. I needed to distinguish between footings and slabs so that I could create formulas to figure out the area for the top and sides of each kind of footing. Floors and Slabs have Default Thickness and Perimeter. When they are rectangular they also have Width and Length. If they are irregular they don't. Foundation footings don't have thickness but have Width and Length.

I used a formula to divide the Volume to arrive at an Approximate Height to use to calculate surface area for top and sides. I used a parameter called Is Slab (an integer) so my Bitumen formula could decide which formula technique applied. I just enter a 1 for slabs and 0 for footings. This is the foundation schedule for wall footings, isolated footings and slabs/floors.

As you can see I added some rows to the header to explain the empty cells in the schedule. I also added the formulas (after capturing the images) to the comments so it's possible to validate the results without having the model.

Here's the schedule for the walls. I've not resolved the overlap of walls onto footings or the walls and their own footings in the schedule above. I'd probably create another schedule for subtracting the bottom surface area of the walls, or if possible include it in this one.

And here's the schedule for the columns, I put the (-) in the header to make it a little more obvious that the area should be subtracted from the other totals.

You may already know that columns don't have a base width or length parameter that we can see in schedules. They have a type name but the parameters that govern their base dimensions are called "b" and "h", like the corresponding graphic in some structural design manuals I've seen. I added two shared parameters, Base Width and Base Length, to the column family and just made them equal to "b" and "h". That's probably the easiest way to resolve content that fails to use system parameters that are compatible with other families, as well as content that you download and find the same conflict between other content of the same category.

Assuming the approach above is completely uninteresting these are some possible alternatives we could consider.

• We can "paint" on materials and there is a Split Face tool which will work on floors, foundation slabs and walls but not structural foundations or columns. We can model all foundation elements as floors and/or foundation slabs which would make it easier to use the Split Face tool and then paint on the insulation.
• Use a combination of the schedules above and some use of the Paint tool and material takeoffs.
  
• We can create separate families for the insulation conditions that can be scheduled by themselves, or at least for the foundations that can't be "painted" with Revit's paint tool.
• We can build more complex footing families that have an additional form(s) for insulated surfaces and these can in turn be used to define them in a material takeoff, instead of a regular schedule.
• A talented programmer with the Revit API could take into account all sorts of permutations and generate a pretty comprehensive summary).

I've posted the project file if you'd like to DOWNLOAD IT. Happy insulating!

Light Fixture Grid Positioning and Wires

I've seen some lighting content that has been modified to make it easier to align with acoustical ceiling tile grid patterns. For example this stock family is the Downlight-Recessed Can.rfa with some reference planes added so we can snap to the grid during placement, or use the Align tool easily afterward.

I didn't bother to assign any parameters to control them. I can use them to fit the fixture in a 2x2 grid or use the Align tool later to position it in the middle of a 2x4 grid. It might not be obvious but I can use one reference in a family to move the family over by selecting another part of the family as my second pick. This means it is easy to just set the reference planes at a fixed position and use the family's own references to move it over if necessary. It just means I don't have to have parameters to decide if the fixture is meant for a 2x2 or 2x4 grid. All this is seems good at first except when it comes time to add wiring to the fixtures.

These helpful reference planes end up affecting where the wire's graphical ends terminate. The fixtures are connected to their wire but they just stop at the extents defined by the reference planes. Not fun when you have to adjust a lot of wires to get closer to the fixture. This means Reference Planes aren't ideal for this task. This is what the family looks like if I use Reference LINES instead.

I've held the same attitude toward adding dimensions in this example too, with much better results as well! We can set the reference lines to Strong (IsReference) and uncheck the Visible parameter. They won't be visible when you select the family but the Align tool will "see" them and Revit will highlight the ceiling grid pattern when you place the fixture too. Fwiw, if you leave it checked they still won't be visible when you select the family.

Fwiw, Model and Symbolic Lines that are Strong References and assigned to Invisible Lines provide the same result. You can uncheck the Visible parameter so they aren't visible when you select the family.

(This is based on working in 2014, it does not work in 2012 or 2013. Nothing seems to resolve it in those versions)