Partly Revit, a lil bit dynamo influenced question. Mostly here for a sanity check.
So some context. There is an OTTB parameter for fire ratings on doors. That is a type parameter. I have always used type parameters for fire ratings on my doors.
it lets me control them all at the same time project wide.
its how you buy the doors. you buy the door panel. the panel has a fire rating. you can’t just change the fire rating of one door panel vs another on site like you would as a finish. its an essential part of the doors make up.
I make one type. I know that type is used on just kitchen doors for example. I put it in all kitchen locations. I know they all have the same fire rating. I change the type parameter, it updates all my kitchen locations if needed.
if its instance parameter. I’m reliant on the user putting the right fire rating, on the right door, instance by instance. for each one. more potential for error. you really don’t want to be adding more potential for error with something like fire.
This is my justification for using the type parameter.
Now the reason why I bring this up. Recent discussion today. I had 2 people say they’ve always made and used an instance parameter on doors for this situation. The main reasoning being. (don’t shoot the messenger as I disagree with this).
But it reduces the number of types for them, so less to manage.
there was a position saying dynamo can be used to change the instance parameter on the doors fire rating based on the wall its hosted in. (but IMO you’d be reliant on running the script every time a door is added / to check what’s in place meets requirements).
there was the thought process that we aren’t responsible for specifying the specific door product, just its required properties. so we should be showing that and leaving the specialist door contractor to determine the types needed (but IMO why not make the types already in revit and know that information of how many variations you’d need before getting to door contractor. Otherwise they’ll just get back to you later if there’s a lot of types they’ll be more work rationalizing them down to a minimum).
fundamentally I disagree with the instance approach. It leaves too much open to human error. if its types I can link them to NBS Chorus clauses as well for each separate door type and there would be a separate system clause for every type. I have more control over them project wide rather than instance by instance as well. But I’m not arrogant enough to think I’m always right. So come here for 2nd opinions.
So that’s the back story and I wanted to see what others do? mainly because if we’re on the same page it will prove my point more!
The actual unit has a rating parameter, which is type driven. Every instance door of that type can have that rating.
But the installed instance has a required rating parameter. It can be driven by the wall in which it sits as you noted.
Let’s say we wanted consistency in terms of look/feel/etc. in the project while simplifying the specification and coordination efforts (all of which is very common things to do). If the door has a 90 minute rating you can put it in the 60 minute wall (yes the nomenclature differs but we can deal with that).
Now for your QA process you get all doors, extract them host, set the required rating parameter, and pop open a schedule showing the rating and required rating for each, highlighting the insufficient or overly sufficient ratings relative to the needs via conditional formatting of a formula cell.
yeah I’ve done similar with walls. there is a max fire rating type parameter on all walls. user has to populate the max on all wall types. and a required fire rating instance parameter allowing them only to colour the instances they care about. if the instance is ever higher than the types max fire rating. it visually highlights it with a filter making it have a cross hatch fill and thick green dashed cut line. so stands out. this has caught out a few people in the past putting wrong wall types or wrong ratings in models.
I get that for walls as you might have a wall that’s max fire resistance is 2 hours. but in one location if only needs to be 30 mins. in another it needs to be 60 mins etc etc. just so any wall penetrations they know what fire proofing sleeves to put on pipes.
But doors. I’ve never used a higher rating than what I need in an area. if it needs to be a 60 mins. I’d use a 60 mins. I wouldn’t put a 60 min door on one spot and highlight it as only needing to achieve 30 mins in plan as I’d be getting more expensive doors where not needed. Plus i wouldn’t treat doors the same way as walls. as its not like I’ll be putting penetrations through a door that needs fire protection around it.so I don’t need to show it having a lower fire rating than what it can achieve for that consideration.
cant justify using instance for it on doors in my head without increasing potential human error
¯_(ツ)_/¯ .
out of curiosity. how’d you typically highlight the doors on plans when doing fire drawings? Instance or type?
As per repeated, super lengthy, previous discussions…
Type all the way.
Main reason : less human error.
A door’s type parameter should match the manufacturer’s fire parameter AND if you also stick the fire rating in the name it’s even harder to mess up.
Safety should always come first.
Where I’m at, we have a instance parameter which is applied to doors, walls, ceilings, floors for fire designation and view templates set up based on this instance. And was historical from before I joined… And they had similar arguments about why… Like cutting down the amount of types etc.
This was all fine when the majority of our work was industrial sheds with limited amounts of internal partitioning. Our business has been evolving and now projects are covering things like shopping centres, residential reclads for HRBs, new build resi, leisure and self storage units where we have a lot more compartments and elements being assigned. Plus exporting the data out in various ways for clients requirements (COBie or other) and also increasingly nbs specs (where as with the sheds it’s just outline specs via notes on drawings for something that will be done as a D&B) is all showing the limitations in the instance approach (it works but is more time consuming in the long term)
