Best Practices for Levels?

[lhanyok]

After I completed our firm's pilot project, I have now embarked upon training others in Revit on another project. I have some questions about how to setup the levels on the project. The building is three wings, one of which is 2 stories, and the other a story and a half. I think that we should have a level for the roof of the double story wing, and a level for the roofs of the 1 1/2 story portion. Another member on the team just wants to offset the heights of all the walls on the 1 1/2 story portion 16' off of the first floor. His reasoning is that the way he is thinking about it is we need 16' clear inside of those spaces, and therefore the walls should just be set at 16'. They are all attached to a sloped roof.

I gave the argument that if we decide to change the dimension of that clear height it will be a lot easier to do if they're all attached to a level. Even though they are attached to a roof, I want to keep things consistent. He doesn't seem to be convinced, so before I just put my foot down and say that that's how we're going to do it, can anybody support me on this? Or maybe I'm the one that's wrong, and we should go about it a completely different way. Any suggestions?

[BillyGrey]

I agree that individual levels are a best practice, and especially for controlling wall/roof heights tied to that vertical elevation. It is a regrettable situation at best if anything does change in a model, esp. after it is fully developed, and a change is proposed. I am not sure if your modeled geometry is simple or complex, but having to cull through a bunch of walls and changing their parameters in the properties dialog seems a very un-elegant solution.

Moreover, there is the future to think about. Develop a one-off solution for no clear reason on one project, and away it seems to go after that.

Utilize the parametric capabilities of Revit to their fullest, especially when there is little or no overhead on the model/performance aspects of the issue.

my 2cents

Cheers

[dbaldacchino]

Well, keep this in mind....just because you make the team create a bunch of levels doesn't mean they're going to use them ;) So make sure you educate them about the reason you're asking them to create these multiple levels and why it is imperative that you assign the objects to them.

In double-story areas, I actually prefer to assign objects to the first level. This is just personal preference. For example if my floor to floor is 14'-0", I'd rather have a wall top that says it's 18'-0" from Ground Level rather than 4'-0" above Level 2. This gets worse when you, say, have a mezzanine level at 12'-0" and/or an intermediate roof level at 13'-0" and someone attaches the top of a wall to these levels and now you get a wall top at 5'-0" from the Intermediate Level......hmmmmm now how tall is this wall, because I can't remember if this level is 12' or 13'?....you get the point.

Make sure to keep levels to a manageable minimum so you don't have to be constantly cleaning up sections and elevations from unnecessary level annotation. You can always place some unwanted levels on a workset set to not be visible by default.

When it comes to ceilings, keep in mind how you want your tag to read. Typically we show height above finished floor, so again, in a double story height, I wouldn't want that ceiling assigned to level 2 or it might read as "10'-0" AFF" instead of your designed "24'-0" AFF". Just some things to think about....

[Arnel Aguel]

When it comes to ceilings, keep in mind how you want your tag to read. Typically we show height above finished floor, so again, in a double story height, I wouldn't want that ceiling assigned to level 2 or it might read as "10'-0" AFF" instead of your designed "24'-0" AFF". Just some things to think about....Great analogy you have there David thanks.

[rjcrowther]

For levels, I would automatically assign 5 for a Double storey house:

First Ceiling Level
First Floor Level
Ground Ceiling Level
Ground Floor Level
Top of Footing

If there was a mezzanine I would also have 2 levels denoting the depth of the mezzanine floor zone.

My preference is to reference something within its own level - just suits my method of thinking.

Good to read that others have a different, and successful, approach.

Rob

[dbaldacchino]

Any approach works, as long as you manage the information in a consistent way. Our structural group places more levels than I'd like to see, but it seems to simplify their modeling, especially getting the analytical right. I've also seen the approach of creating a level for the different parapet heights in a building. When you do this, you get your level annotation in a wall section, whereas if you you don't, you'll have to create fake annotation, use dimensions or use the spot elevation tool and perhaps make it look like the level annotation (one big wish of mine is to have more flexibility for this tool). Either way you look at it, there's no right or wrong!

[cphubb]

David,

Do you set your levels to scope boxes to prevent them from showing all over the place?

This is a good practice in those split level buildings like lhanyok described. We only assign levels to floors roofs and sometimes parapets. We do not place a fake datum on the parapet, just dimension or use a spot elevation.

[dbaldacchino]

For a "fake" elevation, I'd use something with a bit more intelligence, such as a line-based detail component family.....click 1 on the base datum in section/elevation and click 2 on the desired location. This annotation would be set to display a level head and the length of the line-based family. Locking each end to the base datum and the object means that if these change, this "annotation" would update (as length changes, the reported "elevation" changes too).

Anyway, we have not used scope boxes to manage levels or grids yet, but I see your point and I think that scope boxes are very powerful management tools in that regard. Most of what we do have different heights & high/low conditions but typically all start at the same level. I'm trying to keep it simple as users already have a hard time understanding how we're creating scope boxes in plan to control crop regions by plan area :) Also for grids, we've tended to show all grids in all plan areas, even if a particular grid pertains to just a few columns at the other end of the building; this is one reason why we are not using scope boxes to their full potential yet.

[lhanyok]

Well, keep this in mind....just because you make the team create a bunch of levels doesn't mean they're going to use them ;) So make sure you educate them about the reason you're asking them to create these multiple levels and why it is imperative that you assign the objects to them.

This has been the hardest part with the team. After reading all of your responses, I think I'm going to stick with my original plan to add a new level for the 1 1/2 story space roofs. When I say 1 1/2 story spaces, I should clarify that it is just a really high single story space. I guess I've been calling it 1 1/2 stories since that's how we've been describing it's height.

Anyways, right now, different people have constrained the top of the walls several different ways - doesn't make for a very clean model. My biggest reason for constraining the tops of walls is consistency, so that we don't have to keep track of how high the walls should be - because people aren't doing that.

I agree with David's comments on a double height space, since that is typically how I would constrain elements as well.

Thanks for all of the responses!

[chodosh]

Could you use a Reference Plane in this case instead of a Level?
-LC

[dhurtubise]

yes but make sure you name the ref plane

[chodosh]

Absolutely! Good point...
-LC

[Wesley]

Also, if your files are going to have analyis done on them for heating and cooling, you do need to be careful about the way you use levels. If your room height is set to the next level up by default, it will give the wrong values for that 1 1/2 space; and if you have a level for your ceilings, the plenum itself will be left out of the calculations.

BTW, if the ceilings are not seperate levels, programs like IES<VE> will ignore them in doing its calculations.

[dbaldacchino]

BTW, if the ceilings are not seperate levels, programs like IES<VE> will ignore them in doing its calculations.
Hey Wes :) Hmm didn't know this. So you're saying that ceilings cannot be given an offset from some other level? Or you mean they have to reside on their own special level with no other elements associated to it? If the latter is the case, I guess you could have a duplicate of Level 1 so your AFF height is what you'd want it to display when the ceiling is tagged.

[chodosh]

...So you're saying that ceilings cannot be given an offset from some other level? Or you mean they have to reside on their own special level with no other elements associated to it? If the latter is the case, I guess you could have a duplicate of Level 1 so your AFF height is what you'd want it to display when the ceiling is tagged.

In the IES VE, if your room volume in Revit is set to an offset ceiling (8'-0" AFF ceilings when slab to slab is 12'-0", for example), you will have a void space above it that is incorrectly excluded from the calcuations (e.g. the plenum space). You can use a Level for the ceiling and then make this a separate room to give it the bounding elements required to make the room + plenum into two distinct volumes. Instead, Revit advises that you ignore the ceiling and make your room volumes go from floor Level to floor Level (i.e. structure to structure). The Green Paper (http://images.autodesk.com/adsk/files/building_performance_analysis_using_revit.pdf) explains it better, with graphics.

-LC

[dbaldacchino]

Ah cool, thanks a lot for that. I'll need to get familiar with the IES tools but as of right now, I have not worked a true full Revit project with MEP. This will come in handy as we'll soon start such a project.

So if I show my rooms to be 9'-0" high and MEP needs them to be different, they can always C/M the rooms and adjust accordingly, right? Because I can see how teams might not appreciate the need to accurately model room boundaries that aren't important to their drawings, since they're not visible or don't add information to the architectural representations.