while I was working on extracting data from the IFC, it came to my attention that there is not really a logical connection between the IfcBuildingElement and IfcBuildingElementPart or maybe I lack the knowlegde in this department
What do I mean by that?
An IfcBuildingElement as a structure can be composed out of multiple layers and has a Pset appendet to it. This Pset controls the attributes at the entity level of the building element and has no connection to the building element part. In a simple example, a wall (Masonry + Insulation) as a whole can be LoadBearing, but has no definition which of the layers from that composition is LoadBearing. It is human-readable, since a human can identify that layer either by name, color or even texture, but not machine-readable.
Wouldnât it be more transparent if the attributes of the Pset could be connected to the IfcBuildingElementPart? Or even better, that the Pset are composed out of the level of IfcBuildingElementPart. This way the IFC structure would understand which layer is responsible for which criteria at the Pset Level of the entity, whether it is LoadBearing, Accoustical, FireRating, etcâŚ
Therefore, if one Part of the Element is LoadBearing, it automatically gets transported to the whole entity. In the IfcBoolean world, this would mean that the TRUE statement always wins over the FALSE. In the numerical value, it simply gets transported to a higher instance.
To make matters even less convenient: while an IfcWall can be composed of IfcBuildingElementPart entities, it cannot be composed of say an IfcCovering.INSULATION and an IfcWall.STANDARD.
This also implies that the property sets available for covering and wall entities are not available for the building element parts.
And that may be one of the reasons why many contractors request such elements to be separated into independent entities, each with its own properties. But then the designer loses the notion of the wall as a whole, which still has functions as being room separating, load bearing or providing an acoustic barrier etcâŚ
Add to that the fact that a large part of the users of Revit really prefer to avoid using parts so they model the components as separate Revit elements instead (but then lack the wall as a whole). In contrast, many users of Archicad or Vectorworks are more keen to keep the walls as a whole composite element, since their software has the option to generate the IfcBuildingElementPart upon export.
So you may have inconsistent IFC files due to different software habits.
And finally, many of the values you refer to may actually be a derivative of the IfcMaterial that is assigned to the parts or to the LayerSet assigned to the wall. And materials have their own property sets (although not many viewers even show you this and Revit users cannot even export materials with properties although the software has them natively).
So I believe it could be helpful if parts would be allowed to be real Entities in their own right (IfcWall, IfcCovering), with full support for property sets and be composed of materials, with their own property sets.
Your suggestion to have a type of inheritance or cascade of properties to the higher level is tricky, though, as it would imply a lot of duplication (upon export? by the user? by the viewer?) which leads to ambiguities or even contradictory information. Iâm not convinced that this would lead to clean models.
As an Archicad user, I admit that it is really easy to use composite materials to define a whole structure. It gets pretty good also in IFC. Sadly I cannot say how this works in Revit.
Appending the entity one level lower respectively, to the IfcBuildingElement part, would open the way to connect the PropertySets of the two worlds (IfcBuildingElement + IfcBuildingElementPart)
I have an example here of an IfcWall with a composite structure:
The user defines the entities in his BIM authoring tool for each layer and the composite as a whole. A concrete Layer is always going to be either a IfcSlab, IfcWall, IfcColumn, whereas an insulation an IfcCovering INSULATION. A well-structured database in the BIM authoring tool is necessary. The definition of the entities for the IfcBuildingElementPart should be a global function and not object defined.
Upon export, the Software appends entities and its corresponding PSets (according to IFC) to the Layers and Composites.
In the background, a mapping system should transfer the properties from the IfcBuildingElement to the IfcBuildingElementPart. Here is an example:
In this system there is only one way of override rule, meaning that the upper level overrides the lower level, as long it is not custom defined. The lower level will never override the upper level.
There are different scenarios how this system could work:
A Pset Value from the BuildingElement as LoadBearing can be transported only if such a Pset is available one level below.
PSet Values that are present at all lower levels (BuildingElementPart) will be distributed to all of them in the lower level, as an example the AccousticRating.
A Pset Value at the lower level could override the mapping from the upper level, such as in the case of the âStatusâ. In this case the mapping from the upper level will be disconnected.
If PSet Values are not part of the transfer, they can be left out blank or as ND. This will then be mapped at the lower level.
If the layer at the lower level does not possess an entity or is IfcBuildingElementProxy, no parameters will be transferred if not corresponding.
This also works for a horizontal element such as a IfcSlab that might have an IfcCovering FLOORING inside it. Properties from the upper level (IfcSlab) will be transferred to the lower level of the IfcCovering and IfcSlab.
Yes, there is always going to be a margin of error (user, software, mapping,âŚ). But simply because we are not capable of defining certain parameters, does not mean that it is correct. That is why we have tools to check and correct them, in order to deliver reliable data.
This sounds like a logical approach, but the IFC schema is more restrictive on Parts.
E.g., the Covering enumeration is different from the enumeration for a Part, which only defines INSULATION, PRECASTPANEL alongside the regular USERDEFINED and NOTDEFINED.
If we can have a decomposition of an element into entities (rather than parts), this may be more straightforward. There is apparently an option in the Revit IFC exporter to enable this kind of ânon-conformingâ behaviour, if the user chooses to do so.
I am aware about the restrictions in IFC world, which actually started this topic in my head in the first place
But that is my point, that these two worlds are not really connected. We have components on one level telling you something, whereas the bits and parts of it tell you something else.
The current schema might not be prepared for this concept, but it is worth to discuss the future development.
What are the thoughts of other implementers, users, thinkers @jwouellette@TLiebich@Moult@daviddelven
Iâd wonder if the Authoring tools, especially those operating within the Construction stage, could provide modeling strategies more aligned to a construction sequence-based approach, rather than the âcompositeâ approach that âDesign stageâ seems to force historically the main Authoring tools.
Most of the complaints nowadays, regardless of the typical lack of BIM use strategy definition within contracts, are the unsuitability of Design-oriented information models for pre-construction or construction processes.
I think that a more construction sequence-based approach would help also the Design phase and, therefore, a more accurate (but also cost-efficient) way of modeling.
Is building domain IFC Schema before or after those Authoring modeling architectures?
hi @daviddelven
Some modeling tools are design to work sequence-based in the construction phase, others are not. From what I heard at least, Allplan might be the best suitable. As an Archicad user, I know that this tool is not quite efficient for the construction phase. It is up to the developers of the software to define the roadmap, in which part of the lifecycle they want to concentrate. It is up to the end user to which solution he finds more suitable.
Therefore, my suggestion with the connection of the properties would suit both approaches. Whether you work with composite or single layered materials, the properties would be always there and could/should be appended to each one of them.
Iâm actually quite new to the buildingSMART forum and to IFC as well.
Before I read this post I came to much of the same conclusions. The use of BuildingElementParts is great, looking from a designerâs perspective it is so much easier to design a wall or floor âsystemâ (for example for floors or roofs the same kind of layered approach exists with insulation, screed, tiles, âŚ).
Working for a contractor our focus is more on the individual parts. Purchasing for the insulation is different from the the brick wall. So we need a real different approach.
I have been looking into classifications in order to use those for extracting quantities from a model. In my particular case I have a compound floor containing a âstructuralâ layer of prefab elements with another 8cm of concrete cast on site. I need:
Amount of prefab elements (surface area of the lower layer)
Amount of in-situ concrete (volume of the upper layer)
Amount of finishing (top surface area of the upper layer)
âŚ
Right now I can only assign a classification to the ifcSlab as a whole, not by ifcBuildingElementPart. The same goes for extracting quantities. I can get the volume of the composed slab, which is useless. But the amount of concrete for the top layer I canât get.
I believe that a better approach is needed to make the worlds of designers and contractors meet in the middle!
