Best Practices/Remodeling and Wall Joins

[BillyGrey]

I have been having some wall join issues with Revit in general (2008 or 2009)
with reference to wall joins from phase/existing demo to new; wall joins aren't sticky or join incorrectly, changes "away" from a join can cause a corner to fly apart, or where windows/doors exist and are demo'd, there are a whole plethora of problems that can arise.

If you have direct experience managing problematic wall joins in this typ. of a project, I'd like to hear from you. I really don't have any more time to guess my way through hypothetical possibilities because of all the issues I have experienced. Anyway, I've tried all manner of fixes and work-arounds.

In the end, I find myself considering breaking off the new phase of the model from the prev. phases so that I can work freely, without any further drag.

Big Thanks in advance.

Bill

[patricks]

I usually find myself disabling the wall join at the end of a new wall that I'm bringing up to and connecting to an existing wall.

[BillyGrey]

Thanks; are you speaking of a simple butt join at mid span and 90d corners?
Also, I forgot to mention this project is 2 stories tall.

[twiceroadsfool]

I disable existing walls joins, and new walls that have to butt in to existing walls, for simple joins.

Where i need to demo windows and doors, we very often use a different approach other than switching the door/window to Demolished: We will edit the profile of the wall and trace the window, then place a duplicate wall with the inverse sketch (so its JUST the window) and will host the existing window in that. Then, instead of demo'ing the window, we demo that wall. At least, we do this if we dont want it to infill automatically, which is a pain in the *** to work with, unless its an easy cut and dry infill.

It sounds worse than it is...

[BillyGrey]

Thank You all for your answers.

Unfortunately, this is an area that Revit has sorely let go as an ongoing broken feature.

I am forced at this point to abandon the phased development of my project under one file, which is ironic, because this feature actually worked better on previous releases on more complex projects.

Regrettably,

Bill C.

[twiceroadsfool]

Im not sure its broken, per se, so much as a very complex issue that is hard for programmers to deal with.

How should it behave, in your eyes? Im genuinely curious, as we all want different things for it. I could see a dialogue popping up everytime you demo something like a door or window, asking you "Infill or leave opened". Then if you pick infill, youre in the same boat youre in now, unless things like doors and windows suddenly become able to affect not only their hosts, but similar hosts next to one another. Which would cause all kinds of issues, as revit tries to ASSume what you want (hello wall joins?).

Our method os wordy in verbage, but works extremely well. I just finished a project where small portions of existing wall were demo'd, including some existing doors. Some doors got infilled (with different wall types) and some remained, some walls that were knocked out got doors, some didnt. It was difficult to wrap our heads around, but once we figured out how to do it, revit worked very well...

[BillyGrey]

Im not sure its broken, per se, so much as a very complex issue that is hard for programmers to deal with.
How should it behave, in your eyes? Im genuinely curious, as we all want different things for it.

I think that in the context that the tool is designed, presented and implemented, it leaves allot to be desired. To compound my problem, this is a large, complex remodel, and I'm having to do allot of flexing and revising in the new phase to meet client demands/explorations.

I understand you and your firm have developed a methodology of working around many of the limitations, but you indicated that it seemed better on simpler rojects, yes?

In my case, I only tried to accomplish what the tool says it can do, and is intended to do on it's face value within it's parameters. Did it pass that test? No, therefore, I'm sure it is not working properly.

I could see a dialogue popping up everytime you demo something like a door or window, asking you "Infill or leave opened". Then if you pick infill, youre in the same boat youre in now, unless things like doors and windows suddenly become able to affect not only their hosts, but similar hosts next to one another. Which would cause all kinds of issues, as revit tries to ASSume what you want (hello wall joins?).

Why assume anything? If it works it works; we all know what the intended outcomes are. The real world scenario is simple, so programmatically it should reflect that; if I demo something, I should be able to pop in a new wall at that location, then insert a window without a bunch of hoodoo gyrations regarding both elements. What users should not have to go through is unintended consequences reverberating through the model aside from the problem designed/demo'd elements. Consequences such as elements on the other side of the house loosing their connections, or joins 10' down the wall line flying apart, etc.

Our method os wordy in verbage, but works extremely well. I just finished a project where small portions of existing wall were demo'd, including some existing doors. Some doors got infilled (with different wall types) and some remained, some walls that were knocked out got doors, some didnt. It was difficult to wrap our heads around, but once we figured out how to do it, revit worked very well...

For my firm, very well is closer to excellent, but a simple passing grade is just doing what something is supposed to do without a bunch of problems, hassles and time killers.

I think one very big picture issue that is very much lost upon much of the user base at this point in Revit's development, with reference to some elements in the program which have been implemented for many release cycles are these 2 words:

Mature

Robust

Finally, there is the time constraint issue that kills profit. I should never be forced to charge my clients for time lost due to unexpected deficiencies in my chosen tool or worse, expect them to wait for me to figure these out. That is why I buy the tool in the first place. To make my job more efficient. At this point, this particular model has become very inefficient, and it is now obvious to me that it will be faster for me to just drop the 3rd phase of this project, generate some dwg's of the existing phase, and draw the proposed phase/(s) over that.

In the end, I did'nt mean to begin a rant or debate topic. I just went through that on another thread and I did'nt enjoy it...I was hoping for something else, but given the time constraints I face, I gotta haul a$$.

Most of all, I do appreciate you sharing your method of work, and will certainly learn from it and take it under advisement when I start my next phased remodel. I will see then if that can help put the "magic" back into one of my favorite tools in Revit, but my true problem today is that I'm up against the clock. I know I only posted this thread yesterday, but I am replacing 30+- windows and a grip of doors on this project, so I don't think I have the time to try your method, and know I can model this thing up "new" in a jiffy.

Thanks.

[twiceroadsfool]

I think the best point you typed out (that caught my eye) was that i want Revit to handle demolition exactly like the real world: Only we differ in what happens in the real worl.

When i see contractors tear a wall down, i dont automatically see one go up in its place. I just see the wall come down. If i want it there, ill TELL you i want it there. Same with doors. If i demolish a door in the field, guess whats left? A hole. Not a new wall, and certainly (as you indicated) not a wall that acts DIFFERENTLY. In THIS regard, id like to see the tool simplified, but i think more people would be unhappy with it that way.

Nonetheless, weve had great success with the demolition and phasing... Although im not sure the project at hand was simple. When it was said and done, we had intermittant fragments of wall, some existing to remain, some new, some old openings filled in with varying wall types, etc... And that wall was also the boundary between two different phases (both in construction and in revit).

Did it take time to figure out? Sure. Is it right to charge a client for time spent learning the tool? Im not sure, thats an ethics thing, i guess. But, i always tell people to be prepared to "lose big" the first time out of the gate with a new tool. I said it with ArchiCAD, i said it with Digital Project, we were saying it with AutoCAD way back in the day, and i say it with Revit now. It has nothing to do with the tool itself, in my opinion.

Demolition and renovation is very complex. I could think of a one-hundred different ways the programmers could interpret our needs for developing such a tool... And invariably, someone isnt going to be happy, whichever way they go.

Good luck with the deadline... Have some dunkin donuts coffee. It always helps me through.

[davidcobi]

On one of our first projects, getting clean building sections out of the phased model was more challenging than any other part of the condocs.

[BillyGrey]

Thanks for your thoughtful response Aaron.

On one last point of clarification (kind of like my "simple" idea stood out in your mind), I don't want the meaning of my post and topic to be lost. My take on the remodel tool has always left me impressed. I have utilized it to great success in the past, and am very experienced with it. Further, I always "show off" how well the documents turn out with my clients and contractors, and explain how it works in the context of the model.

On the other hand, and this is what the thread is about;

A) Best practices (to which you contributed nicely)

B) But also to shed light on a lingering, true problem that should not be deflected away. That is, I can model you a very simple condition that will present very complex, puzzle like problem solving, process of elimination style exploration to find the fix. This has nothing to do with how a tool should work from a code level development standpoint, but probably has more to do with the way the model itself interacts with itself.

In the end, when I model a bay window, then demo a portion of it, remodel that portion to another (but similar) configuration, is it safe to admit that it is o.k. for the opposite end of the bay window (untouched) to break? That is my point, it happens this way, and in many similar ways, always has, and it deserves to be addressed and fixed at some point in the future.

Thanks Aaron