A number of interesting Revit IFC parsing errors.

Developers IFC4
1

We have an IFC that is created by Revit. It is exhibiting some interesting parsing errors. It’s possible that our parser is being too strict, but this particular file also exhibits errors in ArchiCAD, but not in BlenderBIM. It seems out of line with the spec. Any input would be greatly appreciated.

Calling @angel.velez for input.

Problem 1:
Incorrect date format. Other Revit IFCs format the date like ‘2019-01-24T11:32:54’. I believe it may be the extra enclosing ‘’ that is causing this issue.

Our parse error:
line 4:15 mismatched input ''2022-09-29T17:02:02+02:00'' expecting DateTime

Problem 2:
Extraneous ( ) in all list elements. Other Revit IFCs do not exhibit this issue.
Our parse error:

line 142:30 extraneous input '(' expecting {IntegerLiteral, RealLiteral, Id, StringLiteral, TypeRef, '$', AnyString}
line 142:55 extraneous input ')' expecting ';'

Examples:
#136=IFCCARTESIANPOINTLIST3D(((0.,0.,0.),(43.75,0.,0.)));
#300=IFCINDEXEDPOLYGONALFACEWITHVOIDS((1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30),((31,32,33,34),(35,36,37,38),(39,40,41,42),(43,44,45,46),(47,48,49,50)));

Problem 3:
Unescaped ‘’. I believe the 8" pendant light name is causing the parser to emit an error.
Our parse error:

line 186708:71 extraneous input '':2282502'' expecting {',', ')'}
line 186708:102 extraneous input '''' expecting {',', ')'}

Example:
#187204=IFCLIGHTFIXTURE('03ks4u1evCz8SCUk_egWio',#20,'Linear Pendant:8'':2282502',$,'Linear Pendant:8''',#187203,#187200,'2282502',.NOTDEFINED.);

Update
Problem 1 is a date/time parsing issue in our STEP grammar. Older IFCs generated with the Express Data Manager didn’t encode a time with a time zone. Newer ones generated with ODA use the time zone. Here’s the error in the grammar: IFC-dotnet/STEP.g4 at master · ikeough/IFC-dotnet · GitHub

Problem 3 might be a similar problem with the grammar. We support ' but not ‘’. IFC-dotnet/STEP.g4 at master · ikeough/IFC-dotnet · GitHub

2

Hi Ian,
What version of Revit is this, to start? We’ve switched to the ODA toolkit and do occasionally find some issues they have to fix. Let’s start there because these don’t look like generic issues (otherwise they would be causing rampant problems).

3

I believe it’s a recent version of Revit, but not sure exactly which (I’m finding out). I see the ODA signature in the header of the IFC file. Here’s the header.

ISO-10303-21;
HEADER;
FILE_DESCRIPTION(('ViewDefinition [ReferenceView_V1.2]','ExchangeRequirement [Architecture]'),'2;1');
FILE_NAME('00','2022-09-29T17:02:02+02:00',(''),(''),'ODA SDAI 22.12','23.0.20.21 - Exporter 23.1.1.0 - Alternate UI 23.1.1.0','');
FILE_SCHEMA(('IFC4'));
ENDSEC;
4

Ha! Of course if I had just looked at the first line…
#1=IFCORGANIZATION($,'Autodesk Revit 2023 (ENU)',$,$,$);

5

Revit 2022 exhibits the same issue.

6

You don’t have access to the original Revit file, do you? I’d like to verify that it was created in Revit and not munged afterwards in any way.

7

OK, I don’t think that’s an issue. IFCCARTESIANPOINTLIST3D is a two-dimensional list of Cartesian points provided by three coordinates.

So first parenthesis is the entity parenthesis.
Second parenthesis is the start of the outer list.
Third parenthesis is the start of the inner list.

I did a search in our sample files from across different organizations and they all have the same pattern. And these are certified IFC4 files.

8

For problem 3, I believe a double ’ is a legitimate way to escape the character.
The geometry gym toolkit doesn’t encode the string that way, but it will read files that do.
I don’t recall where this might be documented for STEP serialization, but I would suggest that ‘Linear Pendant:8’‘:2282502’‘Linear Pendant:8’‘:2282502’ is a valid single string attribute.

9

Right. I think he originally thought it was a double quote, but it is a single quote escaped, which I believe is correct (or at least not uncommon).

10

I’ve been out of the IFC game for too long. All of this was errors in our parser. Thanks @angel.velez for taking the time to validate this. Apologies for the run-around.

The challenge with this specific file was that an IFCLabel was terminating with a single quote (ex: 8’ (8 feet)) that was escaped with a single quote. Our parser can handle single quotes inside the string, just not at the end. The error that we were receiving was related to the ‘ …8’’’ being read as ‘…8’ with extraneous ‘’. We also had to add support for two single quotes in a string.

You are also correct that the IFCCARTESIANPOINTLIST is a collection. Again, our parser was deficient. Simply adding the ability for a collection to contain a collection caused this to be recognized correctly.

11

Issues resolved in this PR: Support nested collections and date times with time offsets. by ikeough · Pull Request #69 · hypar-io/IFC-gen · GitHub

12

Sorry to butt in announced with a question that does not relate to the issue. What would " :8’ " mean? Feet?

Thanks.

13

I can only guess that’s what they mean. This is coming from a Revit family where family type names routinely have the size of the type in the name.