Many years later I
am 3.5 years into my use of Revit MEP and have had the pleasure to see how many
different firms are exploiting or suffering through a multi-discipline Revit
workflow. Revit MEP and Revit Architecture's problems seems to be with the high
level of dependency MEP objects have on host Architectural faces.
It is very easy for
an architect to delete and recreate geometry that is, unapparent to them, the
host of an MEP object. This destroy's the "warm and fuzzy" feeling
Revit gives us about elements staying spatially coordinated. In fact it can be a nightmare even if the
element remains hosted. For example, sometimes a ceiling might move for some
design purpose. If elements are hosted to those that have hard connections
(e.g. ducts and air terminals) the architect runs the risk of destroying duct
networks that don't have the space to adjust.
2 strategies need to
be undertaken to make sure this works better:
First, Communicate design
changes out side of Revit. This one is an age old problem between architects
and MEPF consultants. You either need to setup a brute force way of
communicating (email report of model changes by room upon receipt of a new
model) or a software centric comparison automation (in Navisworks or the
Compare Models Revit extension).
The most important change that needs to happen is both
parties understanding the limitations, implications, and realities of a
coordinated workflow in Revit.
Second, MEPF engineers need to respect and anticipate how the architect's model will change. MEPF engineers can
host elements on reference planes where hosted and orphaned elements are
sensitive to change. The model adjustment will be manual but many hosted
elements can be changed at once. Or maybe no elements should be hosted at all.
I ran an unconference session at this past AU called "Leveraging and
Architect's Model in Revit MEP" and this was the sentiment of the group
that attended. Those that had once hosted on planes no longer do so. A vast
majority actually have a standard for non hosted components for everything.
Bottom line, this is
a two way street. Architects need better ways to communicate changes per model
update, and MEPF engineers need to host (or not host)objects in a way that
protects them against damage caused by changes out of their control.
No comments:
Post a Comment