Ideal description of a timber frame wall in IFC schema


In a BIM workflow, an architect, or engineer creates a reference model, which is then used as a reference for timber construction design. The wall from the reference model is geometrically defined as a single volume (e.g. SweptSolid).
Timber frame walls consist of many individual elements (members, panels, insulation boards, screws, etc.). Assembled together, these individual elements form a wall in total.

What kind of definitions in the IFC schema do you use to aggregate such construction Elements correctly?

1 Like

IfcWall as an aggregate. You can then contain IfcMembers and IfcCovering as the decomposed parts of that aggregate IfcWall.

or IfcMaterialLayerSetUsage

…if you’re looking to just do layers and not worry about screws or individual studs.

A definition of the wall in layers is not the goal. It is about construction models in timber construction with a high level of detail (studs, plates, screws, etc.) and there are different options available. It looks like IfcWall as an aggregate is the best choice.
Thanks, Michael

Hi Dion,

We currently use this, but the IfcWall must not have any geometry, otherwise this leads to crashes in various software. The wall is used as a container for the components, which together form the wall.

If there is a volume/geometry for the wall and you also want to relate the individual wood components to the wall volume, this could possibly be created with an IfcGeometricRepresentationSubContext.

IfcWall - Containment Use Definition
The IfcWall may also be an aggregate i.e. being composed by other elements and acting as an assembly using the objectified relationship IfcRelAggregates, referring to it by its inverse attribute SELF\IfcObjectDefinition.IsDecomposedBy. Components of a wall are described by instances of IfcBuildingElementPart that are aggregated to form a complex wall.

But if you decompose an IfcWall into IfcBuildingElementPart, the parts cannot be a covering or member or plate anymore?

Hello, Michael

Have you considered IfcElementAssembly?
IfcElementAssemblyTypeEnum (

This is normal and how aggregates work. The aggregate itself’s Body geometry is the sum of its parts. Your IfcWall will not have geometry, and you can use IfcMember, IfcCovering, IfcMechanicalFastener, etc for its parts within the aggregate.

Why is this solution not sufficient for you?

Using IfcGeometricRepresentationSubContext is not what you’re after I think. The context is always Body.

Thanks for the helpful reply.
I also see this solution as the most suitable.

In some cases, the geometry of the wall is required in addition to the individual components. This happens especially when you want to continue modeling with the elements (Design Transfer). In timber construction software, you often work with envelopes (volumes that represent the wall), which then contain the individual components.

Thanks for the link. This can be very useful for truss constructions and the like.

1 Like

This additional envelope may be represented via either the “Surface” non-body geometric context. Aggregates only disallow the body context of the whole, but not other contexts.

For other types of decomposition breakdowns, you may be interested in IfcRelAssignsToProduct. I am not aware of any BIM authoring software which implements authoring of this yet, though.


I was wondering if ShapeAspect is yet another way of product decomposition? :thinking: That way one can get both the whole geometry and named parts geometries. Parts as separate IfcProducts are lost though.

1 Like

I think you’re right. I have never seen anybody break it down to this level though and expose it meaningfully to the user. However, the disadvantage is that the individual shape aspects are only identified by naming convention, which is hard to standardise, in contrast with a decomposed “IfcMember”, “IfcCovering”, which is very clear what part is what.

Hi Dion,

I have made a attempt to use the IfcRelAssignsToProduct here. I am looking forward to the feedback :wink: .

IfcRelAssignsToProduct.ifc (5.3 KB)