Tuesday, March 6, 2012

Revit Walls/Structural Walls/Rooms and Spaces...from the MEP Perspective

Now that we're getting deeper into Revit on our projects, we find ourselves in an interesting situation. The question is, who owns the walls? And why does it matter to the MEP user?

Our structure is pretty simple - we break projects up into 3 categories - architectural, structural and MEP/Process (yes, on most smaller jobs, these two are in the same project - the benefits far outweigh the file size issues up to about 150mb). Water projects are a little different than typical building jobs - the process drives the building, instead of the other way around.

Initially we started by saying, the architect owns the non-structural wall, and the structural engineer owns the structural walls. We did our first project this way (and we also let them own their own levels). This didn't work out too well for a couple of reasons. Not keeping the levels all in the architectural model (as architectural levels) cause MEP views to work incorrectly, when copy/monitored into a project. One of the impacts was on the space creation - it didn't like how the structural wall was defined, and caused a variety of areas. Both architectural and structural had levels at the same elevation as well, and this cause a lot of headaches on the MEP side.

Another issue came up when the architect created part of the wall for a room as architectural walls, and the structural engineer made the rest. Even with the structural model linked in and set to be room bounding, a couple of rooms never recognized the structural wall as a valid boundary, if the items are not at the same level or following the same bounding surface area. For example - if a structural user alters a structural wall, to move it to a different level or change the top/bottom constraint, the room and space fail. If the structural wall starts on a different elevation than the architectural wall (regardless of how it's defined, top to bottom or bottom to top), then the room and space may fail.

So here's a couple of ways to look at it. If an area of a building is meant to be occupied - whether it's by people, process fluids or equipment, etc. - then the walls that define the closed boundary should be defined as architectural. This way, regardless of whether they really are structural or not, a room can be properly defined for the area. The space association with room is the driving factor here - in order for a space to correctly track area electrical, HVAC and other power loads, it's got to have a good closed boundary. If the room works, the space will work too. You can always change the properties of the wall in the architectural model to be structural and load bearing, if that's the intent. Once the primary walls are defined, the structural model can copy monitor the walls, and edit the copies as needed to perform their structural layout and analysis.

Anything that's not enclosing an occupied area can be either a structural wall or non-structural, but my preference is that it be defined in the structural model - my thinking is that this applies to foundation walls, footings, etc. that are strictly there for support.

You can always link in structural models, set them to be room bounding, and place rooms where a combination of both structural and non-structural exist - just be aware that changes to constraining levels may cause you to have to rebuild the rooms, and subsequently, the spaces, in your project.

Hope this makes sense - let me know how you're doing it in your projects.

Thanks - David B.

No comments: