Fire and or Smoke Rating walls

[g.ganapati]

This issue had been debated all over the place- and what i have read has confused me further.

Issue: The rating of the wall is an type parameter- while i want it to be a instance parameter. Why? Because 2 walls built identically may not need to be considered rated- which allows penetrations etc. w/o firesafing.

Possible solution: While it would be silly to remove fire rating at the type parameter- a "use fire rating" switch could be added to instance parameters?!

So using filters is out for me (unless i add wall types)- and lines seem a bit inelegant a solution.

If any of you have worked around this- please advise!
Thanks.
gg.

[Calvn_Swing]

Here's what we do. The "possible rating" or "assembly rating" is and should be a type parameter. Why? Because a wall assembly with a 3 5/8 metal stud and one layer of 5/8" gypsum on each side will always have the same UL assembly rating. We use the built in type parameter "Fire Rating" for this value.

We then create in the project template a shared text instance parameter called Acoustic or Rated construction (you could do smoke or fire rated construction in your case). In a project, we either populate that field with an R or an A. That parameter is in our wall tags, and our code plan VG filter settings search for that parameter to enable graphic overrides in walls along with the Fire Rating parameter to know what it is rated for.

Make sense?

[dgreen.49364]

We have a fairly anal wall type system, which works well in this case. Using the example of two walls with the same type of construction, one being fire rated and the other not, we use two different wall types, with different type marks, and of course, the one that is rated has "1Hour" in the Fire Rating Type Parameter while the other does not. IMO this is a case where there is no reason to add/change the way Revit deals with walls.

[Calvn_Swing]

I respectfully disagree.

The way Revit handles it worked horribly for us. On complex projects if we had a different wall type for every little thing (Rated, Acoustic, Insulation, nothing special, Rated and Insulated) Then we'd have 5 identical types (identical structures) with only one or two parameters different. Now, multiply that by 20 to 30 wall types and you've got a real nightmare in terms of keeping track of what is what. Worse, our designers would go crazy with a list of 100+ wall types to choose from.

To me, wall types make a lot of sense to represent what is in the Structure of a wall. (Hence, Fire Rating = Assembly Rating for us) Anything else (Height, Rated Construction, etc...) all make sense as instance parameters to us. That's how you want to change them in a project. Select a wall that should be rated, and say "You're Rated" and done!

Anyway, two different perspectives.

[dgreen.49364]

It's ok for you to disagree. You see...our anal wall type system was in place long before Revit came along. It is just as you described...a different wall type for every little difference. Overkill. Not my idea, I just work here. But...it works great with Revit.

[Calvn_Swing]

Ahhhh.... Now I see.

We accomplish more or less the same thing with less pain though. We still have unique tags for each wall, some of the parameters in the tag are just instance, and others are type! Good times though. I had plenty of issues getting people to let go of CAD standards in order to make life in Revit easier. This is the first example I've heard of with a CAD standard actually working in line with Revit's OOTB methodology. I'm laughing on the inside (not at you though!).

[david.kingham]

Hey Kelly I like the sound of your system very much, would you mind sharing more info...I just posed this question last week http://forums.augi.com/showthread.php?t=69798

[g.ganapati]

Here's what we do. The "possible rating" or "assembly rating" is and should be a type parameter. Why? Because a wall assembly with a 3 5/8 metal stud and one layer of 5/8" gypsum on each side will always have the same UL assembly rating. We use the built in type parameter "Fire Rating" for this value.

We then create in the project template a shared text instance parameter called Acoustic or Rated construction (you could do smoke or fire rated construction in your case). In a project, we either populate that field with an R or an A. That parameter is in our wall tags, and our code plan VG filter settings search for that parameter to enable graphic overrides in walls along with the Fire Rating parameter to know what it is rated for.

Make sense?

Just to be clear- when you do a graphic override - you are changing the "common edges" graphic style for the filtered walls?
Thanks!