Door diagrams are incorrect

[trhyder]

It is possible that I need to go back to grad school, but I think there is one fundamental issue with a diagram on 7.1.3.2 IfcDoorPanelProperties.

The door panel is incorrectly positioned for a swing door to actually swing open. In the documentation, the door panel is positioned on the face of the door frame. It would be impossible to hang a swing door like this with a common door hinge without the hinge and panel binding with the frame. Instead, the door panel of a swing door should be positioned flush with the wall and between the frames.

The incorrect position of the door panel also repeats in 7.1.3.1 IfcDoorLiningProperties where the door panel is also incorrectly positioned.

[aothms]

Thanks for taking the time to report this. IfcDoorPanelProperties is actually deprecated now. The mechanism of predefined propertysets as well as the idea of deriving geometry from property values didn't really take on. I will double check how relevant these diagrams are in the new context, but we probably have lost the source for these by now and I'm not sure whether it's important enough the address. If you find more of these, please keep reporting them. All help is welcome in improving the quality of the documentation.

[trhyder]

Thanks @aothms for the update. Am I perhaps looking in the wrong section? How is one to know that IfcDoorPanelProperties is deprecated? It looks like an active page to me.

https://standards.buildingsmart.org/IFC/RELEASE/IFC4_3_0_0/lexical/IfcDoorPanelProperties.htm

I think it would be important to correct the diagrams, as I have seen that Blender Bim has used these, leading to an incorrect representation.

Also, if the originals are lost, I am happy to provide updated diagrams.

[Moult]

I agree that the diagram looks wrong because it doesn't represent a standard door frame. However I never questioned it because I assumed it was purely a theoretical diagram to show how the LiningToPanelOffsetX/Y should work at its extremes. In real life, we would never set OffsetX to 0, and OffsetY would be set such that the door panel sits between the frame as you suggest. Like this:

What does however grind my gears is that the spec isn't explicit on how these very common metal door frame rebates are created:

You can make some assumptions like if the door OffsetX and OffsetY "eats" into the lining, then the lining gets a rebate there, but that doesn't explain how to do double rebates (which you can abuse the casing to get, but it's still dodgy). (there are also more measurements if you want to describe the various lips and turns in metal jambs but I guess that was out of scope)

This is definitely an important part of the specs to fix. Even though IfcDoorPanelProperties as a parametric "geometry generator" is deprecated, it's still relevant as a property set and how the properties relate to real life measurements are critical in producing meaningful door schedules.

[Moult]

Ping @TLiebich do you know the history behind how these parameters were decided and why it's so hard to create seemingly "standard case" single / double rebate jambs? (btw I've never detailed wooden door frames, only metal ones, so maybe there's something different about wood that I'm missing here)

[TLiebich]

as far as I recall, it was a theoretical figure to show the parameters (potentially misleading to a practitioner). And it was more dealing with a schematic parameterisation (and not to the detail of material specific, e.g., steel, linings).

since it has been deprecated and transformed into a Pset, now more "reporting" design parameter (and not trying to parametricallly generate its geometry) the question is, which remain relevant.

[trhyder]

While it would be nice to show different parameters like frame profiles and materials, my reason for reporting this as an issue is that the theoretical figures appear to be wrong. There are a number of related issues but I think the main ones have to do with the casing and its relationship with the lining and door panel.

The casing in Figure 7.1.3.1.C, is shown to have a relationship with the door panel width (Lining to Panel Offset X). This results in a reduced casing representation on the door panel side when the Lining to Panel Offset X is less than the Lining Thickness. There should not be a relationship between the casing and the door panel. Instead, there should be an offset x (and an offset z for the header frame) relationship between the inside face of the lining (door frame) and the position of the casing. Having a reduced casing representation on one side is undesirable, and makes querying the casing from the door parameters different from the geometry.

Also, as there appears not to be an adjustable parameter relationship between the casing the the lining (door frame), the diagrams show a fixed condition that is never desired. Rather than the casing being flush with the inside face of the lining (door frame), the casing should be offset in the x direction (and z direction for the header).

From my perspective, these errors in the theoretical diagrams have resulted in casings being unusable in Blender BIM.

[Moult]

@TLiebich can I propose that @trhyder design a new set of parameters/diagrams (can be really rough sketches for now) with something that is more appropriate? Where possible, parameter names should be reused, but where it doesn't make sense, new parameters should be invented.

[TLiebich]

sure please go ahead an create a more uptodate and sensible figure

[trhyder]

Thanks for the opportunity to contribute. It's an exciting prospect, but before I dive into the details, I wanted to first raise the idea of introducing new properties that could receive profile types.

As highlighted by @Moult, the ability to efficiently manage pressed metal frames without messing around with casings or other parameters, just to get something to look rightish, would be an invaluable addition. This enhancement would simplify the modeling process and significantly enhance the data's value, especially in the context of generating door schedules.

What are people’s thoughts on this? Would this be a good direction?

[Moult]

As highlighted by @Moult, the ability to efficiently manage pressed metal frames without messing around with casings or other parameters

I would love this :)

I think door hardware guys would love it too.

[trhyder]

Hey, I have done a first pass at a proposal for adding profile/mesh properties to the door parameters. If desired, the new properties could work with the existing ones. This could be achieved by establishing a hierarchy of first using the profile, and then, if empty, using the existing parameters. I have done my best to get up-to-speed with all the connecting parts - a lot for me to learn here. I am sure I have missed something or not properly understood something, so please feel free to correct my assumptions/errors. For the moment I have mostly had single swing, pivot, and face sliding doors in mind.

LiningProfile

A new property for the profile that includes the combined lining(frame) and casing geometry. The lining consists of three extrusions - the left and right sides and the header. The relationship between the local origin and the profile determines the gap between the wall opening and the frame.

Instead of one property LiningProfile could be separated into JambLeftProfile, JambRightProfile, and JambHeadProfile. Where if JambRightProfile or JambHeadProfile were empty, their geometry could be sourced from the JambLeftProfile.

If empty, the lining geometry could revert to the existing parameters LiningDepth, LiningThickness, LiningOffset, LiningToPanelOffsetX, and LiningToPanelOffsetY, CasingThickness, and CasingDepth. If LiningDepth is empty, no frame exists.

💡 By using a profile input for the lining (frame) the following is achievable: - The profiles can be moved along the x-axis to create a packing gap. This achieves an opening in the wall that can be used as the ‘rough opening’. - Casings can be included in the profile geometry. - Door stops can be included in the profile geometry without needing to subtract the door panel. - Profile types can be used for generating more data-rich door hardware schedules.

TransomProfile

A new property for the profile of the transom frame member. The height of the profiled transom can be positioned vertically by the existing TransomOffset property. If empty, the transom geometry could revert to the existing parameters TransomThickness and LiningDepth. If empty, no transom.

💡 I am not a huge fan of transoms being part of the door. I am not sure how the geometry is meant to work with the current lining and casing properties and I think the use cases would be low anyway. It would also have limited usability with the proposed `TransomProfile` property as in reality there would be a different frame profile for the jambs below compared to the frames holding the transom glass above. Can transoms be deprecated, or does it need to be figured out?

ThresholdProfile

A new property for the profile of the threshold. If empty, the threshold geometry could revert to the existing parameters ThresholdThickness, ThresoldDepth, and ThresholdOffset(Y) If ThresholdDepth is empty, no threshold.

💡 If a profile approach is to be used, I think two additional properties `ThresholdWidth` and `ThresholdOffsetX` would also be needed to position and size the the width of the threshold correctly. I guess these could be determined by calculating intersecting geometries with the linings. If this is not the best direction, another approach would be to not store a profile but instead store a custom mesh. By using a profile or mesh approach the following is achievable: - The threshold could be scheduled as a type in a door schedule.

PanelMesh

A new property for the custom mesh that defines the geometry of the door panel. The input mesh independently defines the panel’s width, depth, and height as well as its relationship to the bottom center of the overall door. If empty, the door panel geometry could revert to the existing parameters PanelDepth, LiningToPanelOffsetX, LiningToPanelOffsetY, and PanelWidthRatio.

💡 The geometry from the PanelMesh should not influence the geometry of the frame like the `LiningToPanelOffestX` and `LiningToPanelOffsetY` does. By using a Mesh approach the following is achievable: - The door panel is completely customizable. Paneling, glazing, and even a door handle could be added. - Tolerance gaps and undercuts can be accounted for by undersizing the panels and elevating their geometry above their local origins. - The door panel could be scheduled as a type in a door schedule.

[Moult]

IFC does not currently have any precedent for using parametric profiles to define a shape (other than material profile set). Adding this feature in IFC is quite a big leap from where IFC stands today. (not saying it should be done, simply saying that I'd recommend starting smaller and fixing the simple properties first)

[aothms]

I agree with @Moult. I would say the simplest way forward is that we identify the names of these parts such as "Threshold" and nominate them for constituent labels in accordance with this template https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/concepts/Object_Association/Material_Association/Material_Set/content.html

This would mean you would model your door as a single element and use IfcMaterialConstituentSet IfcShapeAspect and all. You would model these as extrusions of profiles.

Alternatively we could propose a standardized mechanism to decompose doors into actual parts, but this seems to be something not actively done now so we don't have a starting consensus in what entities to use to decompose into. E.g a Threshold is that an IfcMember (probably too much structural focus) or an IfcBuildingElementPart (too generic) or an IfcDoor (too much focussed on the operation of the door in its entirety). In the long term (say IFC5) this will mostly likely be the way though, where geometry will likely live on the type instead of the occurrence so decomposed instances is much cheaper and more natural.

[trhyder]

Thank you both for your feedback. @Moult there are a lot of interconnected relationships, but I will do my best to start smaller and fix the simple properties.

Before I post some proposed fixes and new parameters I did want to touch on @aothms comments. Although not simpler I do prefer the alternative proposal to decompose doors into their parts. Two main benefits stand out to me here. Firstly, being able to store the materials for the individual parts. For example, it should be possible to have a door that has a metal frame, a glass door panel, and a stone threshold. Secondly, being able to assign different statuses to the parts. For example, if I want to put a new door in an existing wall the wall hole opening should have the status DEMOLISH and NEW, and the other parts of the door should only have the status NEW.

Regarding the parts, I am not sure what’s involved in getting condenses on the parts but for what it's worth I would think thresholds, linings, and casings would have the entity IfcCovering, and the door panel would have the entity IfcDoor.

I am not sure I see the point of creating labels that aren’t tied to specific geometries. @aothms, can you explain what the value would be? In BlenderBIM I do like the parametric door approach primarily for scheduling, however, the current errors and limitations mean that it doesn’t work well, but I believe these could be fixed to be more useful. Furthermore, if an IfcDoor were to become a combined group of meshes that don’t know their individual parts, I feel that this would be a step backward. Can you please explain more about what the benefits would be of using constituent labels?

[Moult]

@trhyder I think you may be getting lost in the details of what @aothms is describing - don't worry: with both approaches you can have different materials for different portions of the door, as well as have a different status for the opening versus the door. Also having a door as a single object is not mutually exclusive with having the door as an assembly of parts.

Would you be interested in having a short call to go through it together verbally? It might be easier to explain and I can also show things on the screen. I'm in the Sydney timezone.

[trhyder]

@Moult I think a short call would be greatly beneficial. I'm in Boston so the best overlapping times are probably 8am to noon, your time.

[trhyder]

Hey @Moult , I messaged you on Element, but perhaps that's not the best place to contact you. How would you like to setup a meeting?

[aothms]

Any updates on this?

[trhyder]

Moult was gracious enough to give me a brief introduction to the current state of play. To avoid getting bogged down in the details and to bring everyone along progressively, we discussed first gaining consensus on what the ‘base’ parameters of a door should be. The ‘base’ parameters are what every IfcDoor requires to be a door, they should be simple to understand and useful for scheduling. Beyond these, any other parameters should be optional and off by default (ie thresholds, casings, etc. ).

Based on the Building Smart definition of a door the base parameters must be able to define the ‘lining’ and the ‘panel’. This is where I would first like to pause. I would like to question whether we have the opportunity here to better align the parameter names with industry terminology. To my knowledge, using the term ‘lining’ is unique to Building Smart. As a practitioner, I would use the term frame to define the side and top members of the door assembly that is to be fixed into the wall and that supports the door panel via a hinge. My proposal for the ‘base’ parameters below uses the term frame, rather than lining.

DoorOperationType: SINGLE_SWING_LEFT

FrameWidth: The outer dimension of the side frames. Must be a positive value.

FrameHeight: The outer dimension of the frame head from the base. Must be a positive value.

FrameDepth: If omitted, is equal to the wall thickness.

FrameMaterial: The IfcMaterial for the frames.

PanelWidth: The inner dimension between the two side frames. Must be a positive value and less than or equal to the UnitWidth. If equal to the UnitWidth, there are no side frames (frameless).

PanelHeight: The inner dimension of the frame head from the base. Must be a positive value and less than or equal to the UnitHeight. If equal to the UnitHeight, there is no frame head.

PanelDepth: The dimension of the door panel thickness.

PanelMaterial: The IfcMaterial for the door panel.

I am intentionally proposing FrameWidth and FrameHeight over OverallWidth and OverallHeight to cater for additional details like casings that should be included in the overall bounding box of the door but excluded from this parameter.

I am proposing PanelWidth and PanelHeight as two new parameters as these are primary parameters in a door schedule, that are used for code compliance assessments and should therefore have direct inputs.

The consequence of this approach is that the frame thicknesses become calculated parameters. But I think is a good thing. As a practitioner, I want to specify the exact door leaf size, because they are generally available in known standard sizes, and I want the frames to be treated as nominal sizes, to allow for gaps and rebates that I can cover in a detail rather than in the whole model.

I have also proposed FrameMaterial and PanelMaterial, as these have been requested in BlenderBIM and would be beneficial for scheduling.

What do people think?

[macedonianluke]

It gets a bit confusing with curtain panel doors(doors fixed off mullions) and also pivot doors with no frame.

Agree yes your door and frame width/ height would capture most cases in my understanding.

Perhaps add framed or not framed.

Not framed(insert better term) would be panel size and opening size.

Thinking out loud here.

[trhyder]

Good point. I think in that case I would propose using the parameter labels UnitWidth and UnitHeight, instead of FrameWidth and FrameHeight. Where if the FrameDepth were to equal zero the door would be frameless. That way we avoid adding a new parameter for a unique use case. This would mean that the nominal frame (not the exact frame) would be the boolean subtraction of the panel from the unit.