IFC tool performance: normalization and round-trip preservation as enabler for BIM-Level 3-CDEs

[Herb]

Originally coming from automotive electronics industries, I am trained in creating efficient embedded solutions (small electronic circuitry, small code, small data, …). It is painful to see resource-hungry solutions beeing a matter of course in software-industry.

The time has come to release the parking brake instead of installing more and more powerful engines.

After this general statement I step directly into technical details:

WHY do you destroy my IFC?
Testcase: IFC model with 1 project > 1 site > 1 building > 4 storeys > 16 walls > 64 windows of same type
Testcase IFC model and file have been generated by PostgreSQL functions

Round-tripping on three important authoring software tools resulted in similar disillusioning outcomes:

• The round-tripped model looks almost identical to the original model (in Xbim Xplorer)

• The round-tripped model is differently structured based on different representation paradigms, de-normalized (64 windowtypes instead of 1) resulting in bloated IFC files.

Sounds like “issues with particular proprietary products”? Yes and no.

Here I would like to discuss and sketch future goals and ways towards conservative IFC processing.
Conservative IFC processing is an enabler for BIM-Level 3-CDEs and shall be addressed to ALL software vendors.
With conservative IFC processing there is NO CHANGE in the IFC model on a round-trip “L3-CDE > IFC > authoring software > IFC > L3-CDE” if there is no explicit planning step. (e.g. IFC eport immediately after IFC import).

Before bothering you with too many details, I will step back and await your valued comments.

[Herb]

By the way,
as BIM-Level 3-CDE functionality relates to “partial model exchange” mentioned in IfcOwnerHistory (IfcStateEnum and IfcChangeActionEnum):

From tests I recognized that at least ChangeAction seems to be not supported by common authoring software, although the concept exists for more than a decade!

Does anyone have information about the destiny of the “partial model exchange concept”?

Does anyone have a link to a bS roadmap covering this and other concepts for the next decade?

Latest in year 2030 the huge IFC container transfers (Level 2) should be definitely history, right?

[ReD_CoDE]

Good I see more and more considerations to existing issues

And I think during the last six months I mentioned the majority of these issues

IFC has developed based on 80’s ideas, so its base is weak for today requirements, especially BIM Level 3

I think “modeling and simulation-based systems engineering (M&SBSE)” is the future of OpenBIM and BIM

And we work on MaterialPass, ProductPass, and FacilityPass based on Modeling and Simulation-Based Systems Engineering

[Moult]

@Herb As you have discovered, most BIM platforms do not support partial imports and exports, to prevent the data loss you are describing. As you’ve also discovered, the implementation of owner history (and therefore change history) is also lacking. I agree that this is a huge problem that needs to be solved.

I do not see this issue as a technical challenge, but simply that of will. It is slightly tricky, but possible for an authoring tool to perform a partial write to an IFC file. Vendors need to step up their game.

I recently implemented a partial import function into BlenderBIM, as well as diff detection. This is not what you’re looking for, but was necessary to implement some of the under-the-hood before I can implement “conservative IFC processing” (great term!).

I cannot speak for other vendors, but I will make this a top priority for me to implement in BlenderBIM.

[ReD_CoDE]

I warned you about this:

COBie and IFC mapping

Both IFC and COBie spreadsheet are not “static” and most of the times, COBie spreadsheet doesn’t use just as an archive (which the input data just comes from IFC file) For this reason “you have to have a mechanism to archive changes inside the spreadsheet” IFC has IfcOwnerHistory yes, but as you mentioned nobody uses it and even bSI is thinking to drop it. But I think it’s useful, especially after ISO 19650 which mainly focuses on legal aspects, so owner and owner history becomes important Al…

And I think you follow a mechanism, as “diff” that is used to some “old?” databases for version control, but I think it’d be good and efficient (I don’t have any idea, because I’m not a programmer)

[Herb]

From IfcChangeActionEnum of IfcOwnerHistory I read:
“This information is required in a partial model exchange scenario so that an application or model server will know how an object might have been affected by the previous application.”

This is very important information, especially for Level3-CDEs.
If this information is not provided by the authoring software then the Level3-CDE needs to somehow guess the ChangeAction by a diff-algorithm.

I fully aggree that IfcOwnerHistory is important for legal aspects like audit trails.
Additionally, for Level-3 CDEs the partial model exchange scenario is simplified.

For two reasons I decided to resign from IfcOwnerHistory and go with a diff-algorithm for my Level-3 CDE prototype:

1. I dont expect vendors to “step up their game” in the near future
2. Diff-algorithm provides details on what changed (position?, shape?, properties?, …)