View Issue Details

Related ChangesetsJump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0030990CommunityOCCT:Foundation Classespublic2019-09-21 10:292020-07-23 12:43
ReporterabvAssigned Tobugmaster  
PrioritynormalSeverityminor 
Status closedResolutionfixed 
Target Version7.4.0Fixed in Version7.4.0 
Summary0030990: Foundation Classes - unexpected change in numerical results on bsplines after #29769
DescriptionThe problem has been reported by Benjamin Bihler in comments to 0029769, see 0029769:0081087 and further for details.
Steps To Reproducetest bugs fclasses bug30990
TagsNo tags attached.
Test case number

Attached Files

  • bug30990.brep (67,839 bytes)
  • CR30990.zip (49,050 bytes)
  • 0001-0030990-pre29769.patch (45,289 bytes)
  • log_pre29769_ext.txt (223,480 bytes)
  • 0001-0030990-post29769.patch (17,081 bytes)
  • log_post29769_ext.txt (219,144 bytes)

Relationships

child of 0029769 closedabv Foundation Classes - Uninitialized data with BSplCLib_Cache, BSplSLib_Cache 

Activities

abv

2019-09-21 10:34

manager  

bug30990.brep (67,839 bytes)

abv

2019-09-21 10:36

manager  

CR30990.zip (49,050 bytes)

git

2019-09-21 19:28

administrator   ~0087393

Branch CR30990 has been created by abv.

SHA-1: fedda15eb3fc064cf8ac4ed388a3a93b36fb6f37


Detailed log of new commits:

Author: abv
Date: Sat Sep 21 19:24:55 2019 +0300

    0030990: Foundation Classes - unexpected change in numerical results on bsplines after 0029769
    
    Added reproducer (DRAW command) and test case

abv

2019-09-21 21:31

manager   ~0087397

Differences are caused by changes in implementation of cache of surfaces; changes in cache of curves does not affect the results of the test command.

abv

2019-09-23 08:17

manager   ~0087433

The difference is explained by more consistent work of BSpline cache for surfaces after integration of patch for 0029769 (in current master, 7.4.0) as compared to previous state (7.3.0).

Reproducer
==========

I have prepared two patches for investigation of this issue, running the reproducer test case and printing out details on how b-spline evaluation is performed:

- 0001-0030990-pre29769.patch and log_pre29769_ext.txt - patch for commit prior to 0029769 on master, and output produced by running the test case

- 0001-0030990-post29769.patch and log_post29769_ext.txt - patch for commit 0029769 on master, and output produced by running the test case

The comparison of the output shows that on version before 0029769 B-Spline surface cache sometimes does not get updated for points located exactly at knots, and sometimes gets updated unnecessarily (when span index remains the same after update). Version after 0029769 does not exhibit such problems. At the points where the cache is not updated when it should, b-spline gets evaluated using coefficients of neighbour span, which results in deviations from correct value (the deviations are due to different numerical roundings and thus negligible, yet they are the very subject of the original complaint).

Details
=======

The main purpose of the class BSplSLib_Cache is optimization of evaluation of b-spline surfaces by avoiding unnecessary updates of spline coefficients when several points are evaluated in the same spline span. For that BSplSLib_Cache stores the spline coefficients for the last evaluated span, and range of that span (by U and V). Before evaluation of a point, it checks whether it is located on the same span as already cached, and updates cache only when the point is on different span.

The point is considered to be within i-th span if its parameter is within limits [Start=Knot(i), End=Knot(i+1)) where Knot(i) is i-th knot of the b-spline. Note that range includes start knot but not includes end knot. That is, if parameter is equal to knot, the point is evaluated using span that starts at that knot. This behavior is the same for curves and surfaces, and is implemented in BSplCLib::LocateParameter().

BSpline cache has to update span coefficients when point gets into the span different from the current one, and for that the parameter (for surface, for both U and V) P is compared against the range of the current span (see method BSplSLib_Cache::IsCacheValid()).

Formally this comparison is consistent with BSplCLib::LocateParameter() in both OCCT 7.3.0 and current master. However, cache for surfaces (BSplSLib_Cache) in 7.3.0 does not store original span range, instead it stores mid-point of the range and its half length. When check for parameter to be in range is performed, actual range is recovered from stored values, and apparently these calculations may lead to loss of precision. The result is that for parameter equal to the end of the range of the current span that method sometimes returns True. The point is then evaluated using spline coefficients of the previous span.

Within 0029769, this logic has been extracted to separate class BSplCLib_LocateParameter and is now the same for curves and surfaces. Now start of the range is stored as-is (while still the length of the span is stored instead of the end of the range). Even if the latter may potentially lead to similar issues as described above, current implementation is found to be much more stable and shows no errors on the tested cases.

abv

2019-09-23 08:18

manager  

0001-0030990-pre29769.patch (45,289 bytes)

abv

2019-09-23 08:18

manager  

log_pre29769_ext.txt (223,480 bytes)

abv

2019-09-23 08:18

manager  

0001-0030990-post29769.patch (17,081 bytes)

abv

2019-09-23 08:18

manager  

log_post29769_ext.txt (219,144 bytes)

git

2019-09-23 08:20

administrator   ~0087434

Branch CR30990 has been updated forcibly by abv.

SHA-1: 42027f4e33e4d81937edc8c2dff9d5b328bae7ef

abv

2019-09-23 08:27

manager   ~0087435

I have pushed a branch CR30990 containing a test case for reproducing the problem with update of the b-spline cache. It evaluates B-SPline surface by computing points at U and V located exactly at b-spline knots, after evaluation of points inside the spans before and after the knot, and checks that result at the knot is exactly the same regardless of previous evaluation (i.e. the cache is updated as necessary). The test is OK on master while gives 22 errors on version before 0029769. Please review.

BenjaminBihler

2019-09-23 11:36

reporter   ~0087445

No objections from my side and no worries anymore. The seeming deterioration of program behaviour was just a phantom. Thank you for your investigations.

abv

2019-09-24 13:52

manager   ~0087474

New test is OK on current master on both Windows and Linux: see Jenkins job CR30990-abv. Please integrate

bugmaster

2019-09-24 14:18

administrator   ~0087477

Combination -
OCCT branch : CR30990
master SHA - 42027f4e33e4d81937edc8c2dff9d5b328bae7ef
5f5b1aed1c6e139bbd34314eca77ae7abcd8895c
Products branch : master SHA - cede13b0d79b1c3448ecd68f0db85c2a087762ad
was compiled on Linux, MacOS and Windows platforms and tested in optimize mode.

Number of compiler warnings:
No new/fixed warnings

Regressions/Differences/Improvements:
No regressions/differences

CPU differences:
Debian80-64:
OCCT
Total CPU difference: 16834.18000000005 / 16808.79000000008 [+0.15%]
Products
Total CPU difference: 10551.000000000033 / 10561.440000000042 [-0.10%]
Windows-64-VC14:
OCCT
Total CPU difference: 18245.234375 / 18298.78125 [-0.29%]
Products
Total CPU difference: 12465.265625 / 12507.671875 [-0.34%]


Image differences :
No differences that require special attention

Memory differences :
No differences that require special attention

git

2019-09-29 12:36

administrator   ~0087626

Branch CR30990 has been deleted by inv.

SHA-1: 42027f4e33e4d81937edc8c2dff9d5b328bae7ef

Related Changesets

occt: master 0a5ec5f3

2019-09-23 03:34:09

abv


Committer: bugmaster Details Diff		 0030990: Foundation Classes - unexpected change in numerical results on bsplines after 0029769

Added DRAW command and test case for detection of inconsistent update of B-Spline surface cache		 Affected Issues
0030990
mod - src/QABugs/QABugs_20.cxx Diff File
add - tests/bugs/fclasses/bug30990 Diff File

Issue History

Date Modified Username Field Change
2019-09-21 10:29 abv New Issue
2019-09-21 10:29 abv Assigned To => abv
2019-09-21 10:29 abv Relationship added child of 0029769
2019-09-21 10:30 abv Status new => assigned
2019-09-21 10:30 abv Target Version 7.5.0 => 7.4.0
2019-09-21 10:30 abv Description Updated
2019-09-21 10:34 abv File Added: bug30990.brep
2019-09-21 10:36 abv File Added: CR30990.zip
2019-09-21 19:28 git Note Added: 0087393
2019-09-21 21:31 abv Note Added: 0087397
2019-09-23 08:17 abv Note Added: 0087433
2019-09-23 08:18 abv File Added: 0001-0030990-pre29769.patch
2019-09-23 08:18 abv File Added: log_pre29769_ext.txt
2019-09-23 08:18 abv File Added: 0001-0030990-post29769.patch
2019-09-23 08:18 abv File Added: log_post29769_ext.txt
2019-09-23 08:20 git Note Added: 0087434
2019-09-23 08:27 abv Note Added: 0087435
2019-09-23 08:27 abv Assigned To abv => BenjaminBihler
2019-09-23 08:27 abv Status assigned => resolved
2019-09-23 08:27 abv Steps to Reproduce Updated
2019-09-23 11:36 BenjaminBihler Note Added: 0087445
2019-09-23 11:37 BenjaminBihler Assigned To BenjaminBihler => abv
2019-09-24 13:52 abv Note Added: 0087474
2019-09-24 13:52 abv Assigned To abv => bugmaster
2019-09-24 13:52 abv Status resolved => reviewed
2019-09-24 14:18 bugmaster Note Added: 0087477
2019-09-24 14:18 bugmaster Status reviewed => tested
2019-09-29 12:19 bugmaster Changeset attached => occt master 0a5ec5f3
2019-09-29 12:19 bugmaster Status tested => verified
2019-09-29 12:19 bugmaster Resolution open => fixed
2019-09-29 12:36 git Note Added: 0087626