IfcOS C++ - internal data model documentation, design reasons? #4218
Replies: 3 comments
-
Maybe this helps as a first starting point. Let me know which things need additional clarification.
Uses to query model based on IFC type
Query by id; also instance references are resolved dynamically, parsing is only single pass
IfcBaseClass has a unique uint32_t in addition to the numeric instance from the step file. The purpose for this is when you add an instance to a file we use the identity to see if that instance was already added once earlier and not add it again.
Query by guid
Used to resolve inverse attributes, which require the type and attribute index because inverse attributes have named forward attribute mirroring potentially a specific subtype.
Used for 'batch mode', which is basically to do a topological sort based for large subgraph deletion, so that you delete from the leafs inwards and don't keep updating inverses within the subgraph.
Appears unused. I think was once used for caching when inverse attribute calculation was more expensive. |
Beta Was this translation helpful? Give feedback.
-
Thank you for the overview. So basically the parse functionality iterates over the file and creates for each # line (STEP instance) in the file a new -> I think here is an opportunity for optimisation of the in-memory model. I'm thinking of using an Entity Component System known from game engines or reusing instances for IfcType e.g. do not duplicate an IfcCartesianPoint with the same value. I had a hard time understanding the class declarations, either due to the change of naming style to suddenly snake_case compared to other elements and that class definitions are not really located in the files I would expect. I also was a bit thrown off by the name Here is a follow up question: What’s the difference and purpose between the classes I get that first one as it basically is an Entity list / vector with added functionality. |
Beta Was this translation helpful? Give feedback.
-
Functions and Rules are not exchanged as part of the P21 (.stp) file format. For types it depends on the situation. In spf simple types are typically exchanged as the simple literal values they wrap. You don't read
This is an unfortunate fact of life I think that if you want to remain true to the words in the specification you alienate the normal people. But entitylist is wrong for two reasons. It's not only applicable to lists in the schema, but also sets. Its values are not entities (which are the classes in STEP) but entity instances.
This has to do with the separation of schema and parsed model. Only when you interact with a named attribute in the schema, the generically stored list of instances is casted to a typed ( This is something we can do better now, to when parsing already use schema information to store values with less indirection based on the schema. Maybe IfcEntityInstanceData can actually be more like a tuple instead of an array with abstract values with virtual methods. But 10y ago, variadic templates where not there yet in C++ and in ifopsh we didn't have the runtime schema information available yet. This would be in my mind the most obvious memory and performance gain, there is really a lot of inefficiency in the virtual calls, casting (not only aggregate_of_instance but also e.g vector) and pointer chasing happening in the stored attribute values. |
Beta Was this translation helpful? Give feedback.
-
Hi there,
is there anywhere an in-depth documentation or write-up about the internal data model of the IFC hierarchy?
I am still trying to GROK this and would be interested to hear the reasoning behind the architectural decisions. I can see, that the parsed IFC file is stored in memory with a bunch of maps (some of the unordered hash maps) with the IfcFile class, but unfortunately I couldn't find the WHY behind this.
IfcOpenShell/src/ifcparse/IfcFile.h
Lines 71 to 84 in b4120b1
Beta Was this translation helpful? Give feedback.
All reactions