Door Fire Rating

[ericnC2WN4]

Hello!

I know that the 'type' vs 'instance' debate when it comes to the fire rating parameter for doors is as old as the ages, but I have one fundamental question...why? Why did Autodesk establish this as a 'type' parameter? I assume that there is a reason why....so why? I am hopeful that an Autodesk employee sees this post and can supply an answer to this question.

[SteveKStafford]

It boils down to the experience of the architects involved in the product originally and their experience with the types of projects they worked on informing their choices. When I got started in architecture I mistakenly thought it's a fairly monolithic kind of profession where we'd all agree on such things. 🙂

[Mike.FORM]

The likely reason is that when the developers of Revit added fire ratings they intended users to create new types for elements that are rated.

From a BIM standpoint, a hollow metal door and frame that has a fire rating is a different door than one that does not have a fire rating.

[David_W_Koch]

Taking all that @SteveKStafford and @Mike.FORM said into consideration, there is no reason why you have to use the built-in parameter in your projects and schedules.  If an instance-based parameter suits your workflow better, create a shared parameter, make it instance-based, and use that instead.

Ask a group of ten architects how to do something, and you will likely get at least eleven or twelve opinions.

[ericnC2WN4]

Sure, I know how to create an instance parameter to handle this situation, and I have done the workflow both ways. Usually when I get into this debate it always devolves into "why did Autodesk code the parameter this way?"...so I thought I would ask. I would like to know the rationale...good, bad, or otherwise.

[HVAC-Novice]

Revit basically provides a few hard-coded parameters. You can use them or not. But Revit also is built to customize (with your own shared or project parameters in this case). 

If the native Revit parameter was "instance", people also would have reason to make their own. 

FWIW, I use a shared parameter (that also is used as project parameter) I apply to walls, floors, ceilings, roofs, doors, windows, dampers... and probably something else I'm forgetting. That way I can show the fire rating in tags, schedules, or color-code based on it. For walls often it is instance, for doors it is type... really up to you how to do it. Revit gave you all the tools inc. the ability's to create your own parameters. Use them. 

You see that some people prefer instance, some type. this all depends on our workflow, schedules, tags etc. Autodesk just assumed a common scenario. For me it actually is very rare that I use hard-coded parameters. For one reason or another, I end up creating my own since I run into these issues that I use them differently than Autodesk intended. 

[barthbradley]

You can make the Door Families' In-Built Fire Rating Parameter an Instance Parameter. Is that what you are after? 

1. Open Door Family
2. Put a value in for Fire Rating Parameter
3. Recategorize Family from Door to Generic Model Category
4. Edit Fire Rating Parameter and change it from Type to Instance
5. Recategorize Family back to Door Category

[barthbradley]

As for why Families (and Templates as well) are built the way they are - maybe there is no rhyme or reason. Maybe Autodesk wasn't even involved in the decision. You would need to talk to the originator of the Family to find out for sure. 

By the way, besides changing it in the rfa, you can also change it in the rft.  

...I have a guess. It's not that "Type" was chosen. It's that the extra steps to make it "Instance" weren't done.  Maybe that work wasn't included in the contract.  

[SteveKStafford]

---

@barthbradley wrote:

As for why Families (and Templates as well) are built the way they are - maybe there is no rhyme or reason. Maybe Autodesk wasn't even involved in the decision.

---

Yup, Revit Technology Corporation staff made all of the foundational decisions from 1998-2002 and Autodesk bought them in 2002...and many of the earliest staff remained on the team for at least a year afterward...or in some cases many years afterward. I could probably name the person who made the final decision guided by the architects working alongside...but that's not my place. They definitely made the choice intentionally, they didn't do anything (then or now) arbitrarily.

[ToanDN]

A non fire rated and a fire rated door assemblies are different enough to be of different types.  Instance parameters more like a paint color, or hardware group.  It, however, is up to you. Nothing prohibits you from using an instance parameter for fire rating.

[barthbradley]

I stand corrected, @SteveKStafford.

Fire Rating was purposely made a Type Parameter by a Company whose name originates from the phrase "Revise Instantly".

Good to know.  

...love you man.  😉

[KaseyWelles]

My thoughts are that the door geometry doesn't change enough to warrant a different door type. The data included in the model and schedule is what makes a door fire rated in Revit. I believe the efficiency of changing a fire rating instance parameter if a door rating changes is difficult to argue against. Since the door geometry of a fire rated doesn't change, I don't see the value in changing the door type to indicate this. I'm open to criticism though ;). 

Edit: I'll add that not all data deserves and instance parameter. If the data will vary, but the geometry stays the same the data parameter should be an instance parameter to avoid excessive type duplication.