Why are GlobalIds not unique across files?

[Moult]

For example, on a sample of 6 architectural Revit models on the same project (and therefore 6 IFC files), I found 2,578 duplicate GlobalIDs across elements from a total of 1,898,180 rooted elements. This is a duplication rate of 0.136% which is pretty severe.

This is creating lots of problems with linking to other systems. I have to resort to all sorts of tricks to regenerate and map changed GlobalIds.

What can be the cause of this? From the few I checked manually, the duplication happens across files, not within the same file. Perhaps copied elements?

[AngelVelezSosa]

Hi Dion,

1. You should never - at least for several years - have one IFC file with repeated GlobalIDs. Definitely report that if it ever happens.
2. You can trivially create a duplicated GlobalId by doing the following: a. Create a new project with a wall in it. b. Save it. c. Export it. d. Copy the original file. e. Open it. f. Export it.

If you copy a file and the elements within them, are they the same elements or not? This is kind of a universal problem because I can see cases where it could be either. Now, there should be a way in Revit itself (IMHO) to say "reset document GUIDs". But lacking that functionality, if a user were reusing elements in new projects, then they would have to set the IfcGUID manually to be something new.

If you are seeing duplicate GUIDs for different elements, please send those files. While of course that is possible, we'd expect nowhere near .136%. .0001% maybe.

[Moult]

Yes, I am talking about duplicates across multiple IFCs.

The projects I'm seeing these on are typically large complex federated projects - so it is very common that a user will start off with a template, or halfway through a project, duplicate the file and split it into two files, so your second explanation is probably the culprit. So the most common duplicates are say 80 IfcBuildingStoreys, but also duplicate GlobalIds for IfcRelDefinesByProperties, IfcSpace, IfcPropertySet, IfcRelAggregates, IfcRelContainedInSpatialStructure, and IfcGroup.

Users, after duplication, tend to rename these objects. So I will have two storeys with the same ID but a user genuinely believes they are two different objects. Users, naturally have no control over IfcRelationship entities (so, will your manual override trick work?) nor any control over IfcGroup or IfcPropertySet.

So - whether this is classified as a user error, a UX error, or otherwise (e.g. the IfcRelationship lack of control), the practical reality is that contractors receive a ton of IFCs from many third parties, who will, outside their control, be doing these types of workflows. I think your proposed solution of a "reset document GUID" or some way of knowing if there are linked files that it is part of a federated dataset to have some control over GUIDs.

Here's a little snapshot from my debug comparing just 2 files (sorry I cannot send the files as it is a sensitive project):

  "0jcJ1wPir4ER5pN8ZIKcHy": [
    "#1903151=IfcGroup('0jcJ1wPir4ER5pN8ZIKcHy',#42,'Gross Building2',$,$)",
    "#1838236=IfcGroup('0jcJ1wPir4ER5pN8ZIKcHy',#42,'Gross Building1',$,$)"
  ],
  "0jcJ1wPir4ER5pMudIKcHu": [
    "#1903142=IfcRelDefinesByProperties('0jcJ1wPir4ER5pMudIKcHu',#42,$,$,(#1903085),#1903140)",
    "#1838227=IfcRelDefinesByProperties('0jcJ1wPir4ER5pMudIKcHu',#42,$,$,(#1838192),#1838225)"
  ],
  "0jcJ1wPir4ER5pMedIKcHu": [
    "#1903140=IfcPropertySet('0jcJ1wPir4ER5pMedIKcHu',#42,'Identity Data',$,(#499,#1903071))",
    "#1838225=IfcPropertySet('0jcJ1wPir4ER5pMedIKcHu',#42,'Identity Data',$,(#506,#1838178))"
  ],
  "0jcJ1wPir4ER5pN8ZIKcHu": [
    "#1903085=IfcGroup('0jcJ1wPir4ER5pN8ZIKcHu',#42,'NLA2',$,$)",
    "#1838192=IfcGroup('0jcJ1wPir4ER5pN8ZIKcHu',#42,'NLA1',$,$)"
  ],
  "1LKcsEFhbFQAzKAhiekN3S": [
    "#1903076=IfcRelDefinesByProperties('1LKcsEFhbFQAzKAhiekN3S',#42,$,$,(#1903063),#1903074)",
    "#1838183=IfcRelDefinesByProperties('1LKcsEFhbFQAzKAhiekN3S',#42,$,$,(#1838167),#1838181)"
  ],
  "1LKcsEFhbFQAzKAxiekN3S": [
    "#1903074=IfcPropertySet('1LKcsEFhbFQAzKAxiekN3S',#42,'Identity Data',$,(#499,#1903071))",
    "#1838181=IfcPropertySet('1LKcsEFhbFQAzKAxiekN3S',#42,'Identity Data',$,(#506,#1838178))"
  ],
  "1LKcsEFhbFQAzKBReekN3S": [
    "#1903063=IfcGroup('1LKcsEFhbFQAzKBReekN3S',#42,'FSA2',$,$)",
    "#1838167=IfcGroup('1LKcsEFhbFQAzKBReekN3S',#42,'FSA1',$,$)"
  ]

[AngelVelezSosa]

In this case, I don't think files are necessary - it is certainly the case I described above. Obviously we don't want an element's GUID to change because the name changed, or really any other characteristic. It does beg the existential question : If I have Level 1 at 0m, and rename it to Level 2 at 3m, is it the same element or a new element?

Another issue is compatibility. We could change how GUIDs were generate. For example, we could expose a "Base IFC GUID" for a project that would be user visible and modifiable, or even use the existing IFC Project GUID as the base GUID that a user could override. But that would change GUIDs for all existing projects, which would likely create havoc. So how do we preserve existing behavior while allowing for better new behavior?

In the short term, you have access to the IFC GUID parameter. You could create a script that re-wrote all of the IFC GUIDs for one of the projects, and that would be respected.

[Moult]

Agreed it isn't straightforward. The user needs to have the choice to say whether it is the same or new element. What about the Rels, Groups, and Properties? Does the user have any control over that?

I'm not sure I agree with the base IFC GUID - I've been a proponent of using uuid v4, and it's always been a huge irk how Revit uses things like magic numbers and the GUIDs look almost sequential.

In the short term, we are already running a script that rewrites all the IFC GUIDs, so I guess we'll keep on doing that for the moment until there is a bit more user friendly solution.

I really appreciate the quick responses!

[Moult]

I've edited the bug name to better reflect the issue.

Note that for the record, I've also experienced two other types of issues. When users have the "Store GlobalID in an element parameter" checked when exporting, then sometimes, I've noticed that this sometimes gets overwritten with nonsensical data, or, with an expanded base 16 uuid. I've questioned the authors of these files, and they have no idea how it occurred, so unfortunately my sleuthing ends there. Perhaps it would be good to perform a check to ensure that any manually overwritten GlobalIds follow the IFC specification to prevent invalid data?

[AngelVelezSosa]

1. We have a new GUID generation routine that can create better guids, but we are only going to be using it for GUIDs that are currently not unique, because we don't want to break compatibility. Perhaps when that is finalized, we could have a toggle to choose old meh GUIDs vs. new better GUIDs. Even with the new ones, it would still be based on some document based guideline. Element id 9948 appears all over the place - there needs to be something unique on top.
2. The Revit user (currently) isn't going to have control over "derived" IFC entities. We are doing work to expose more IFC-specific things, so perhaps that would be incorporated. But we need to find the line between 'IFC seems tacked-on to Revit' and 'Revit has a detailed IFC manager that requires you to know everything about IFC to import/export'. We want common-sense controls over information that is useful without Revit looking like an IFC shell.
3. "Store GlobalID in an element parameter" isn't really smart enough to write out garbage. We do currently have code in place (fairly recent) that ignores bad data (if a user put it there somehow), and if "Store GlobalID in an element parameter" is checked and that data isn't used because it is bad, it will override it. But definitely if you see any occurrences of that, we would be interested to flush them out.

[Moult]

Thanks for all the explanations! I'll pay extra attention to the third in case it happens again.

[ArtemHnatko]

Hello @Moult,

This behavior is expected. GlobalIds are unique within a single Revit project but may be duplicated across multiple files if those files were created by copying or splitting an existing model. In such cases, the same element identifiers are retained.

To avoid duplicate GlobalIds across projects, it is recommended to regenerate IFC GUIDs before exporting — for example, by using a script to rewrite them or by manually editing the IfcGUID parameter. Currently, Revit does not provide a built-in “Reset document GUIDs” function.

Since the fix requires a change in the core Revit application's internal document management, the issue is beyond the scope of the IFC Add-in development team.

We will close this issue to reflect that the problem has been fully diagnosed and its resolution requires a platform-level feature request. We recommend promoting the need for a "Reset Document GUID" tool on the Autodesk Revit Ideas forum.