HVAC - IFC 2x3 and IFC4 - How assemble 3 IFC object information into 1 object + three general questions

Developers
1

We are currently using aggregates for combining 3 HVAC parts into 1 HVAC assemble. Is this the best approach. Ref. file “example_blenderbim_aggregate.png”, or is there a better option?

Additional general questions:

  • Is it better to use the ElementType or Element?
  • Is the complete hierarchy “IfcProject/IfcSite/IfcBuilding/IfcBuildingStorey” necessary to include IFC files (related to the first main question for aggregating objects into 1)
  • Should we use Psets for encoding general data in IFC 2x3 files? Ref. file “example_data.pdf” lines 11-155 in json

Many thanks in advance.example_blenderbim_aggregate example_data.pdf (67.3 KB)

2

You can certainly use an aggregate. I notice, however, that your aggregate class is called IfcBuildingElementProxy. You may consider IfcElementAssembly. I find the IFC documentation vague on exactly when an IfcElementAssembly should be used compared to any other IFC class aggregate, so hopefully someone here can clarify that.

For your general questions:

  1. It is not better to use ElementType or Element. Both serve different purposes and so it cannot be said that one is better than the other. An element represents a single element instance - e.g. the physical HVAC assemble at a specific location in your building. An ElementType represents a typical construction typology. E.g. you have 5 fire sprinkle elements, all of the same fire sprinkler element type (i.e. the same model purchased from the same manufacturer)

  2. The complete hierarchy is not required. Only the “IfcProject” itself is required. From there, the hierarchy can be as you desire. What you’ve shown there is simply a preset default as an example. You are free to customise it. Note that despite this, some vendors do not support more complex spatial hierarchies. For example: https://wiki.osarch.org/index.php?title=Revit_import_pitfalls - where an OSArch user has reported that if a building storey is missing, Revit will fail to import the IFC. If you come across issues such as these, please help report them to the OSArch wiki so we can document the various quirks that users have to face.

  3. It is theoretically feasible to dump the data you’ve shown into a custom pset. However, I would highly recommend looking to see if there is a more ISO standard location to store the data instead. Otherwise, this defeats the purpose of IFC. The point of IFC is standardisation, not just data transfer, of which there are plenty of alternatives. For example L25-26 shows a classification. This should be stored in a classification relationship. L37-39 shows an operating voltage, which I suspect already exists somewhere in an ISO PSet.

Hope it helps!

1 Like
3

Thanks you so much for the very quick and detailed response. It helped a lot. We are on it and I will come with a response on that soon.

4

Hi

I think that we have couple of Implementation Agreements that directs how to use IFC spatial structure:

CV-2x3-141 Agreement on having maximum of one instance of IfcSite
CV-2x3-142 Agreement on having at least one instance of IfcBuilding as part of the spatial structure

Probably Revit import follows CV-2x3-142 and it fails on purpose.
Please see Agreements here: Implementation Agreements (buildingsmart.org)

5

Oh yes, sorry @marko.ripatti is correct there are implementer agreements which only apply to IFC2X3. For IFC4 (which I recommend you use) these are not applicable.