Topography Background Process - Can't Save

 Not being able to save a project because "background processing" is running is VERY dumb!

Phasing and Replacement Windows

Over the years people have often complained about trying to document replacing existing windows with modern windows but maintaining the existing opening. This means swapping windows with families that are the exact same size. This is related to the wall that Revit creates to infill a wall that has a demolished window. You may have encountered this warning message?

That message appeared when I attempted to place new windows in the New Construction phase after demolishing the existing windows first. I was careful to set up views assigned to different phases and phase filters so there wouldn't be any display conflicts.

I got interested in this issue again recently because of a thread at the Autodesk User Forums for Revit Architecture. A fellow member was sharing how much trouble Revit has been giving them trying to do this kind of work. After some back and forth I narrowed it down to one window family and another member realized that family uses a void to cut the hosting wall in the family itself versus the usual opening.

This led me to write some hypotheses for testing purposes. I wrote:

Hypothesis A: Within phasing we can replace Existing Window A with New replacement Window B using the exact same sizes (same size opening dimensions) IF they both use an OPENING in the family to cut the host.

Hypothesis B: Within phasing we can replace Existing Window A with New replacement Window B using the exact same sizes (same size opening dimensions) IF they both use a VOID in the family to cut the host.

If either of the above are false then...

Hypothesis C: Within phasing we CANNOT replace Existing Window A with New replacement Window B using the exact same sizes (same size opening dimensions) IF one uses an OPENING and the other uses a VOID, in the family, to cut the host.

I did some testing using the latest release of Revit, 2024.1 and I determined the following:

Hypothesis A is TRUE

Hypothesis B is FALSE

Hypothesis C is neither

I find that I can replace a Void based window with an Opening based window but not the reverse. Also any alterations to the hosting wall in the project; such as length adjustment, or top/bottom offsets, attach/detach will place the void type window at risk of being deleted. Weirder still is that it might not delete all of them, one or more.

It seems that the short answer is: eliminate window families that use a void to cut the hosting wall IF you intend to place identical sized windows in phased projects; to demonstrate existing window replacement without altering the existing openings. Windows created this way will not work for this task. A logical next hypothesis is to anticipate similar behavior in door families.

I speculate that this warning happens because an opening cuts fully through the host while a void (or combination of voids) might cut more and/or less of the host as it travels through it. I suspect that the infill wall can't abide the shape a void might create and that in turn means a void won't be viable as a window to alter the location of the infill wall. I think it's similar to curtain walls only supporting non-rectilinear panels with the system panel families.

I'd love to hear that the developers will test this against their own experience and expectations. I know that a lot of people rely on voids to shape the opening in a host wall to match a variety of actual construction techniques for openings. To eliminate voids in families as an option for this kind of project (replacement windows (and doors?)) is not ideal. They'd probably have to revisit the entire logic of infill elements where demolished hosted elements occur. Perhaps leave it up to us to fill in holes?

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 Warning Using Save not Sync

Lately we see this warning message appear, in BIM 360 hosted projects, when clicking the Save button (local) instead of the Synchronize with Central button.

It isn't happening for all models or all projects. I haven't isolated a cause yet and it shouldn't be happening at all. This is true for projects running in Revit 2020.2.3. Anyone else see this?

Create or Opening a Section View Crashes Revit

Have you encountered this issue (and/or elevations)? By crash I mean Revit stops responding, the blue spinning wheel of death. One cause I've identified is HVAC Zones. I've been able to resolve each on so far by deleting the related zone(s) and creating the zone(s) again. I haven't figured out what is going wrong with the zones. I'm just calling it corruption for now but I have no idea if it is something I can prevent or see first yet.

Happy to hear if any readers have encountered this situation too.

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.

Color Fill Calculation Failed is Back

This warning appeared quite a bit with Revit 2016 and patched in subsequent updates.

I've clicked Restart to no joy and I've submitted the error. I've done the Edit Color Scheme and Cancel process described for Revit 2016 with no joy either. Hopefully it will get sorted out again.

Moving a Viewport Error - Disjoin

The Move tool offers us an option called Disjoin. When it is used Revit deletes the original and creates a new element at the new location. That isn't obvious to us but if you examine the GUID (ID's of Selection) you'll find it has a new GUID after the Move is complete.

The option is sticky, we have to remember to disable it when we use the Move tool again. When we are working on sheets and adjusting views we now have an opportunity to run into a confusing error message.

If you run into this or people you support do, just remember to Disable da Disjoin.

Per a comment: My previous post on re Disjoin.

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...     

Move to Room - Element ID - Review Warnings

If we use Review Warnings often enough, and we should be, we'll run into this warning eventually.

Check the item and Click Show to have Revit try to find a view to show it in. Once it is selected we can either drag the Tag where it is suppose to go or Click the Show Related Warnings button on the ribbon to show the dedicated warning it has again.

When this warning is isolated like this the dialog includes the Move to Room button. An aside, is it amusing or worrisome that Revit seems to think the best way to fix warnings is to delete the offending element (via Delete Checked)? Regardless, Move to Room will resolve the issue whether we can see where the tag is meant to be or not.

Another way to tackle it from the Review Warnings dialog is to make a note of the Element ID referenced in the warning. Now we can then use the Select by ID tool. Enter the ID value and click OK.

This will select the tag, even if we're not in a view that it can be seen in, and then we can use the Show Related Warnings button on the ribbon again followed by the Move to Room button.

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.

Warning Message - Highlighted Elements are Joined but do not Intersect

Revit is telling you that someone used the Join Geometry feature on elements but now they no longer touch each other, intersect. When they were moved apart a warning appeared but the user didn't click Unjoin Elements (see image), they clicked OK so now Revit is keeping track of the joined relationship; doing what it was told to do.

If they/you/we do this enough we'll end up with a lot of warnings to review here.

You/they need to fix the problem, Unjoin the geometry, no warning anymore. The Warnings dialog even gives us a way to fix it, click Unjoin Elements. Fixing accumulated errors like this will improve performance. Please don't regard the warning as irrelevant, it's not!

Better still, avoid the problem in the first place, click Unjoin the first time the message appears instead.

Oh, I should also mention that clicking Unjoin Elements in the Warnings dialog does Unjoin them BUT it doesn't clear that warning from the list until you close the dialog and open it again. That's a little confusing.

Detach from Central and the Specify Worksets Option

When we use Detach from Central (DfC) this message may pop up from time to time.

It can be a confusing to see it because quite often the very notion of using DfC is to deal with the fact that the Central File has been moved or copied, like when a consultant sends us a copy of their project file. We use DfC to create our own copy of their project on our server and project folder.

My initial reaction to it is, "Yeah...duh...why do you think I'm using DfC Revit?" Well to be fair, the reason the message appears is that the Central File was saved using the Save As > Options... Open Workset default: Specify (see next image). Revit is attempting to open that dialog before actually beginning the DfC process (technically).

Taking advantage of this concept means that we don't have to remember to choose Specify Worksets when we open a project, it is the default choice.

This is one instance where cavalierly clicking Close, thinking yeah whatever...is okay.

Worksharing - Loading Content Part 2

In my previous post I recommended a point person be assigned to manage the loading of content for a team. That might sound like a beauracratic minded recommendation. Not me at all. It is more a matter of self preservation, wishing to avoid having to fix the resulting duplication before it becomes a bigger problem. As such there is a another minor measure we can take to help catch the issue when it occurs and fix it.

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

If we can't get a single person to manage this loading then using SwC immediately afterward will increase the odds that a warning message will appear as soon as the transaction is completed. This does assume that we all develop this habit. If the warning appears than we need to examine the new family(ies) and or type(s) in the Project Browser and resolve the issue.

The goal is to avoid creating the duplicates and even more importantly using them in the project.

Worksharing - Loading Content

I read Jason's post this morning and he describes a classic worksharing gotcha. Unfortunately he hasn't identified the true culprit. I'm referring to this part of his post specifically.

One of our most notorious examples is the infamous Break Line. Each drafting view we imported had a copy of the break line family. By the time anyone noticed, the project model had “Break Line (1)” through “Break Line (22)”.

What he describes is the result of worksharing and multiple users loading the same family in their own local files. Revit sees multiple versions of the same file being loaded from different local files (users) and seeks to protect them by renaming the other versions it encounters. We see this sort of message when it happens.

This error and situation is easy to replicate.

• Two users open local files for the same project
• Each user loads a new family and the same type
• Each uses Synchronize with Central (SwC)

The first person to sync will be successful without an issue but the second person will receive a warning about the family being renamed. If this is repeated enough, and by enough users at the same time, we could end up with family22 like he described.

For example, if eight people all introduce the same new family to the project then by the time the last person uses SwC there will be eight versions of this family listed in the Project Browser. This is what the Project Browser looks like after just two users think they both need to load a new double door and type.

Jason's post is focused on cleaning up after oneself and it IS important but it is also important to manage the loading of content and harvested details. It is equally important that people understand why these extra versions show up in the first place. Each time someone uses Load Family or Insert from File they must reconcile the warnings that appear before anyone has a chance to begin using the wrong version of the families that are duplicated.

I think it is worth restating that the subtlety of this issue is that this only happens when more than one user is introducing the same new family to the project (via their Local Files).

Once the family is part of the project (defined in the Central File) Revit doesn't get confused anymore. Here's what happens when I introduce the Break Line family he mentioned to the project via two users. Keep in mind that there is no Break Line family defined in the Central File at the moment. Each user loads the family, into their Local File, unaware the other user is doing it too. The first person to use SwC is fine but the second user sees this message (I expanded the warning to see the family description).

When the first user uses Reload Latest or SwC they'll both be able to see this in the Project Browser, listed beneath Detail Items.

Subtlety compounded with yet another subtlety...if the family is already defined in the project (Central File) but a new TYPE is loaded by more than one user then we end up with this situation in the Project Browser.

How do we avoid this situation?

As soon as we think we need to load a new family or type...STOP.

Who (on our team) is responsible for ensuring the content we need is available to us? There ISN'T any ONE person assigned to this? There should be. All new content should be requested, requests sent to or asked of this person. That person can delegate the task.

The goal is to avoid the situation where more than one user is loading the same new content.

Only ONE person needs to load the family(ies)/type(s) and then use SwC to make it available to everyone else on the team (they use Reload Latest). We are working on the same project after all.

To close and return to what inspired my post, Jason went on to write that they've abandoned using Detail Components in their details because of this issue. Tragic. They (the detail families) aren't the problem; Revit's worksharing behavior and user habits are. I hope he'll revisit that decision.

Revit 2016 - Loss Method and ASHRAE Tables

Fittings and loss errors have been annoying in Revit MEP for quite some time. If we were striving for a warning free model then we'd be confounded at every turn by fittings and their loss for loss. In Revit 2015 R2 and 2016 we've got the option to assign fitting's Loss Method parameter to Coefficient from ASHRAE Table.

The ASHRAE Table Settings dialog displays graphical information that is associated with duct fittings table. We can choose from among the fitting descriptions in the table or accept the default one that is already selected.

If you select a fitting randomly and check this out you may find the dialog set to None. It only starts to work when components are well connected. That means, if you see warnings associated with fittings, its likely those fittings are not part of a well connected network yet.

Revit 2016 Trial Versions - Do Not Install the Wrong Version

A post of caution - If you are tempted to download a trial version of Revit 2016 please keep in mind that it comes in three trial flavors:

• Revit
• Building Design Suite (BDS) Ultimate
• Revit LT

Let's imagine you're anxious to check out the new release and just download and install a version that you don't already have a license for with the expectation that you will just activate it for your particular license later.

PLEASE DON'T DO IT!

If you do install a version you don't own then you'll get to REMOVE that version and INSTALL the version you really need instead.

The installation is perhaps the least of it since the download time (the installation files are large) can be significant so I'd be really sad if I downloaded BDS Ultimate thinking I could just install it and then authorize it against Premium.

NOPE... uninstall, download correct version and install. I'd be wailing and gnashing my teeth...

Don't go there, wait for your correct version to become available to you via the subscription center. Forewarned is four-armed (as I read recently)...

Copy Paste and Structural Floors

The situation this post describes seems like a bug to me. If not then it is certainly confusing least.

When we use Copy to Clipboard and Paste Aligned... to place families on another level or more than one other level the outcome is affected by whether a structural floor slab was present when the families were added. For example consider these floor slabs (see next image), each configured as shown by the screen capture of their properties. There are three desks in the view too, one on each floor. Specifically the floor on the left does not have it's Structural parameter checked, the middle floor has both Structural AND Enable Analytical Model parameters checked, and the floor on the right only has the Structural parameter checked.

If we use the Copy to Clipboard tool on the three desks (one on each floor) and then use Paste Aligned to Selected Levels, choosing Level 2 we get a dialog showing that there are two warnings associated with the desks over the two structural floors. The desk on the left is not involved in the warning.

This is what the end result looks like in elevation. We have a new desk on Level 2 above the floor that is not structural but the other two new desks are in the same location on Level 1.

At this point it appears that it is caused by using the Structural parameter. If it's checked that is BAD for using Copy/Paste. If we create a floor that is not structural the hosting relationship isn't forced on the hosted elements. If at any time we check the structural parameter any elements that you place on that surface will lock out the normal desired Copy/Paste behavior, they'll only be placed on that surface. Deciding to un-check (turn off) the option after it was turned on won't resolve the situation either. The floor can't EVER be structural. If they are/were any families placed on the floor's level will become locked in to that floor.

Said another way, this condition affects families that were originally placed on a floor that is or became Structural before the families were placed. If the families were there before the floor or before the floor was changed to structural they'll work fine with Copy/Paste. In my testing so far this condition also appears to be limited to families that are level based (also referred to as "not" hosted), for example furniture, casework, generic model, plumbing, and specialty equipment. If the families are "Face-Based" they appear to be unaffected, for example a light fixture.

We can avoid this by turning off the Floor category in the view before placing families. Changing the view to use Wireframe instead will not help.

This post is the result of looking at a project shared at RFO that was exhibiting the problem.

Creating Family Templates

Revit does not permit us to use Save As to create a Family Template unlike projects which can be saved as either a project or a project template. It's a bit like a strict parent that insists we go to bed at 8 PM no matter what, even if a TV show we really really want to watch is on at 8 PM.

Along the way, many years ago, someone noticed they could just rename the family to use the template extension .RFT instead of .RFA (family extension). The technique works as long as you don't have a desire to alter its structure (the file that changed from .RFA to .RFT) once you've started to create a family with it.

This means I can rename a family extension from .RFA to a template extension .RFT. Once it's changed I can create a new family by clicking New Family and choosing this special family template. While working on this new family (based on the template) I cannot delete any reference planes/lines or dimensions I created while it was a family (not a .RTE). When Revit opened the file it took ownership of all of "my work" while it was still just a family (using .RFA).

This means that if I want to start a new family based on this template but realize I need to alter the format a little, I have to return to the original "template/family" to do so. Once I've changed the extension to .RFA again I can alter the template's format freely. Any families I've created using the template can't be changed as extensively or freely.

There is no going back to a less well prepared format, at least not with the resulting family(ies). I can move and copy reference planes but I can't decide I don't need them any longer. Revit locks down the reference planes in the same way that the stock templates have done for the reference planes we find there. It protects those parts of the template file. This can be particularly confusing for other people when they come across a family and think they can reverse engineer it or start with this family to create something similar. It's confusing when they can't get rid of so many reference planes and dimensions.

Since I frequently have different things asked of me I just leave families assigned to the .RFA extension, those that I think of as templates. I add the word "template" to the name. This way I don't have to deal with switching the file extensions back and forth, which I find confusing. Which ones did I change, which ones did I leave alone? I just keep my templates in a separate folder. The hardest part for me is remembering to use Save As before I start messing with one. I could make the folder read only to make it a little harder on myself.

I recall slightly different results using past releases. This post is based on using Revit 2014.

Room Separation Line Overlapping a Wall Error

Another inspired by email: When you sketch a room separation line and it overlaps a wall you'll get yelled at. Revit will also store the warning for you to deal with later using Review Warnings if you don't resolve it right now, when the warning first appears.

If you change the Wall's Room Bounding property so that it is "off" or un-checked you'll still get yelled at when they overlap. Revit isn't checking to see if a wall is room bounding when it catches the condition. It's only concerned that they both overlap. No grace for you!