buildingSMART
IfcPropertyBoundedValue tests
The test cases for bounded property values (IfcPropertyBoundedValue) make no sense to me. It might be that I'm not getting how it should work.
My intuition is that if someone puts a value in IDS for such a property, it should apply to the "setpoint" value (last attribute), is that true? ~~And if someone puts IDS restrictions with min/max, they should not exceed the upper/lower bounds of the property.~~ edit: And if someone puts IDS restrictions with min/max, the bounds in IFC should be within the IDS bounds (IDS: 100-200, IFC: 120-140 --> pass; IDS: 100-200, IFC: 90-110 --> fail). See the question from https://github.com/buildingSMART/IDS/discussions/372#discussion-7422524.
However, the test cases called "any_matching_value_in_a_bounded_property_will_pass" have those set values:
- pass-any_matching_value_in_a_bounded_property_will_pass_1_4.ids --> 1
- pass-any_matching_value_in_a_bounded_property_will_pass_2_4.ids --> 5
- pass-any_matching_value_in_a_bounded_property_will_pass_3_4.ids --> 3
- fail-any_matching_value_in_a_bounded_property_will_pass_4_4.ids --> 2
and they are all checked against the same IFC model, just with different names:
- pass-any_matching_value_in_a_bounded_property_will_pass_1_4.ifc
- pass-any_matching_value_in_a_bounded_property_will_pass_2_4.ifc
- pass-any_matching_value_in_a_bounded_property_will_pass_3_4.ifc
- fail-any_matching_value_in_a_bounded_property_will_pass_4_4.ifc
which contains the following attributes:
- UpperBoundValue=5000
- LowerBoundValue=1000
- SetPointValue=3000
I get that the IFC is using a millimetre unit, while the IDS is in metres, so we are comparing 1, 5, 3, 2 with >=1; <=5; ==3. To me, all four tests should fail.
I tested those four pairs with IfcTester, and all yielded the expected results, so I must be missing something.
@Moult, did you write those? Can you shed some light?
Worth noting SetPointValue was only added in IFC4, and my reading is it's intended for 'operational values' rather than design-time measures. As well as these examples on Spatial Pset_SpaceThermalLoad I've most it seen it employed on sensor measures like Pset_SensorTypeTemperatureSensor where there may be a high/low watermark on a measure.
... which begs the question "what should IDS be checking, and is SetPointValue even relevant". Tellingly I've not seen an example in the IFC standards specifying a value for SetPointValue.
If the requirement was that "All Room temperature sensors should measure between 0 and 50 Celsius" (converted to Kelvin) then really it's just the Upper/Lower bounds we care about? In the original poster's example presumably it's a requirement similar to Pset_SpaceThermalLoad.Lighting be > 0 & < X Watts (where again the SetPointValue is not relevant)?
So far all the IDS examples/tests seems for bounded properties have used simpleValues, and avoided combining Range Constraints. Perhaps we need some more real-world examples as the ones above feel a bit synthetic?
Good point. Let's ignore SetPointValue then and focus on Bounds only.
I would not assume that Lower/UpperBound has to always match IDS min/maxInclusive. Instead, the bounds in IFC should be within the IDS min/max:
Example: IDS could say that the People load should be within 0-20 (Pset_SpaceThermalLoad) and if IFC has value 5-10, that should pass.
Still not sure how to approach data with only one Lower or Upper filled in.
Do you agree, @andyward? If so, we need to add it to the docs and improve/add the test cases to cover it.
@atomczak Agreed we should ignore SetPointValue.
the bounds in IFC should be within the IDS min/max
This makes sense.
In the case of open bounded IDS requirements, isn't it just a case that minInclusive only would check lowerBoundValue >= minInclusive (ignoring upperBoundValue), while maxInclusive only would check upperBoundvalue <= maxInclusive?
An extra wrinkle is that upper and lower bounds are themselves optional in IfcPropertyBoundedValue (i.e. 'open')
Some Examples:
"The minimum Thermal Load for People should be 20kW"
<requirements>
<property cardinality="required" dataType="IFCPOWERMEASURE">
<propertySet>
<simpleValue>Pset_SpaceThermalLoad</simpleValue>
</propertySet>
<baseName>
<simpleValue>People</simpleValue>
</baseName>
<value>
<xs:restriction base="xs:double">
<xs:minInclusive value="20" />
</xs:restriction>
</value>
</property>
</requirements>
With these expected results:
| Lower Bound | Upper Bound | Expected Result |
|---|---|---|
| 20 | 40 | ✔️ |
| 15 | 40 | ❌ |
| 25 | ✔️ | |
| 40 | ❌ |
"The maximum Thermal Load for People should be 50kW"
<requirements>
<property cardinality="required" dataType="IFCPOWERMEASURE">
<propertySet>
<simpleValue>Pset_SpaceThermalLoad</simpleValue>
</propertySet>
<baseName>
<simpleValue>People</simpleValue>
</baseName>
<value>
<xs:restriction base="xs:double">
<xs:maxInclusive value="50" />
</xs:restriction>
</value>
</property>
</requirements>
With these expected results:
| Lower Bound | Upper Bound | Expected Result |
|---|---|---|
| 20 | 40 | ✔️ |
| 20 | 55 | ❌ |
| 25 | ❌ | |
| 40 | ✔️ |
The min/max Exclusive variants would be very similar?
Before touching the tests, I want to know from @Moult why fail-any_matching_value_in_a_bounded_property_will_pass_4_4 actually works (fails) in ifctester.
Just came across the unit test Artur mentioned in the previous comment. To me it's also unclear why this should fail, especially since the only difference in the IDS compared to "pass-any_matching_value_in_a_bounded_property_will_pass_3_4" is the value (3 instead of 2). The relating IFC fles are exactly the same, with lower/upper bound of 1/5 meters. I would think that both the values 2 and 3 are within that same range.
This all has nothing todo with the actual discussion on how this should work in IDS, just trying to comply with the 1.0 version unit tests.
My reading on these 'bounded property' tests is that they are designed to test equality against any of the three attributes of a IfcPropertyBoundedValue (UpperBoundValue, LowerBoundValue, SetPointValue). Importantly, the attributes are tested independently, ignoring any relation between Lower and UpperBounds.
Given this Bounded property value:
#10=IFCPROPERTYBOUNDEDVALUE('Foo',$,IFCLENGTHMEASURE(5.),IFCLENGTHMEASURE(1.),$,IFCLENGTHMEASURE(3.));
... when specifying simpleValues, the only three Real values that will pass are: 5, 1, 3 (I'm simplifying for the fact the actual tests involve unit conversions). Any other value, including 2 will fail - despite 2 being "in the Bounds".
I'm not saying this makes sense immediately, but I see the logic - we're testing the data found explicitly in the model, not the continuum of values that could occur in operation. As mentioned in my November 24 comment above, if you wanted to test values fell within the Bounded range, you'd probably want to use a minInclusive or maxInclusive restriction.
E.g. IfcPropertyBoundedValues seem little used in the official Psets (outside of IfcSensor psets), so imagine a hypothetical bounded property 'AverageEnergyConsumption' might have UpperBound=500W, LowerBound=100W, SetPoint=null - and could be applied to specify/record an appliance's typical energy consumption performance.
That's fairly obviously defining a range of operational values the appliance could operate within. You could make the argument that an IDS spec saying 'All appliances must have AverageEnergyConsumption = 200W' probably should fail for those elements - it's too specific and makes no sense as not every appliance will have the same properties. I don't think a user would ever write this spec for this use case. More likely you'd be specifying 'the AverageEnergyConsumption should be < 1000K', and we'd expect it to pass. Or provide a range of values (0 < n < 1000)
Bottom line: I think these tests are probably a little 'synthetic' and we'd benefit from some more real world tests using range restrictions. But I suspect the above explains how IfcOpenShell (and xbim's) tests are passing currently in IDS1.0.
... when specifying simpleValues, the only three Real values that will pass are: 5, 1, 3 (I'm simplifying for the fact the actual tests involve unit conversions). Any other value, including 2 will fail - despite 2 being "in the Bounds".
Why would we only look at the three values if they define a range? Why would the 2 fail? it is within the bounds and should pass IMO.
See the updates to the documentation we made recently with @CBenghi: https://github.com/buildingSMART/IDS/blob/e1b39e0957abe8ec8cfc4ccb622e254622103d57/Documentation/UserManual/property-facet.md#supported-types-of-properties Do you agree?
Yes OK with the proposed updates to the docs. Feels like this may be a 1.1 change vs retrospective 1.0?
I guess it comes back to my point above about the use cases, and what the semantic intent of '==2' is when compared to a bounded range. Does 2 == 1...5 => true? I think we can agree that 6 > 1...5 => true and 1 < 2...5 => true