Angel Velez provided further clarification on the relationship between the Revit element UniqueId
and the IFC GUID generated from it, prompted by
the Revit API discussion forum thread
on abnormal modification of Element.UniqueId
:
We encounter a problem with the management of the GUID returned by Element.UniqueId
.
UniqueId
.UniqueId
changed!This bug obviously causes problems in plugins that manage an external database or other tools using the IFC export.
First of all, here are some previous discussions on the relationship between the unique id and the IFC GUID:
In them, we explain that the GUID generation routines have an internal cache that prevents duplicate GUIDs from being generated. In IFC, these functions are called once per element, and then a call to the ExporterIFCUtils.EndExportInternal
method clears this cache for the next IFC export. Please note that the first time you call these routines, they have consistent values from previous sessions.
For now, there are two workarounds:
ExporterIFCUtils.EndExportInternal
to reset the internal cache.To recapitulate, the IFC GUID is based on the Revit UniqueId
.
If the UniqueId
is changing, then so will the IFC GUID.
I suspect that when you save a file, you change the EpisodeId
of the document.
The unique id of an element is based on the EpisodeId
and the ElementId
.
If the EpisodeId
is reset on an undo of a delete, that would explain it.
For the issue of consistent GUIDs, Revit ensures that:
UniqueId
being consistent, so if there is an issue there, then that will clearly affect IFC export.I looked at your sample files and note a couple of cases that could be improved. In general, though, most of the GUIDs are consistent and unique as per rules 1 and 2. We will improve this over time to reduce the noise in 3, but it is very difficult to remove all of the noise without a lot of extra storage in the Revit file.