The IfcSpace entity contains numerous PropertySets which are either defined on the entity itself or which it inherits. In the field of thermal load there are 5 PropertySets defined at the space and two more inherited from IfcSpatialElement. These PropertySets are partly redundant, but at some points they are incomplete. They do not follow a consistent naming convention and it is sometimes not clear from their descriptions how the application is intended.
Can this also be the subject of the revision of the IFC schema? In that case, I can work up the problems once and make a consolidation proposal.
2 Likes
Dear @ElisEck ,
thank you raising this question. You made a great point. Yeah, Building Room is open for improvement proposals, that was a main purpose of this call.
Feel free to suggest those changes here. You may upload it here. We will forward all comments it to IFC4.3 Team.
There are 8 Psets at IfcSpace focussing on HVAC domain:
- Pset_ThermalLoadAggregate (inherited from IfcSpatialElement)
- Pset_ThermalLoadDesignCriteria (inherited from IfcSpatialElement)
- Pset_AirSideSystemInformation
- Pset_SpaceThermalDesign
- Pset_SpaceThermalLoad
- Pset_SpaceThermalRequirements
- Pset_SpaceThermalLoadPHistory
- Pset_SpaceThermalPHistory
And 4 more Psets that touch HVAC domain: - Pset_SpaceCommon
- Pset_SpaceCoveringRequirements
- Pset_SpaceLightingRequirements
- Pset_SpaceOccupancyRequirements
Sometimes these Psets overlap, sometimes they are incomplete. Therefore I analyzed all of them on a property level.
I suggest to not have any properties / psets cluttering the ifc schema, that are only valid in a very well defined context, such as energy balances and TimeSeries of results. Although I have some experience in heating load calculation and building simulation, I don’t understand how to use the energy balances in the Pset
- IfcSpace:Pset_SpaceThermalLoadPHistory
- IfcSpace:Pset_SpaceThermalLoad
I’m afraid others feel the same way and users are put off by a mess of psets. I suggest to transfer these into a well defined use case within the UCM. Alternatively, these would need to be better documented to show how the use is intended.
As the time series within IfcSpace:Pset_SpaceThermalPHistory cannot be interpreted without knowledge how they were calculated they should be moved to a use case, too.
All properties in the above mentioned psets, can be classified into
- requirements
- constraints
- assumptions (should be removed)
- intermediate results (should be removed)
- results
- Design decisions
I suggest not to mix properties from different classes in one pset.
Furthermore I suggest to not clutter the IFC schema with properties containing intermediate results and assumption that the engineer made during his work. People have different work processes and most importantly: they usually will not use an exchange format such as IFC to document an “arbitrary” choice of intermediate results of their work.
I propose a significant stripping of the properties at IfcSpace, as well as a merging of the remaining propertysets. As there are 146 properties now, I leave the details to the attached file.
I suggest to have a consistent naming of the Psets and the Properties themselves. Is there a naming convention that all Psets-Names start with the Respective entity e.g. Pset_SpaceThermalRequirements or can that be shortened to Pset_ThermalRequirements?
Furthermore I suggest to move most of the Pset definitions to IfcSpatialElement instead of IfcSpace. They can be used more flexible then (but maybe naming of the Pset has to be changed then?)
The properties focus very much on air-based heating and cooling, which is usually not the only conditioning system (in Germany it is usually accompanied with water based systems. As a counterpart to Pset_SpaceAirHandlingDimensioning (previously: Pset_AirSideSystemInformation) a Pset_SpaceXXXDimensioning would be necessary.
I attach an excel sheet with the mapping of the old and new properties.
Maybe people involved in the history of these Psets can comment on the original purpose and intended use. Especially concerning the properties I proposed to “kick”. I am particularly interested in what is meant by all these “diversity”-properties (IfcPositiveRatioMeasure). Maybe @TLiebich?
The goal of my proposal is to make Properties clearer and hopefully convince more people to use it for data exchange. I intentionally propose to reduce the number significantly (146->44) to the properties that are almost always needed, regardless of the project context.
2 Likes
Unfortunately I cannot attach any documents. @mirbek.bekboliev I send it to you via mail and ask you to upload it.
1 Like
Dear @ElisEck,
thank you so much for your invaluable input!
Like requested I’m uploading you documents in one buddle. Here is a Link to Download (PDF and Excel-Table).
@TLiebich and @berlotti please see attached files for further review and consideration.
Kind regards
Mirbek
1 Like
Very valuable review, @ElisEck .
I think @agron also dealt with this topic
Regarding →
Could you expand a bit more on this idea about “intermediate” results? I am not sure to understand what you mean. Is it something related to WIP tasks? Do you mean not using IFC as the exchange format when sharing intermediate results within energy analysis information exchange scenarios?
I think this:
would be very very valuable as well, not just regarding IfcSpace properties, but for the whole of them. Probably UCM will help to get that necessary context, but at least it would be nice to have a resource where to check the initial purpose in a clear and explicit format, nowadays.
Regards,
David
2 Likes
I try to explain that using the Pset_SpaceThermalDesign. It contains this properties:
- VentilationAirFlowrate (IfcVolumetricFlowRateMeasure, “Ventilation outside air requirement for the space.”)
- CoolingDryBulb (IfcThermodynamicTemperatureMeasure, “Inside dry bulb temperature for cooling design.”)
- CoolingRelativeHumidity (IfcPositiveRatioMeasure, “Inside relative humidity for cooling design.”)
- TotalSensibleHeatGain (IfcPowerMeasure, “The total sensible heat or energy gained by the space during the peak cooling conditions.”)
- TotalHeatGain (IfcPowerMeasure, “The total amount of heat or energy gained by the space at the time of the space’s peak cooling conditions.”)
- CoolingDesignAirflow (IfcVolumetricFlowRateMeasure, “The air flowrate required during the peak cooling conditions.”)
- HeatingDryBulb (IfcThermodynamicTemperatureMeasure, “Inside dry bulb temperature for heating design.”)
- HeatingRelativeHumidity (IfcPositiveRatioMeasure, “Inside relative humidity for heating design.”)
- TotalHeatLoss (IfcPowerMeasure, “The total amount of heat or energy lost by the space at the time of the space’s peak heating conditions.”)
- HeatingDesignAirflow (IfcVolumetricFlowRateMeasure, “The air flowrate required during the peak heating conditions, but could also be determined by minimum ventilation requirement or minimum air change requirements.”)
- ExhaustAirFlowrate (IfcVolumetricFlowRateMeasure, “Design exhaust air flow rate for the space.”)
- BoundaryAreaHeatLoss (IfcHeatFluxDensityMeasure, “Heat loss per unit area for the boundary object. This is a design input value for use in the absence of calculated load data.”)
- CeilingRAPlenum, “IfcBoolean (Ceiling plenum used for return air or not. TRUE = Yes, FALSE = No.”)
This is obviously about determining the amount of air for a room (even though the pset designation “SpaceThermalDesign” doesn’t exactly suggest it, but based on the properties included, I deduced this). I’ll describe the workflow that I think the pset was most likely intended for:
- Based on the loads to be discharged in the heating case (specific and absolute, 4+5) or cooling case (only absolute, but sensitive and total 9+12), a target volume flow (6+10) can be determined. The necessary setpoint conditions (humidity and temperature, 2+3+7+8) are provided in the Pset, but there is no property for the supply air temperature/temperature excess, which is also necessary for the design.
- These target volume flows could be combined in a next step of the design with target volume flows resulting from other boundary conditions (e.g. prescribed air exchange rates or based on the occupancy of persons) in order to then make a final decision on the design volume flow of a room. Possibly, the parameter VentilationAirFlowrate (1) is intended for a volume flow resulting from other boundary conditions. However, the question arises why this is only included as a “result” in the Pset, while relevant boundary conditions/intermediate results are specified for the determination of the thermally necessary air volume flows. Furthermore, it is questionable that there is only this one further volume flow in the Pset. Spontaneously I can think of two other criteria (precribed air exchange rates or occupancy with people) that come into question to determine an air volume based on the necessary air quality. (Surely there are others, I am not a ventilation expert). So either the air quantity determination based on the air quality has to be documented in another Pset or the corresponding parameters would have to be integrated in this Pset. However I don’t see another suitable PSet in the IFC standard. It would be consequential to have a Pset in the standard for both types of air quantity determination, or for neither of them.
- As a result, a planning decision on the nominal volume flow in the room will be made from the various target air quantities based on different criteria. This is an essential planning result and therefore it seems reasonable to provide a place for it in the exchange format IFC. ExhaustAirFlowrate (11) could be this parameter, but the parameter is unsuitable due to its designation. The nominal air flow rate does not have to correspond to the exhaust air flow rate, e.g. in the case of overflow (TRA). If the exhaust air volume flow (ETH) is defined, then the other air volumes should also be named at this point, especially the supply air volume flow (SUP), which is the more relevant one in the case of thermal design anyway.
Since the Pset focuses on the thermal design of air volume flows, the supply air temperature is missing as an essential parameter.
The CeilingRAPlenum (13) property indicates in the form of a boolean whether the ceiling is used as an air outlet. However, it is not only interesting whether the ceiling is used, but also where (if not on the ceiling) the air supply is instead. Furthermore, there is much more information about the selected form of the air outlet, which can not be shown in this PSet.
I hope I could show with this example what I mean by “arbitrary choice of intermediate results”.
With this Pset (and with the other Pset from IfcSpace it is similar) most of the important boundary parameters can be documented for some work steps, for other work steps this is not possible. Thus, the user is forced to make the complete documentation of his air volume calculation elsewhere. In this case, it does not make much sense to document some intermediate steps in the IFC, if it cannot be the single source of truth anyway. The ventilation designer has additional effort to store some parameters in the IFC, which is not justified, because this information is not relevant for other involved parties (e.g. CoolingDesignAirflow, HeatingDesignAirFlow), so he will turn away disappointed after viewing the IFC specification.
Hence my plea to have the PropertySets completely or not at all in the IFC standard.
It is better to have a complete and well-documented coverage of a sub-step than an incomplete and incomprehensible coverage of the entire process (in this example “determination of air flow rates”)
3 Likes
Well documented.
I can only agree to your statement. I had a similar case where the IFC structure was not quite appropriate in storing data under a certain process.
2 Likes
I just read this article (MVD based information exchange between BIM and building energy performance simulation) and suppose that some of the Properties/Psets (PSet_SpaceThermalLoad, PSet_SpaceThermalLoadPHistory) come from this project context. However, even there (Annex60 Final Report) I don’t find detailed descriptions how the application of the PSets and Properties was intended. Maybe @james.odonnell can give a hint?
1 Like
I want to add that the PropertySet PSet_SpaceThermalRequirements from IFC2x3 disappeared in IFC4x3. On the other hand, if you have a look at the change log it seems like it still exists: Annex F (normative) Changelogs - IFC4.3.2.0 Documentation
Maybe someone can tell me what is correct?
