IVS-137 ALB012 Vertical Segment Radius of Curvature #300

civilx64 · 2024-10-10T13:15:45Z

Fixes #241

Also adds an additional check per Note 3 on the RadiusOfCurvature attribute in the
IFC 4.3.2.0 schema documentation.

Scenarios for validating the horizontal continuity were added. Those scenarios should be implemented in another rule, but were maintained in the commit to be evaluated, and should be altered after

…erkin-rules into IVS-137-ALB011-IfcAlignmentVerticalSegment.RadiusOfCurvature

It was created a function of comparison that considers the instance context precision tolerance. This function was added in the 'then' step that compares an attributes to an expression.

ALB010 is already in use. Renaming this feature will allow for a new rule ALB011 to check RadiusOfCurvature for the horizontal layout. (IVS-137)

…gment.RadiusOfCurvature

…ature' of https://github.com/fg55b/ifc-gherkin-rules into IVS-137-ALB012-IfcAlignmentVerticalSegment.RadiusOfCurvature

(IVS-143)

ALB012 focuses solely on 'RadiusOfCurvature' design parameter and includes a scenario that fixes #241. (IVS-137)

aothms · 2024-10-11T07:59:33Z

features/steps/thens/attributes.py

+        'equal to' : operator.eq,
+        'not equal to' : operator.ne,
+        'greater than' : operator.gt,
+        'less than' : operator.gt,
+        'greater than or equal to' : operator.ge,
+        'less than or equal to' : operator.le,


I guess with str.split these operator keys can never be matched. Not a problem for now, but maybe remove them in order not to give false hope.

equal to is being matched for the second scenario so should be OK to leave as-is

features/ALB012_Alignment-vertical-segment-radius-of-curvature.feature

aothms · 2024-10-11T08:04:12Z

features/steps/thens/attributes.py

+    try:
+        expression_value = eval(expression)
+    except Exception as e:
+        raise ValueError(f"Error evaluating expression: {e}")


I've asked this before but what's currently the behaviour of raising exceptions?

What happens for example with a ZeroDivisionError.

Regarding that specifically should there be some rules to prevent zeros in the denominator in this equation?

IIRC, in case there is an error unrelated to the rule (e.g. a ZeroDivisionError as mentioned earlier), it's a bit annoying for the gherkin CI/CD but without consequences for subsequent rules.

It would be nice to have something in the decorator or validation_handling that could return an ERROR outcome whenever an exception is raised. I started to replace all of the raise statements with yield ValidationOutcome(... ValidationSeverity.ERROR) but that felt like a non-pythonic brute force approach.

What happens for example with a ZeroDivisionError.

It is not caught in CI/CD. There is nothing in place to handle the exception and therefore the process fails before it can yield a ValidationOutcome with severity ERROR. Current pytest logic is still 0 errors = pass, not all results are ValidationOutcome(ValidationSeverity.PASSED).

resolved in 6a3c82f

aothms · 2024-10-11T08:09:01Z

features/ALB012_Alignment-vertical-segment-radius-of-curvature.feature

+
+  Scenario: Validating the absence of curvature radius for constant gradient vertical segment
+    Given PredefinedType != 'ARC' or 'PARABOLICARC'
+    Then The value of attribute RadiusOfCurvature must be empty


The correspondence of IfcAlignmentVertical <- nests -> Segment -> IfcAlignmentVerticalSegment is assessed in ALB002. But we don't have rule dependencies. Are we sure that violations of ALB002 don't cause crashes in ALB012 causing the entire validation task to fail?

ALB002 is currently disabled with an item in backlog to be re-activated. I added a link to this comment to the ALB002 reactivation ticket IVS-75 so that I remember to verify independence of ALB002 and ALB012 in UAT.

ALB002 is currently deactivated.

We indeed don't have rule dependencies (should we?). I did some experiments, activated the rule again and ensured that ALB002 always fails when the step you mentioned is reached. The result is that both rules (ALB012 and ALB002) fail

I reviewed the test files for ALB002 and ran them on a deployment of the gherkin repository, which included ALB012. It seems that ALB012 runs even when the correspondence fails.

IIRC, in case there is an error unrelated to the rule (e.g. a ZeroDivisionError as mentioned earlier), it's a bit annoying for the gherkin CI/CD but without consequences for subsequent rules.

That appears even worse. Is this logic never checked?

ifc-gherkin-rules/features/ALB002_Alignment-layout.feature

Lines 53 to 64 in 31df653

Scenario Outline: Agreement of the segments of alignment

Given an IfcAlignmentSegment

Given The element nests an <AlignmentComponentType>

Then The type of attribute DesignParameters must be <SegmentType>

Examples:

| AlignmentComponentType | SegmentType |

| IfcAlignmentHorizontal | IfcAlignmentHorizontalSegment |

| IfcAlignmentVertical | IfcAlignmentVerticalSegment |

| IfcAlignmentCant | IfcAlignmentCantSegment |

I'm just worried about the AttributeErrors when DesignParameters is not of type IfcAlignmentVerticalSegment

I agree, for some reason I thought it was IfcAlignmentVerticalSegment that nests IfcAlignmentVertical and that IfcAlignmentSegment was a supertype.

~~Do we have an implementation "Given attribute is of type {entity_type}? I looked briefly earlier and didn't find anything.~~

Edit: I found the Given and added it to the background.

~~Regardless of where this lands I will add additional fail files so that we are certain that the type check is handled correctly for both ALB002 and ALB012.~~

I added a test file na-alb012-incorrect_type_for_DesignParameters_attirbute.ifc. Because of the new Given in ALB012, the incorrect type will mean that ALB012 is not activated. However ALB002 will still capture this as an error. Or at least that is the design intent.

Coming back to the original question:

Are we sure that violations of ALB002 don't cause crashes in ALB012 causing the entire validation task to fail?

Yes, we are sure now because of the additional Given statement in the feature's Background.

aothms · 2024-10-11T08:09:35Z

features/steps/thens/attributes.py

+
+@gherkin_ifc.step('First instance {first_expression} value must be {comparison_op} the second instance {second_expression}')
+@gherkin_ifc.step('First instance {first_expression} value must be {comparison_op} the second instance {second_expression} at depth 1')
+def step_impl(context, inst, first_expression:str, comparison_op:str, second_expression:str):


I don't see a usage of this impl function

Correct, and thanks for the catch. We originally had a number of additional scenarios and this one handles the check of StartDistAlong that I mentioned in Slack. See also IVS-150 in JIRA. I would like to leave it in for now so that it's there fore future rules.

After another look I see that there is some duplicated code and there is likely benefit in using itertools.piecewise() for consistency with ALS implementation. I've removed this function and stored in a gist for the time being at https://gist.github.com/civilx64/9d533dc44d6b2fa4a4ef21bd79963a3c.

aothms · 2024-10-11T08:11:53Z

features/steps/utils/geometry.py

+        'less than or equal to'. 
+    '''
+    if comparison_operator == 'equal to':
+        return math.isclose(value_1, value_2, abs_tol=precision)


rel_tol has a default value. Should we set it to 0? https://docs.python.org/3/library/math.html#math.isclose

From the docs:

rel_tol must be greater than zero.

The implementation seems to be correct as-is.

The code disagrees. I really prefer to be explicit about this. If we want a relative tolerance in addition to an absolute tolerance I prefer that we write it down in the code as an act of explicitly documenting our behaviour. I think only an absolute tolerance better matches the intent of the IFC spec (even if that's very limited).

>>> import math >>> math.isclose(1.0, 1.0, rel_tol=0.) True >>> math.isclose(1.0, 1.0, rel_tol=-1.0) Traceback (most recent call last): File "<stdin>", line 1, in <module> ValueError: tolerances must be non-negative

I see. Implemented in 515cc49.

Co-authored-by: Thomas Krijnen <[email protected]>

civilx64 · 2024-10-11T13:42:30Z

~~Need to step away for a bit. Will revisit soon to finalize.~~

A few things to discuss in order to wrap up the PR:

Raising and handling Exceptions versus ValidationOutcomes with ERROR severity
Avoiding ZeroDivisionError. One solution would be an addition additional scenario to enforce StartGradient = EndGradient for CONSTANTGRADIENT only.

- adds a Given statement for proper entity type of DesignParameters - adds `na` unit test file to confirm this new Given statement - adds `na` unit test file to confirm rule is not activated for alignment with horizontal layout only (IVS-137)

(IVS-137)

fg55b · 2024-10-18T01:18:20Z

features/steps/thens/attributes.py

-        )
+@gherkin_ifc.step('The value of attribute {attribute} must be {value_or_comparison_op}')
+@gherkin_ifc.step('The value of attribute {attribute} must be {value_or_comparison_op} {display_entity:display_entity}')
+@gherkin_ifc.step('The value of attribute {attribute} must be {value_or_comparison_op} the expression: {expression}')


Do you think that using this with constant values directly in place of the expression would be confusing? For example, “The value of attribute must be equal to the expression: 0”?

I ask because, in ALB011, the StartRadiusOfCurvature and EndRadiusOfCurvature of IfcAlignmentHorizontalSegment need to be zero or non-zero according to its PredefinedType. This cannot be verified with the first expression because "The value of attribute must be 0.0" would compare the 0.0 float value of the IFC file with the 0.0 string value declared on the rule. It also does not consider the precision.

“The value of attribute must be equal to the expression: 0”

While maybe not ideal, this pattern would be fine IMHO.

I would first try to fit it into

https://github.com/buildingSMART/ifc-gherkin-rules/blob/development/features/steps/thens/attributes.py#L63

Could be as simple as:

>>> import ast >>> required = '1.0' >>> try: required = ast.literal_eval(required) ... except: pass ... >>> type(required) <class 'float'>

But maybe also take into account tolerances when you detect you're comparing floats

“The value of attribute must be equal to the expression: 0”

While maybe not ideal, this pattern would be fine IMHO.

This would be particularly useful to evaluate if StartRadiusOfCurvature and EndRadiusOfCurvature of IfcAlignmentHorizontalSegment is not zero for nonlinear PredefinedTypes, as the "not equal to" operator can be used.

I would first try to fit it into

https://github.com/buildingSMART/ifc-gherkin-rules/blob/development/features/steps/thens/attributes.py#L63

Could be as simple as:

>>> import ast >>> required = '1.0' >>> try: required = ast.literal_eval(required) ... except: pass ... >>> type(required) <class 'float'>

But maybe also take into account tolerances when you detect you're comparing floats

The comparison using tolerances, after evaluating the string, can be done using

ifc-gherkin-rules/features/steps/utils/geometry.py

Line 227 in 42959f2

def compare_with_precision(value_1: float, value_2: float, precision: float, comparison_operator: str) -> bool:

However, the expression as is would only compare using the "equal to" operator, which is not applicable to this case.

Ghesselink · 2024-10-22T09:35:27Z

features/steps/utils/geometry.py

+def compare_with_precision(value_1: float, value_2: float, precision: float, comparison_operator: str) -> bool:
+    """
+    Compare the value_1 with value_2 according to a comparison operator, considering a precision tolerance.
+
+    The valid comparison operators are:
+        'equal to';
+        'not equal to';
+        'greater than';
+        'less than';
+        'greater than or equal to';
+        'less than or equal to'. 
+    """
+    if comparison_operator == 'equal to':
+        return math.isclose(value_1, value_2, rel_tol=0., abs_tol=precision)
+    elif comparison_operator == 'not equal to':
+        return not math.isclose(value_1, value_2, rel_tol=0., abs_tol=precision)
+    elif comparison_operator == 'greater than':
+        return value_1 > value_2 and not math.isclose(value_1, value_2, rel_tol=0., abs_tol=precision)
+    elif comparison_operator == 'less than':
+        return value_1 < value_2 and not math.isclose(value_1, value_2, rel_tol=0., abs_tol=precision)
+    elif comparison_operator == 'greater than or equal to':
+        return value_1 > value_2 or math.isclose(value_1, value_2, rel_tol=0., abs_tol=precision)
+    elif comparison_operator == 'less than or equal to':
+        return value_1 < value_2 or math.isclose(value_1, value_2, rel_tol=0., abs_tol=precision)
+    else:
+        raise ValueError(f"Invalid comparison operator: {comparison_operator}")


What do you think of the following?

operators = { 'equal to': lambda: math.isclose(value_1, value_2, abs_tol=precision), 'not equal to': lambda: not math.isclose(value_1, value_2, abs_tol=precision), 'greater than': lambda: value_1 > value_2 and not math.isclose(value_1, value_2, abs_tol=precision), 'less than': lambda: value_1 < value_2 and not math.isclose(value_1, value_2, abs_tol=precision), 'greater than or equal to': lambda: value_1 > value_2 or math.isclose(value_1, value_2, abs_tol=precision), 'less than or equal to': lambda: value_1 < value_2 or math.isclose(value_1, value_2, abs_tol=precision) } if comparison_operator not in operators: raise ValueError(f"Invalid comparison operator: {comparison_operator}") return operators[comparison_operator]()

Perhaps it's a bit easier to read than if/else statements

Actually worse IMO. Replaced with pattern matching in f6fc490.

Ghesselink · 2024-10-22T10:05:51Z

features/steps/thens/attributes.py

+        'less than or equal to' : operator.le,
+    }
+
+    if expression is not None:


Can probably be simply

Suggested change

if expression is not None:

if expression:

Ref: Zen of Python -

Explicit is better than implicit

I say let it stand.

Ghesselink · 2024-10-22T10:09:41Z

features/steps/thens/attributes.py

+    operators = {
+        '+' : operator.add,
+        '-' : operator.sub,
+        '*' : operator.mul,
+        '/' : operator.truediv,
+        '%' : operator.mod,
+        '**' : operator.pow,
+        'equal to' : operator.eq,
+        'not equal to' : operator.ne,
+        'greater than' : operator.gt,
+        'less than' : operator.gt,
+        'greater than or equal to' : operator.ge,
+        'less than or equal to' : operator.le,
+    }


We're using operators at quite some points in the code now. What do you think of moving them to a dataclass and seperating them into arithmetic operators, comparison operators and the various interpretations of operators.
Maybe not in the scope of this PR, but what about a ticket with these kind of cleanup/maintanance tasks?

Ticket is good. This PR is turning into a marathon and I'd like to wrap up.

…m/buildingSMART/ifc-gherkin-rules into IVS-137-ALB012-IfcAlignmentVerticalSegment.RadiusOfCurvature

The test file that raises an exception should start with 'fail'. (IVS-137)

…gment.RadiusOfCurvature

civilx64 · 2024-10-24T02:45:02Z

A few things to discuss in order to wrap up the PR:

1. Raising and handling Exceptions versus ValidationOutcomes with ERROR severity

2. Avoiding ZeroDivisionError.  One solution would be an addition additional scenario to enforce StartGradient = EndGradient for CONSTANTGRADIENT only.

Exception handling added in 6a3c82f. Thanks @Ghesselink!

(IVS-137)

civilx64 and others added 11 commits September 24, 2024 10:51

add ALB011 unit test files

1d2c578

feat/first commit of ALB011

9bd31c8

feat/added scenarios and steps

bc9c3e8

Scenarios for validating the horizontal continuity were added. Those scenarios should be implemented in another rule, but were maintained in the commit to be evaluated, and should be altered after

Merge branch 'development' of https://github.com/buildingSMART/ifc-gh…

2e49010

…erkin-rules into IVS-137-ALB011-IfcAlignmentVerticalSegment.RadiusOfCurvature

feat/added precision tolerance to the comparison

fc93553

It was created a function of comparison that considers the instance context precision tolerance. This function was added in the 'then' step that compares an attributes to an expression.

feat/update compare function description

b89ae45

rename ALB011 to ALB012

9969602

ALB010 is already in use. Renaming this feature will allow for a new rule ALB011 to check RadiusOfCurvature for the horizontal layout. (IVS-137)

Merge branch 'development' into IVS-137-ALB012-IfcAlignmentVerticalSe…

7670846

…gment.RadiusOfCurvature

Merge branch 'IVS-137-ALB011-IfcAlignmentVerticalSegment.RadiusOfCurv…

50ace43

…ature' of https://github.com/fg55b/ifc-gherkin-rules into IVS-137-ALB012-IfcAlignmentVerticalSegment.RadiusOfCurvature

rename ALB011 to ALB012

7f21949

(IVS-143)

finalize ALB012 feature file and unit tests

29922bd

ALB012 focuses solely on 'RadiusOfCurvature' design parameter and includes a scenario that fixes #241. (IVS-137)

civilx64 requested a review from Ghesselink October 10, 2024 13:15

aothms reviewed Oct 11, 2024

View reviewed changes

Update feature file per review comments

f5f6237

Co-authored-by: Thomas Krijnen <[email protected]>

civilx64 marked this pull request as draft October 11, 2024 13:41

civilx64 added 3 commits October 12, 2024 07:49

add explicit relative tolerance for value comparisons

515cc49

(IVS-137)

add unit test file that raises ZeroDivisionError

42959f2

(IVS-137)

fg55b reviewed Oct 18, 2024

View reviewed changes

Ghesselink reviewed Oct 22, 2024

View reviewed changes

Ghesselink and others added 5 commits October 22, 2024 21:46

IVS-181 Fix/Custom Error Handling

d477990

Update wording

21a5c6f

Merge branch 'IVS-181-Fix-Custom-Error-Handling' of https://github.co…

6a3c82f

…m/buildingSMART/ifc-gherkin-rules into IVS-137-ALB012-IfcAlignmentVerticalSegment.RadiusOfCurvature

rename test file for ALB012

3de923b

The test file that raises an exception should start with 'fail'. (IVS-137)

Merge branch 'development' into IVS-137-ALB012-IfcAlignmentVerticalSe…

d4190bc

…gment.RadiusOfCurvature

civilx64 marked this pull request as ready for review October 24, 2024 02:40

civilx64 requested a review from Ghesselink October 24, 2024 02:40

avoid NoneTypeError when processing outcomes

c382fe7

(IVS-137)

refactor compare_with_precision() to use pattern matching

f6fc490

(IVS-137)

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

IVS-137 ALB012 Vertical Segment Radius of Curvature #300

IVS-137 ALB012 Vertical Segment Radius of Curvature #300

civilx64 commented Oct 10, 2024

aothms Oct 11, 2024

civilx64 Oct 11, 2024

aothms Oct 11, 2024

civilx64 Oct 12, 2024

civilx64 Oct 12, 2024 •

edited

Loading

civilx64 Oct 24, 2024

aothms Oct 11, 2024

civilx64 Oct 11, 2024

Ghesselink Oct 11, 2024 •

edited

Loading

aothms Oct 11, 2024

civilx64 Oct 11, 2024 •

edited

Loading

civilx64 Oct 12, 2024

aothms Oct 11, 2024

civilx64 Oct 11, 2024 •

edited

Loading

aothms Oct 11, 2024

civilx64 Oct 12, 2024 •

edited

Loading

aothms Oct 12, 2024

civilx64 Oct 12, 2024

civilx64 commented Oct 11, 2024 •

edited

Loading

fg55b Oct 18, 2024

civilx64 Oct 18, 2024

aothms Oct 18, 2024

fg55b Oct 18, 2024

Ghesselink Oct 22, 2024

civilx64 Oct 24, 2024

Ghesselink Oct 22, 2024

civilx64 Oct 24, 2024

Ghesselink Oct 22, 2024

civilx64 Oct 24, 2024

civilx64 commented Oct 24, 2024

	Scenario Outline: Agreement of the segments of alignment

	Given an IfcAlignmentSegment
	Given The element nests an <AlignmentComponentType>

	Then The type of attribute DesignParameters must be <SegmentType>

	Examples:
	\| AlignmentComponentType \| SegmentType \|
	\| IfcAlignmentHorizontal \| IfcAlignmentHorizontalSegment \|
	\| IfcAlignmentVertical \| IfcAlignmentVerticalSegment \|
	\| IfcAlignmentCant \| IfcAlignmentCantSegment \|

IVS-137 ALB012 Vertical Segment Radius of Curvature #300

Are you sure you want to change the base?

IVS-137 ALB012 Vertical Segment Radius of Curvature #300

Conversation

civilx64 commented Oct 10, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

civilx64 Oct 12, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Ghesselink Oct 11, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

civilx64 Oct 11, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

civilx64 Oct 11, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

civilx64 Oct 12, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

civilx64 commented Oct 11, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

civilx64 commented Oct 24, 2024

civilx64 Oct 12, 2024 •

edited

Loading

Ghesselink Oct 11, 2024 •

edited

Loading

civilx64 Oct 11, 2024 •

edited

Loading

civilx64 Oct 11, 2024 •

edited

Loading

civilx64 Oct 12, 2024 •

edited

Loading

civilx64 commented Oct 11, 2024 •

edited

Loading