Guidance in assigning Class & Type for Wall/Floor components

We are preparing guidance document on correct application of classes, types and classification codes for exemplary elements.

When I take the example of a Cavity wall, how would you classify the different layers, when assuming all layers are modelled as separate components?

Does this seem correct?

  • Outer Brick Layer: IfcCovering.CLADDING
  • Air Layer: What class should I use here? Or do we simply not model it at all?
  • Insulation Layer: IfcCovering.INSULATION
  • Inner Brick Layer (structural): IfcWall
  • Inner Plaster Finishing: IfcCovering.CLADDING

Similarly for a composite floor:

  • Floor Finishing Layer (e.g. Tiles): IfcCovering.FLOORING
  • Screed Floor: IfcCovering.FLOORING
  • Insulation Layer: IfcCovering.INSULATION
  • Concrete Slab: IfcFloor.FLOOR (or BASESLAB?)

Is it possible that you’d create an IfcWall and have these layers as separate parts, yet still retaining their Main Class? E.g. when exporting a composite wall/slab to IFC from ARCHICAD I can generate Parts, but they all become “IfcBuildingElementPart” classes.

[off topic] I see you’re using SfB naming/classification. Have you seen this more detailed codification of SfB? http://www.bim7aa.dk/BIM7AA_Typekodning_UK.html

Yes, it gets complex quickly! I’d generally do the same approach as you, but I have my own questions to add on top!

By the way, as for your question “Is it possible that you’d create an IfcWall and have these layers as separate parts, yet still retaining their Main Class?” I see two ways:

  1. Don’t worry about it! You’ve already defined IfcCoverings and an IfcWall. Remember, that an IfcCovering has a CoversElements relationship to the IfcWall, so your model should already relate all the layers of the wall together. Therefore they are all defined correctly, and people understand when they see the IfcWall's property Pset_WallCommon values for fire and acoustic rating that it applies to the full system of layers … or, uh, do they? Hah :slight_smile:

  2. If you are worried, use IfcMaterialLayerSet with a Path Connectivity set, but that’s only good enough for simple junctions. Not “separate parts” physically, but still defined separately :slight_smile:

My own questions

  1. Personally believe air should not be modeled, but how does one then detect the air layer for its acoustic and thermal properties?
  2. It should be IfcSlab, as IfcFloor doesn’t exist. Whether or not it is .FLOOR., .ROOF., .BASESLAB. etc depends on where it is in the building (e.g. suspended slab is .FLOOR. and slab on ground is .BASESLAB..
  3. If an air layer isn’t modeled, if you want a simple version of the model where all ways are represented by a massive extrusion rather than composite layers, it will create an unsightly gap. We’ve run into this problem where I work. Has anybody actually applied the Surface Geometry concept in practice to overcome this?
2 Likes

To return to this discussion…

  • Is it allowed in IFC to have a container “IfcWall” with no geometry and have parts using a Decomposed Relationship that are not IfcBuildingElementPart but specific classes, such as IfcCovering?
  • If not, can you have an IfcWall with full geometry and properties at the element level and still have parts?

I don’t think these cases are allowed, but I could be wrong.

Problem is that we need a full layered wall for thermal calculations (including the air gap layer), whereas the contractors prefer to have the individual parts for costing and planning. But if the whole model only contains IfcBuildingElementPart, you loose much of the semantic richness of IFC…
E.g. IfcBuildingElementPartTypeEnum only contains two types

https://standards.buildingsmart.org/IFC/RELEASE/IFC4/ADD2_TC1/HTML/link/ifcbuildingelementparttypeenum.htm

That said, I’m not even sure if there is even a way to generate this from common BIM software… So maybe the answer is: “You don’t and make separate exports”: one with composed, multi-layered elements and another with empty containers and parts. And maybe a third one where there are only the parts as specific classes (but no containers).

Clearly I don’t think that this is the approach we want to adopt.

bSI and software vendors should think about it and find the best way

Current approach is not suitable in many cases/scenarios

Many building elements/objects have a lot of granular parts (layered/none-layered) and cause a lot of issues
One of the popular issues related to wall is most of the times there’re two walls to represented a wall which is incorrect

To come back to this discussion again. I completely agree with stefkeB! An ideal situation would be indeed to have the ifcBuildingElementParts replaced by their representative ifc class. I didn’t see a reply, would this be allowed?