Fire rating for door - type or instance?

[damon.sidel]

Age old question? Or has it been answered satisfactorily?

Revit OOTB doors have a type parameter for Fire Rating, right? But we often have the same style and size of door, one that is rated and one that isn't.

What is your best practice?

[htlmv]

I'd say instance.

[Yna-Db]

Hello,
As discussed in another forum, an instance parameter would let Dynamo fill the value automatically from the host wall values. It can be useful in some cases.

[damon.sidel]

Thank you both for your reply.

[david_peterson]

We do them and have done them by type. It changes the door.
We then use a view filter to in our LSPs to verify the color matches the wall.
We also have a working view set up that shows a similar thing.
Since the Rating of the door doesn't need to match the wall....in some cases... it could be difficult to script.
We did it so it was harder to change on accident. If its an instance parameter, yes you can use dynamo to fill it out, but anyone can very easily change it by selecting a wrong field in the properties box.
Just my opinion, but I'm not a big fan of Instance parameters in doors in general.

[Yna-Db]

Interesting account. I saw recently this thread about a changing color annotation (http://forums.autodesk.com/t5/revit-architecture-forum/how-to-toggle-a-symbol-within-a-tag-based-on-parameter-values-of/m-p/6651851#M130405) and this is were I started from : a fire-rating plan with all information visible.

[patricks]

Hello,
As discussed in another forum, an instance parameter would let Dynamo fill the value automatically from the host wall values. It can be useful in some cases.

Door ratings don't always match wall ratings. A 1-hour wall could require a 20 minute, 45 minute, or 60 minute door, depending on the function and location of the door. 2-hour walls typically have 90-minute doors, and 4-hour walls typically 3-hour doors, as examples. So I'm not sure how useful that would be.

We always do fire rated doors at separate types. I don't think it's ever been an issue for us. You can't really automate what goes where. It takes someone checking the code and making sure it's correct, which someone should be doing anyway.

[Yna-Db]

Hello,
Type or instance parameters can equally be reused through Dynamo once they are set. See here for instance, a way of placing automatically a symbol according to FR value: Place detail family as symbol for fire protection values of doors (https://forum.dynamobim.com/t/place-detail-family-as-symbol-for-fire-protection-values-of-doors/7287)

[damon.sidel]

We always do fire rated doors at separate types.

Do you see any reason NOT to do it as an instance for all the same reasons you are discussing the individual nature of each location?

[damon.sidel]

We did it so it was harder to change on accident... but anyone can very easily change it by selecting a wrong field in the properties box.

Would it be fair to say then, that your primary reason for making it a Type parameter is to help control who changes it? Are there any architectural/design reasons beyond that?

So far, I haven't heard any overwhelmingly compelling reasons one reason or another, which is totally fine.

Here's how I often think about type vs. instance: my contractor will be ordering 50 doors. For this simple example, let's say they are all the same size, material, and style: flush wood doors that are 36"x84" with hollow metal frames. Four of these doors are fire rated for 90 minutes. When s/he orders them, is it 50 of door A, of which 4 have a 90-min fire rating feature? Or is it 46 of door A and 4 of door B? Usually, this is a pretty simple scenario, because I use this example to explain types and instances to newbies and talk about a flush door vs. a door with glazing. Clearly those would be ordered as door A and door B.

Thanks for all the good thoughts!

[david_peterson]

Would it be fair to say then, that your primary reason for making it a Type parameter is to help control who changes it? Are there any architectural/design reasons beyond that?

So far, I haven't heard any overwhelmingly compelling reasons one reason or another, which is totally fine.

Here's how I often think about type vs. instance: my contractor will be ordering 50 doors. For this simple example, let's say they are all the same size, material, and style: flush wood doors that are 36"x84" with hollow metal frames. Four of these doors are fire rated for 90 minutes. When s/he orders them, is it 50 of door A, of which 4 have a 90-min fire rating feature? Or is it 46 of door A and 4 of door B? Usually, this is a pretty simple scenario, because I use this example to explain types and instances to newbies and talk about a flush door vs. a door with glazing. Clearly those would be ordered as door A and door B.

Thanks for all the good thoughts!

The main reason we do it, is because it changes the door assembly. Fire rated doors are generally constructed differently and have different hardware requirements.
Also because it's slightly harder to change.
Finish on the other hand.....should be instance in my opinion by I could make the same argument there. I started in structural so I don't mind type parameters and families with lots of types as long as you have a good standard naming convention (which we have)
A door panel can be made of wood and painted several different colors. Changing the color or the finish doesn't change the construction of the door. If I need to have a door that's rated it requires smoke seals and may require a different frame set. We also do Negative pressure doors and make those as a type parameter as it can also change the construction of the door.
When doing large healthcare facilities you end up with a ton of doors that all need some type or rating. I'd rather place a door with that information already filled out vs having to add it to each individual instance. Plus when I start coping doors, if I copy one that happens to be rating, each instance I place will have those same settings and I may be placing rated doors accidentally because I didn't see it in the type name.
Our door naming conventions contains 95% of the type parameter information in it. So when I place a door I know exactly what I'm placing.

Just my thoughts. We went round and round with a lot this "Instance" Vs "Type". And sometimes giving to much freedom when people are on and off of projects can cause some issues. So we really try to keep the KISS method applied. Plus in my mind it only takes about 5 secs longer to create a new type vs change an instance.
Just my 2 cents.