Export a single-layer wall as IfcElementPart

[LauraResta]

Hi,

I am in a research project, and we are trying to export all the wall layers as IfcElementPart. The problem comes when the wall is made of a single layer. I have created the walls both as a single-layer composite and as a basic wall by applying a material… and in both cases, they are always exported only as IfcWall, with no element part. I have tried to dive into the IFC interoperabilities to find a way to achieve this, but I have not found any option for it.

Does anyone know if there is a way to do what we need?

[Nathan Hildebrandt]

It might have something to do with your classification settings in Archicad, and then the Element Type mapping that you have in your IFC translator. If you are exporting your IFC and the wall is not classified and mapped to IfcElementPart then it might be the issue you are facing?

[LauraResta]

Thank you for your response. I've been thinking about your solution, but the problem I see is that if I do what you propose, I lose all the IfcWalls, am I wrong? My intention is to keep the whole wall as IfcWall and the layers (even if it only has one) as IfcElementPart. I don't know if it's viable.

[Nathan Hildebrandt]

If it is a single layer you won’t get both I believe.

You could add some additional layers of air say and check them as do no participate in collision and select only elements that participate in collision to export. 

clutching at straws here to think of ways to work around what you are trying to achieve. 

[thesleepofreason]

I reckon this is a limitation in the translator. Splitting a complex element (composite/profile) into multiple IFC entities only work for composites/profiles with multiple skins/components.

So the next approach would be to use a placeholder material/component which would trigger the split but not be exported. This doesn't work as the export selection seems to be done on the parent element which then is split. Even using PSD to only show what you want in AC and then export won't work - it simply drops the information about it being a part and treats is like a whole.

So this leaves you with using a placeholder material than you either can accept in the IFC model or that you delete from the IFC model, using another application, to get the correct structure.

[Johan Stinckens]

For me this is not a limitation, but a functional bug!

AC26 has brought us the long awaited Component-level property mapping, which is great!

Sadly GS has somehow omitted it for use in single-skin components.

We've got all building materials classified. For multi skin composites/profiles we are able to read this material from the composite-skin. For single skin composites we need to attach the building material to the element! This means we need to create seperate rules for checks or ITO's.

Really hope this will be resolved in the next build of AC26!

[Zoltan Vale]

I am happy to give you hopefully some good news regarding this topic, especially to @Johan Stinckens . We also found the limitation with using component-level properties on single-skin elements/composites, and we already addressed this issue to make the entire workflow better and more understandable. You can expect these updates in the very near future.

As with the original post, @LauraResta I am having a bit of trouble understanding your use-case. Can you please help me see more clearly why exporting IfcBuildingElementPart to single layer wall is essential in your workflow? According to the IFC schema : "IfcBuildingElementPart represents major components as subordinate parts of a building element.". It seems to me, more of a schema mis-usage than a bug, but please help me out with a bit of context for your issue.

[Bojan Fratina]

Have any solutions to this issue been implemented?

I am currently working on an .ifc export of a project in AC27. Properties that are defined for building materials get exported for individual skins of multi-skin composite walls but still don't get exported for basic walls or single-skin composite walls.

[Bojan Fratina]

So, I have done some more testing.

When exporting to .ifc, if the translator is set up to split composite elements and export each individual skin, then each skin will get the properties that are set for its building material. However, in case of basic elements (non-composite) and in case of composite elements with a single skin (this includes composites with multiple skins where only one skin has a non-zero thickness), the properties set for the building material get ignored and only the properties set on the element itself get exported.

The only exception to the above that I have found is if a single-skin element is not classified in any classification system. In this case, the translator will use the properties from the building material of that element when doing property mapping to .ifc. However, the type mapping won't use the building material classification, so the element will be exported as IfcBuildingElementProxy, no matter how the building material is classified. So this isn't a fully functional workaround either, as I want my walls to be classified as ifcWall in the exported .ifc.

As is, the only solution that works for me is to set the properties on the single-skin elements themselves, which is more work and more error-prone than just setting the properties once for the building material.

[Laszlo Nagy]

I recently looked at BlenderBIM for a bit, which is an open-source free software, as you guys might know. One of the interesting features I found was the ability to open an IFC file in BlenderBIM and modify any data within the IFC file. You can even write and run Python scripts to do it.

Reading this thread, I was just wondering if this is something that could be done in BlenderBIM - open the IFC exported from Archicad and modify the IFC data so the single-layer element becomes an IfcElementpart entity in the IFC file.

I don't know the answer to this question, I am just aware of such capabilities in BlenderBIM.