IFC Model Version Comparison: Added, Deleted and Modified Elements

When BIM teams compare two IFC revisions, they usually need more than a visual overlay. They need a structured answer to a practical question:

Which model elements were added, deleted, modified or moved?

Those categories form the basis of useful IFC version comparison, but their interpretation is not always as simple as it first appears.

Added elements

An added element exists in the new revision but has no corresponding engineering object in the previous revision.

In a normal design workflow this may represent new scope, increasing model detail, a newly modelled system or an object that has moved from another package into the current model.

A large number of additions is not automatically “good progress”. It simply means that the represented model gained content.

For a BIM Manager, the useful question is what kind of content was added and whether it matches the expected design stage.

Deleted elements

Deleted elements deserve particular attention.

A deletion can be intentional: scope may be removed, an alternative design may be rejected or a model may be restructured.

It can also reveal an unexpected loss of content.

This is why a revision comparison report should make deletions easy to isolate. A single critical object removed accidentally may matter more than hundreds of expected additions.

In a multi-revision analysis, deletion trends are also useful. If one revision contains a sudden spike in deleted elements, that revision becomes an obvious candidate for review.

Modified elements

Modification is a broader category.

A represented element may keep its engineering identity while its geometry changes. A pipe component may change size, a piece of equipment may be updated, or a structural member may be remodelled.

Depending on the IFC exporter, relevant properties can also change even when geometry remains stable.

This is one reason model comparison is more informative than simple file-size comparison or object-count comparison.

Two IFC files can contain almost the same number of elements while representing very different engineering work.

Moved or placement-changed elements

Placement changes are particularly important in coordination.

An object can remain essentially the same object but move in space.

For example:

• equipment is relocated;
• a pipe route is adjusted;
• a cable tray changes elevation;
• a structural component moves to resolve an interface.

A pure added/deleted comparison may misrepresent this kind of change if object identity is unstable.

A robust comparison workflow therefore needs to distinguish, where possible, between a new object and an existing object that has changed placement.

The identity problem

Most IFC workflows rely heavily on `GlobalId`.

When identifiers are stable between exports, comparison is much easier.

Real engineering workflows are not always so clean.

Identifiers can change because of exporter behaviour, model restructuring, copying, regeneration or cross-software workflows.

That is why Model Bridge does not treat comparison as a single-column database join.

It combines source information, representation data and geometry-oriented evidence to make the comparison more useful when the source models are imperfect.

A dedicated article in this series examines the GUID problem in more detail.

Why one pair is not enough

Added, deleted and modified counts become more interesting when they are placed on a revision timeline.

Consider five IFC deliveries.

If Revision 02 adds 800 elements, Revision 03 adds 900, Revision 04 adds only 30 but modifies 1,500, and Revision 05 deletes 600, the project story is very different from a simple “the model now contains more elements” statement.

Revision history makes changes contextual.

It can show phases of model expansion, rework, stabilisation and restructuring.

This is one of the core ideas behind the multi-revision comparator in VoxelStudio Model Bridge.

Source-aware comparison

The current development is tested with IFC files exported from Autodesk Revit, AVEVA E3D and SolidWorks/3DEXPERIENCE.

The same change categories apply to all three, but the source information available for matching and classification differs.

Revit IFC files commonly provide useful IFC classes and object naming.

AVEVA E3D exports can preserve plant-engineering information such as DBREF, OWNER and TYPE.

SolidWorks/3DEXPERIENCE exports may contain a higher proportion of generic proxy elements, which increases the importance of representation and geometry evidence.

This is exactly why an IFC comparator should inspect what is actually inside the export rather than assuming that every authoring system produces equivalent IFC semantics.

A report should support decisions

The goal of a change report is not to produce the largest possible table.

It should help a BIM Manager, BIM Coordinator or Design Manager decide where attention is needed.

A useful summary therefore needs to answer:

• How much changed?
• What type of change occurred?
• Which engineering category was affected?
• Was the change expected?
• Is the pattern normal compared with earlier revisions?

Model Bridge uses the revision timeline for the overview and detailed exported reports for investigation.

The combination is more useful than either layer on its own.

Version comparison tells you what changed. Revision history helps explain how the model is developing.