IfcPropertyBoundedValue tests

[atomczak]

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 #372 (comment).

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?

[andyward]

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?

[atomczak]

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.

[andyward]

@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?

[atomczak]

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.