buildingSMART Forums

Is there any command line tool to diff two ifc models?

@JustinWang

Would this be between two files created by the same authoring tool, but maybe different versions? If it was between two different tools creating the “same” model, I would say that currently it would never work.

@jwouellette
My expectation is that two files are created by the same authoring tool with the different versions. FreeCAD diff tool is trying to compare the geometry by centroids, areas, volumes, bounding box, and also cover material, id. However, it doesn’t cover others: spatial structure, hierarchy, relationship, property set in detail. Also, it isn’t a separate tool from the FreeCAD. Perhaps, this tool isn’t what I want now.

Correct. That is why I have proposed to create a standalone diff tool :slight_smile: I believe OpenBIM really needs one.

I don’t see why it can’t diff IFCs created by different authoring tools, the CG industry has had diffing tools for a while now that are completely agnostic of the geometry creator, so… why not for IFC?

1 Like

Unfortunately, the way things work right now, two tools can create different IFC files for the same model data. They are different because each application has written the ASCII syntax in a different order.

Although yes, the way things work right now is not the best, because each authoring tool supports IFC in a different way.

However I don’t think the different ASCII syntax is a problem at all. I can take an OBJ, edit it in Blender, then edit it in 3DS Max, and I can still compare the two, regardless of the OBJ being written differently each time. It is the same with IFC - the diff tool simply has to:

  1. parse each IFC file into a data structure
  2. canonicalise and sort the data structure
  3. where GUIDs match, compare attributes (geometry, centroids, data attributes) within a certain set precision value

Therefore, the ASCII structure doesn’t matter, and the only prerequisite is that the GUID isn’t mangled in the authoring program, which it shouldn’t be (see discussion in other thread how the current spec for IfcGloballyUniqueId is currently inaccurate, but when this is fixed it can help ensure tools like this diff and others can work reliably).

This is already being done today. It is what the model checkers were made for.

Absolutely:) so it should be trivial for someone to extend that code to include diff capabilities (FreeCAD is one such example). But such a standalone, command line, open source tool doesn’t exist yet?

I suspect writing one with IfcOpenShell which is headless and relatively easy to prototype with is your best bet.

Tried Notepad++ ?

Geometry Gym has developed diff and merge routines that can be run as a standalone command exe, cross platform with mono. And with nordlenningen have run the routine with files originating from tekla and passed through revit with success. It’s developed on demand as it has various smarts about geometry tolerance. I would like to automate the creation of this tool akin to the toolkit in Ifcdoc.

In a pure way, you could use an approach similar to what I’m advancing on with the definition of ifc within ifcdoc. Create an ordered ifcxml. This might work with very little effort.

That’s true, Jon. But not quite sure what is asked for (maybe bad reading from my side…). Variations and difference between to models originated from the same authoring tool, is as Jeff says done by model checkers. On a “desperate” user level we have used Notepad++ to check the difference in files, but that is often related to specific errors, and may not match the need here.

So maybe my bad on a sleepy morning… :slight_smile:

My interpretation is that the OP is asking for a git diff that is a bit more semantic … this is not something that a model checker currently provides.

I suspect writing one with IfcOpenShell which is headless and relatively easy to prototype with is your best bet.

IfcOpenShell has this entity_instance.get_info() method which you can use to get a hierarchical attribute map for an instance (rooted or not) which you can trivially compare for equality with one from another file. You can exclude the numeric instance id name so the check is robust against multiple exports from the same model which sometimes creates different numeric ids. So yes, this is indeed “relatively easy”.

1 Like

Hi Guys,

We have a standalone developer tool which compares two IFC files on textual basis. (Not command line tool, it has UI). It has two panels with the direct an inverse references, you can navigate parallel in both files:

If you need, I can share it with you, and all comments are welcome!
Regards,
József L. Kiss

2 Likes

If you need, I can share it with you, and all comments are welcome!

Hi @jkiss! Is it possible to try your IFCComparator tool? I get that it’s not pulished somewhere as opensource, right?

For a bit of closure on this thread, BlenderBIM now packages IFCDiff, which is a command line tool that does some, but not all (yet), of what you’ve asked.

https://blenderbim.org/download.html - it’s completely free software, under IfcOpenShell, and cross-platform.

At the moment it covers geometries and properties, ignores changes in STEP line IDs, and also takes into account floating point differences between exports. I expect its capabilities to evolve over time to allow diffing for specific things, deeply nested relationships, querying exactly where geometry changed, spatial diffs (i.e. diffing based on spatial location, not the entire file), and better ways to visualise and report the data. It currently provides a JSON report of added GUIDs, removed GUIDs, and changed GUIDs along with a before / after of property values, and a boolean indicating geometry changes.

1 Like

If you compare IFC file versions (revisions or variants) generated by the same authoring software there are only minor challenges to solve.
Examples for authoring software deficits:

a) each subsequent IFC export is “new” again, no difference information supported ( attribute “ChangeAction” in “IfcOwnerHistory”, see thread IfcOwnerHistory)

b) changed GUIDs for unchanged items

c) minimal changes in real values (e.g. in the magnitude of 1E-17 caused by rounding errors)

d) same object type e.g. WindowType is stored separately for each window even if the imported IFC4 DTV IFC file had one common WindowType for all equal windows

… to be continued by the community
@jwouellette:
Where can a systematic collection of such current drawbacks (future improvements) be found?

If two or more different (authoring) software applications are in use then there is the big challenge of “different representation paradigms”:
https://3d.bk.tudelft.nl/projects/geobim-benchmark/ifc.html
As @jwouellette mentioned: " two tools can create different IFC files for the same model data."
And they really do! (e.g. wall represented by extruded area versus brep)
Even worse: currently NO roundtrip-preservation on IMPORT - NO CHANGE - EXPORT (NO “conservative IFC processing”):
Your IFC4 DTV file is completely dissassembled by the authoring software during import. If you export without planning changes you get back the same model in a different representation paradigm. Comparing the differences based on text and formal information structure only,without taking into account the geometric semantics is impossible.
See:

Solution: BIM Level 3:

  • shift building model to a CDE
  • (authoring) software applications operate on the model (using an open IFC API) by using standardized basic model manipulation operations (similar to DML of DBMS)

Comments welcome!

Hey @Moult, great news! Is IFCDiff source availiable anywhere? Is it https://github.com/IfcOpenShell/IfcOpenShell/blob/v0.6.0/src/ifcdiff/ifcdiff.py?

@claimred Correct, that is the source :slight_smile:

1 Like

One of the challenges you have is describing what constitutes a difference!

  • We assume GUID is stable (same object always exports with same GUID - initially this was not always implemented in software). But if I create 100% the same object (properties, geometry, location) in the same software as you do, we both generate a different GUID. Does that imply a different object? I’m not convinced, personally.
  • Number and Name and Description and other identifications occur both on Type and on Occurrence level. This may change or not, but is mostly independent from geometry and even properties.
  • Geometry? This is very dependent of the IFC export settings (e.g. you can export the same geometry in different ways AND you can export different geometry in the same way if you go to BREP) - Not every modeling method in the native software has an equivalent in IFC. Even the way we create a BREP and the more parametric geometric descriptions (e.g. extrusions, sweeps, CSG) can lead to huge differences. That is even before taking tessellation into account.
  • Properties? We have both the predefined buildingSMART property sets (with some possibilities for local interpretation), and in some cases local-standardised sets. And a lot of project- and company specific properties (alongside the software-specific properties).
  • Base Quantities? While defined by buildingSMART, we notice huge differences between software: not all quantities are filled in and since the method of quantity calculation may differ from the native software, this is not always visible for the user in the native software. E.g. the “NetSideArea” for a Wall may not have an equivalent native quantity calculated following the same method, so we completely rely on the native software correctly following the buildingSMART method and calculating this upon export (only visible for the user in the IFC output)

This is complicated by the fact that every software is free to organise the IFC export how they see fit. The order of entries is irrelevant, the STEP ID (#123) doesn’t matter.

So all in all, I mostly see difference tools being useful to compare “versions” of a model coming from the same software.

So, this is bSI’s and software vendors’ problem

This is why still “few” who know IFC well say “IFC is not explicit”