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?

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

Synchronization and Disconnected Systems

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

Imagine this scenario:

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

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

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

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

Dept. of Errors - Assert Yourself?

Have you seen this message? I've been seeing it lately in conjunction with middle mouse use and having my computer connected to a projector. I don't recall seeing it in other circumstances.

If you have I'd be curious what the circumstances have been (post a comment). I find that if I click Retry that I can at least save the file. Ultimately I have to click Abort and accept that RAC, RST or RME will have to close. At least I can save!!

Are You a Good Sketch or a Bad Sketch? Part Deux

I wrote an article about this before but just put an image in the post. I thought I'd revisit it with a video this time. You can listen and watch here too.

Video Bandwidth

If you've attempted to watch a video and got a bandwidth message, it has been fixed. Sorry for the inconvenience.

Dept. of Subtle - Family Editor Parameter and Formula

This is an "oldy" but "goody". When you add a new parameter in the Family Types dialog and then immediately attempt to use that parameter in a formula Revit generates this message.


To avoid this message just click APPLY or OK (which closes the Family Types dialog box) to commit the addition of the parameters to the family. Then return to the Family Types dialog and add your formula. You just need to let Revit get used to the new parameters first, then it will happily let you make the formulas you need.

Hey You! Smell the Roses!!

It goes something like this..."Hey Steve can you help me with something?". Naturally I can't wait to help! I eventually stop browsing AUGI and wander over to their desk and ask "What's up? Need help with that Stock pick? or trying to decide between the Vanquish or the DB9?, you only live once go for the Vanqu...oh it's a Revit problem? I see, well what's seems to be the matter?"

They say, "I'm having trouble getting "this" to work!" I ask them to run through it again. Two steps into their demonstration I see a warning message flash on the screen and before I can say, "Jumping Jack Flash" they've clicked the OK button and they've moved on to the next step.

I say, "What was that message?". They say, "What message?" I say, "The one you didn't read and then clicked OK for!". They say, "NO!??!...really??"...yeah really!!

My advice? Take a deep breath, slow down...smell the roses...read those messages and more importantly try to understand them. Even the ones that just offer a simple "?". That one just means Revit is as confused as you are, you both need a break.

Have a nice day, visit a garden!

Dept. of Reviteristics - The Solution is Delete!!

Whenever you get a warning message or use Review Warnings have you noticed that the solution Revit seems to think is the correct choice for practically every situation is to DELETE the offending element. It is sort of an "off with his head" reaction isn't it?? Is your wall giving you problems...DELETE IT! That's what I do and I feel much better! It is the "duct tape" solution in Revit...101 uses!

I think it would be wonderful if...since Revit caught a problem in the first place...the warnings were more meaningful, in "plain English" and offered us some more useful possibilities in addition to or other than DELETE!

Am I unanimous in this?

Save and Save to Central Error Message

Teams that use worksets and link multiple Revit models started enduring this message a little over a year ago, around the release of 2008 methinks.


Autodesk finally pinned it down to this:

If a linked RVT file contains a linked DWG (or other "CAD format") file, and the DWG file has changed on disk since the last time the linked RVT file was saved, then when the linked RVT file is loaded (as a link) the DWG file is reloaded which Revit interprets as a modification.

If this seems vaguely familiar, Dwayne Lindsey posted about the newly minted Known Issue at Autodesk on his Blog Revit Arch-Center. I'm reposting because I read and responded to a question at AUGI and a couple clients were bumping into it recently. I thought why not echo it again...again?

If the dwg file is reloaded into the linked model or if the linked model is opened and saved the issue should not generate the message until the dwg file is altered again. If the file is NOT a "Link" then it wouldn't generate the message either. So that might be an argument to not listen to my normal advice to use the Link option with DWG files. Make rules and then break them is my "motto" 8-).

Proper credit to the guy I first heard nail it down, John Vogt with HOK St. Louis. John 'splained it to me at the HOK Cad Work Session I attended back in May. Sure enough he was correct! You are the MAN John! Cheers! I'll buy you a beverage next time around!

[I stole the image from Dwayne's post because I can't recreate the error in the latest build of Revit 20080602-1900, thanks Dwayne!]

[Amended: Andre Carvalho added this suggestion in a thread at AUGI:
The way I found it works nice, is avoiding to link the DWG that someone is still working. Instead of that, I first create a blank CAD file, XREF the DWG that someone is working and save in another folder. This new DWG will be the file I will bring into Revit. Because it has an XREF from the original file, I still can see the changes made in it when I open Revit, but because no one is actually opening it, working on it or saving the DWG I've created, I never get that message anymore...]

Export To File Error - Illegal Characters in View/Project Names

I posted this at the HOK CAD Solutions blog regarding this issue today and I am providing a link here just in case you don't visit their blog...yet...

Keep it Legal!!

Retry = OK

Every now and then an error message pops up in Revit and most of the time they tell you what is wrong and how to resolve it. Sometimes they are a bit too mysterious like this one. We had a good chuckle when we saw this one tonight.



Apparently OK = Retry and Cancel = Ignore

This message occurs when you acquire coordinates from a dwg file and that file is open for editing by someone at the same time as you save your project file. Revit wants to store a user UCS in the dwg file but can't access it.