Hello all,
I’m trying to wrap my head around the decomposition and nesting for Building Elements in general. I work for a general contractor, we mostly deal with the structural/architectural domain.
On a couple of occasions I have wondered upon this subject and now I’d like to know if I have understood correctly. When comparing to object-oriented programming, the terminology of “Parent” and “Child” relationships comes to mind. I’ll continue that terminology during the remainder of this post.
So I looked up the ifcRelAggregates and ifcRelNests. As much as I understand both serve the purpose of combining “child” elements into a single IFC “parent” element that has it’s own properties. The difference between both is that with Aggregates, only the child elements have a geometry while with Nesting there is the geometry of the parent as well as the child elements.
There are a number of specific examples where I would think this is very useful:
- Phasing of (wall) elements:
(a) In a concrete structure it is the standard methodology that a wall is modelled as a single element, that might be 50m or even hundreds of meters of length in a single element. In reality however these walls will be constructed in multiple phases. During the design it is interesting to postpone splitting phases as long as possible because such things will change. Either depending on the contractor or even depending on the progress and planning on site. In this case I think it would be very useful to have the “Nesting” relationship. The parent element can contain the geometry of the entire wall, which can be used for coordination, clash detection, … Once the phasing is known the child elements can be created by splitting the parent. However for the coordination it seems it would be necessary to keep the parent (because of it’s unique ID) to trace the entire history.
Important note here is the relationship between parent and child: the modelling software should take care of perfect synchronisation of it’s geometry. For example when creating drawings for a specific child element (=construction phase) which must align with the geometry of the parent element.
Second question here would be: how does an IFC viewer handle such geometry? Will it show only the child or parent? Or both? Could be similar to the concept of assemblies (like I see them a lot from Tekla models)?
(b) A very similar example could be wall panels. We do a lot of projects with precast concrete wall panels (single layer or sandwich panel). In the “Architectural” design this is modelled as a single wall. In production it’s split in separate elements. I identify two main differences with the first example 1(a):
- In this case the geometry will probably differ between parent and child. The child elements will allow for some margin (space between child elements) and might be in a higher level of detail for production purposes;
- Parent (single wall element) and child (individual panels) will probably not be in the same model or even in the same modelling software.
- Layered wall/floor elements:
For multi-layer floors and walls there is the concept of “IfcMaterialLayerSetUsage”. In my opinion this falls short on two major reasons, but please correct me if I’m mistaken:
- I don’t find any documentation related to quantity takeoff. For a wall/slab there are the Qto_WallBaseQuantities or Qto_SlabBaseQuantities that contain volume area. As a contractor, that information is very important to us (both gross as well as net). However this is not useful on a compound wall/slab, certainly when it comes to volumes (area will usually be more or less similar for all layers). How should this be handled when using the ifcMaterialLayerSetUsage?
- Classification: This is used for a couple of reasons, one is related to the quantity takeoff. Using an ifcClassification makes it very easy to compose a qto schedule. But we need this link to every “material” separately, is this possible on the ifcMaterialLayer?
Second use of the classification is in the coordination. If a compound wall consists of both in-situ concrete and some insulation then it’s important to do clash detection on the concrete and not so much on the insulation. We should be able to identify these individual layers somehow.
I am wondering if a decomposition with ifcRelAggregates wouldn’t be more logical. That way every child element can have their own specifications, properties, quantities, … but still the concept of the “compound” wall/slab remains.
I have found examples of software that export to IFC with the parent being ifcSlab and the children all be ifcBuildingElementPart. This is very close to what I think would be best, but I’d rather see the child elements also be ifcSlab. Or maybe ifcCovering?
Is it currently allowed to have an ifcWall decomposed with some child elements being ifcWall and others ifcCovering?
- Stair assemblies:
In the documentation I found that an ifcStair can be decomposed by its ifcStairFlight, ifcSlab (with predefined type Landing) for the landings and eventually the ifcRailing. This makes a lot of sense to me!
However, in reality I think it’s even more complicated, certainly for steel stairs (maybe wood as well).
What I see when receiving IFC models with steel stairs is that every “manufactured part” is a separate assembly containing for example one or more ifcBeam and some ifcPlate. For the fabrication drawings and the assembly on the building site this makes sense. In the (IFC) building structure however it doesn’t.
Would it be possible (/allowed) for an ifcStairFlight to be decomposed by these assemblies, with each assembly in turn having it’s own decomposition? Then the ifcStairFlight would contain some more general properties like number of risers and treads, riser height, tread length, …
I’d like to end with a not on the general “ifcElementAssembly”. I can see the use for it though shouldn’t it be avoided as much as possible just because it is so generic? I get it’s “easy” in the implementation of the ifc export in a modelling application but it causes an ifc model that is not very readable by the user.