MantisBT
Mantis Bug Tracker Workflow

View Issue Details Jump to Notes ] Related Changesets ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0024826Community[OCCT] OCCT:Foundation Classespublic2014-04-14 10:162016-09-08 21:34
ReporterIstvan Csanady 
Assigned Tobugmaster 
PrioritynormalSeverityfeature 
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Version[OCCT] 6.9.0Fixed in Version[OCCT] 6.9.0 
Summary0024826: Wrapping of parallelisation algorithms
DescriptionAs an OCCT user I would find it useful, to have the Intel TBB parallelisation methods wrapped in the TKernel framework, to be able to support different multithreading libraries such as Grand Central Dispatch on OSX, and to be able to use these wrappers in a uniform way.

Note: currently parallel_for_each is used in the BRepMesh meshing algorithm, and the parallel_for is used in the "Parallelization FillDS part of BO" story. It is pretty easy to provide such constructs with GCD, as I mentioned in this forum thread: http://dev.opencascade.org/index.php?q=node/909 [^]
Providing a C++ interface with a factory method would be nice, but a simple macro like solution (like in the BOPCol_TBB.hxx) could be useful as well. Also see this forum topic, and the references in it: https://groups.google.com/forum/#!searchin/oce-dev/gcd/oce-dev/l8wU6mpZtlA/WJNzd244xr8J [^]
Steps To Reproducenot applicable
TagsNo tags attached.
Test case numberNot needed
Attached Filesxls file icon CR24826-perf_01.xls (14,336 bytes) 2015-02-03 18:18
xls file icon CR24826-perf_02.xls (14,336 bytes) 2015-02-04 18:02

- Relationships
related to 0021961closedpdn Open CASCADE Paralleling BRepMesh using Intel TBB tools 
related to 0024639closedmkv Open CASCADE Parallelization FillDS part of BO 
related to 0022146assignedabv Open CASCADE Integration of OCC in-house parallelization tool 
parent of 0025801closedbugmaster Open CASCADE Some of the commands in BOPTest packages show the execution time without -t key 
related to 0025545closedbugmaster Community TopLoc_Location::Transformation() provokes data races 

-  Notes
(0028844)
kgv (developer)
2014-04-15 14:15

Just to notice - parallel_for is used also in OpenGl_RaytraceGeometry.
(0029073)
Istvan Csanady (developer)
2014-04-25 13:47

Just an example to show how simple it is to write a parallel_for_each with the dispatch API:
    dispatch_group_t syncGroup = dispatch_group_create();
    for (auto iter : container)
    {
        dispatch_group_async(syncGroup, dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
            process(iter)
        });
    }
    dispatch_group_wait(syncGroup, DISPATCH_TIME_FOREVER);
(0030869)
git (administrator)
2014-08-19 10:46

Branch CR24826 has been created by azn.

SHA-1: 6bfc8cbce36add7026719a1ab205b819f0892441


This branch includes the following new commits:

       new 6bfc8cb 0024826: Wrapping of parallelisation algorithms 0022146: Integration of OCC in-house parallelization tool


Detailed log of new commits:

commit 6bfc8cbce36add7026719a1ab205b819f0892441
Author: azn
Date: Tue Aug 19 10:44:01 2014 +0400

    0024826: Wrapping of parallelisation algorithms
    0022146: Integration of OCC in-house parallelization tool
    
    - Added new structures and wrappers for parallelization.
(0031884)
git (administrator)
2014-09-19 11:02

Branch CR24826 has been updated by azn.

SHA-1: 33adb1b9f3c5014f006f075dc6338f7a3738187b


Detailed log of new commits:

Author: azn
Date: Fri Sep 19 11:01:15 2014 +0400

    0024826: Wrapping of parallelisation algorithms
    
    - Implement ParallelForEach parallel primitive.

(0032124)
git (administrator)
2014-09-25 12:03

Branch CR24826 has been updated by azn.

SHA-1: a012b30ef8408108535470117798d1cbabe3d346


Detailed log of new commits:

Author: azn
Date: Thu Sep 25 12:03:05 2014 +0400

    0024826: Wrapping of parallelisation algorithms
    
    - Implementation of alternative parallel primitives to BRepMesh and BOP modules.

(0032287)
dbp (developer)
2014-09-29 11:22
edited on: 2014-09-29 11:23

Dear azn,

Please consider the following remarks:

//! Returns mutex instance.
static Standard_Mutex& mutex()
{
  static Standard_Mutex aMutex;
  return aMutex;
}

Here the static variable is used, thus it is shared over all instances of class Range.Therefore, execution of one task can affect on the execution of another task. You probably should use mutable member variable for mutex.

//! Returns first non processed element or end.
//! Thread-safe method.
Value It() const
{
  Standard_Mutex::Sentry aMutex( mutex() );
  return ( myIt != myEnd ) ? myIt++ : myEnd;
}

It is ok for heavy tasks. Hovewer, for small tasks (i.e., transformation of millions of vertices according to some matrix) syncronization overhead can be too high (performance can degrade significantly). For many collections (like vector, array, ...) we can use atomics, which are almost free.

static Standard_Address Run(Standard_Address theTask)

Can we use explicit type for the argument (Task<Functor, InputIterator>)?

Also please check code style in your patch (the are several inaccuracies with brackets and naming conventions: ( mutex() ), i, ...).

The separate question is about test code (ParallelTest_Calculator in QABugs_19.cxx). We probably demonstrate where this functionality should NOT be used. Calculations are too simple to get any performance boost. It is interesting to show several examples of tasks (of different complexity) and measure actual acceleration in each case. Also it would be great to compare performance of our solution with OpenMP and Intel TBB for some widely used example (saxpy is a good choice). We need to understand the efficiency of our solution to ensure proper use in various problems.

(0032340)
kgv (developer)
2014-09-29 23:03
edited on: 2014-09-29 23:04

+aNumLogicalProcessors = (Standard_Integer)sysconf(_SC_NPROCESSORS_ONLN);

please notice that this does not work as expected on Android platform - current implementation of sysconf returns random number of active (not in power-safe suspended mode) cores.
There is workaround based on parsing "/sys/devices/system/cpu/present" and "/sys/devices/system/cpu/possible" from sysfs.

(0032503)
git (administrator)
2014-10-01 13:14

Branch CR24826 has been updated by azn.

SHA-1: ab8d390727f4ddb99fafdb7b55b8ed2e1a9c106c


Detailed log of new commits:

Author: azn
Date: Wed Oct 1 13:12:18 2014 +0400

    0024826: Wrapping of parallelisation algorithms
    
    Simple parallelization primitives for the loops "for" and "foreach" were implemented.
    This realization is based on the templates. Therefore the next functor-interface should be realized:
    
    // Example
    class Functor
    {
    public:
      void operator() ([proccesing instance]) const
      {
        //...
      }
    };
    
    These primitives wrap tbb::parallel_for and tbb::parallel_for_each interfaces if TBB library is used.
    All parts of OCC code which are using tbb were changed on new primitives.

(0032620)
git (administrator)
2014-10-03 12:58

Branch CR24826 has been updated forcibly by azn.

SHA-1: 6c0b0abb1b3543ee656845100b45c032ce4944a1
(0032622)
git (administrator)
2014-10-03 13:08

Branch CR24826 has been updated forcibly by azn.

SHA-1: 7a076286d5b39dfef41c89a9eb0db88dddfc07db
(0033146)
abv (manager)
2014-10-15 15:59

Some remarks:

- In BRepMesh_WireInterferenceChecker, Standard_Mutex::Sentry is created inside if{} where it does not have sense, please correct
- Class OSD_Parallel does not have description, please provide
(0034975)
git (administrator)
2014-12-03 17:08

Branch CR24826 has been updated forcibly by azn.

SHA-1: c3b77c3acc31ab1c19a901b83a683be372857d10
(0034985)
kgv (developer)
2014-12-03 20:38

+  if ( trheArgc != 2 )
+  {
+    theDI << "Usage: "
+          << theArgv[0]
+          << " vec_length\n";
+    return 0;

wrong syntax should be treated as error - command should return 1 and use std::cout to report error. Please also use theDI.PrintHelp().

+  Standard_Integer aLength = atoi(theArgv[1]);

Draw::Atoi() should be used instead.

+  theCommands.Add ("OCC24826,", "Usage: OCC24826 vec_length", __FILE__, OCC24826, 
group);

this is not applicable adding new command without description.

+  //! Simple primitive for parallelization of "for" loops.
+  template <typename Functor>
+  static Standard_EXPORT void ParallelFor( const Standard_Integer theBegin,
+                                           const Standard_Integer theEnd,
+                                           const Functor&         theFunctor );

inline methods can not be exported

+  //! Returns number of logical proccesrs.
+  static Standard_EXPORT Standard_Integer getCountLogicalProcessors();

why it is private? The name "NbLogicalProcessors" would be better.

+    mutable Value          myIt;    //!< First non processed elemnt of range.

elemnt -> element

+
+class OSD_Parallel
+{

should not be this class documented?

--- /dev/null
+++ b/src/OSD/OSD_Parallel.cxx
@@ -0,0 +1,77 @@
+#include <OSD_Parallel.hxx>
+

file header is missing.

--- a/src/MeshTest/MeshTest_PluginCommands.cxx
+++ b/src/MeshTest/MeshTest_PluginCommands.cxx
@@ -83,7 +83,6 @@ void MeshTest::PluginCommands(Draw_Interpretor& theCommands)
     __FILE__, mpparallel, g);
   theCommands.Add("triarea","shape [eps]  (computes triangles and surface area)",__FILE__, 
triarea, g);
   theCommands.Add("tricheck", "shape   (checks triangulation of shape)", __FILE__, 
tricheck, g);
-  

unrelated change.

Please provide some numbers for comparison between tbb / built-in replacement on several scenarios for BRepMesh and ray-tracing (ask Denis for test cases).
(0035084)
git (administrator)
2014-12-05 18:39

Branch CR24826 has been updated forcibly by azn.

SHA-1: abb6e1de602e6c1bd631354475763d5913711026
(0035128)
msv (developer)
2014-12-08 13:37

The parallel framework developed in scope of this bug is to be applied to the command OCC25545, so as to make it functioning in absence of TBB.
(0035177)
msv (developer)
2014-12-09 03:06

I have had a look at the branch. I have the following remark, though may be it concerns not the changes of this branch but the initial code:

File BOPCol_Parallel.hxx
In the method BOPCol_ContextCnt::Perform, when bRunParallel is true, context is not passed to aFunctor.
(0035262)
abv (manager)
2014-12-10 14:30

Mikhail, the code in BOPCol_ContextCnt::Perform() should be Ok -- I have checked that with Eugene some time ago (on first version of the fix).
(0035314)
msv (developer)
2014-12-11 12:03

I have found the following problem with suggested wrapping mechanism.
Let's turn again to the file BOPCol_Parallel.hxx, which replaces the file BOPCol_TBB.hxx.
The body of the old class BOPCol_TBBContextFunctor had the following declaration:

  void operator()( const flexible_range<Standard_Integer>& aBR ) const;

The body of its replacement BOPCol_ContextFunctor is the following:

  void operator()( const Standard_Integer theIndex ) const;

So, the body of the old functor could work out a range of items in one thread run. And the new functor can work out only one item in one run.

The class IntTools_Context that plays the role of TypeContext parameter of the template is not thread-safe because it provides its services using non thread-safe data map containers. This thread-dangerous nature of the context is the cause why it is not passed to the functor in parallel mode.

So, in each run of functor body the new instance of context is created. And if in the old version it was done once for a range of items in new version it is done for each item. So, we can anticipate a significant downgrade of performance depending on shapes complexity.

The better way is to provide thread-safety of IntTools_Context and to pass the same instance of it in all thread runs.

To my mind, we are too hurry when implement wrapping mechanism without providing thread-safe containers. The better way would be to provide wrapping to implementation of thread-safe containers (TBB has a good set of them), so that to be ready to solve the problems like we have with IntTools_Context.

All in all, we must not permit downgrade of performance of OCCT code. So, I suggest that the certification of the patch for this bug will include special set of tests that involve parallel computation of BOP on complex shapes (at least the set that was used during implementation of parallelization of BOP).
(0035339)
msv (developer)
2014-12-11 16:40

The set of tests for performance measurements please get from the post of PKV in the following page: http://dev.opencascade.org/index.php?q=node/718#comment-362 [^]
(0035458)
oan (developer)
2014-12-17 13:13
edited on: 2014-12-17 13:15

Dear Mikhail,

your remark concerning IntTools_Context and possible slowdown is quite correct. However, introducing of thread-safe containers will not solve all possible problems with data races. What I mean:
I figured out that IntTools_ShrunkRange contains calls to IntTools_Context::ComputeVE that uses cached GeomAPI_ProjectPointOnCurve; IntTools_EdgeFace contains calls to IntTools_Context::IsValidPointForFace which uses cached GeomAPI_ProjectPointOnCurve; both of these classes are used in parallel that means possiblity that context of GeomAPI_ProjectPointOnCurve or GeomAPI_ProjectPointOnCurve can be corrupted during their using in parallel threads. In this case even if we wrapped data maps used in IntTools_Context, described problem will remain the hot point. This situation does not appear in old version as far as the same context is used for range of items processed in a single thread. As a solution, some protection can be impemented for particular tool, however this means creation of N * M mutexes, where N is number of shapes, M is number of tools related to this shape. So, it seems not a good idea.

Additionally, using of TBB as well as another framework providing such services is optional for OCCT and force using of TBB containers introduces unnecessary strict dependency. Hence, somehow or other we should take care to protect native OCCT containers, however such protection should be impemented on the level where the problem can occur.

As a result, IMHO, in this case it seems as an unavoidable victim if we want to introduce unified parallelization tool within OCCT.

Additional question to discuss: what the reason to maintain two pairs of similar methods ParallelForEach - ForEach and ParallelFor - For in class which name (OSD_Parallel) explicitely hints to parallel services implemented there, is not it a buttery butter? I suggest to remove existing ForEach and For methods, move their functionality to corresponding parallel ones, add new parameter isForceSingleThreadExecution with default value equal FALSE and remove prefix "Parallel". So, we will obtain quite logical OSD_Parallel::ForEach() instead of OSD_Parallel::ParallelForEach(), for instance.

(0035541)
msv (developer)
2014-12-22 10:28

We shouldn't allow performance downgrade of the code. The context was initially introduced to speed up the calculations by creating one instance of a tool and then using it many times. With the proposed patch, this approach will be broken. It is not a good way to bring a well working approach as a victim to another improvement, even more so there is a way to avoid degradation.
So, I suggest that we first make the context thread-safe before going further in direction of parallelization of BOP related code.

Though TBB is optional product when working with OCCT, it is for the moment the only way to make algorithms running in parallel.

In order to separate unsafe things, it is possible to have one unique thing for each thread. For example, we could create a wrapper over the context, such that creates and uses a unique context for each thread.

Concerning API of OSD_Parallel class, I agree with proposition to leave only For and ForEach.
(0035542)
msv (developer)
2014-12-22 10:41

Please continue the work on this issue taking above remarks into account.
(0035594)
git (administrator)
2014-12-23 14:22

Branch CR24826 has been updated forcibly by azn.

SHA-1: ae1305a47f1c7236695e5f1e8d49c2c7084d74ae
(0035612)
git (administrator)
2014-12-23 16:31

Branch CR24826 has been updated by azn.

SHA-1: d03f01013d24c17665ae7042f05cf80fa5c1fbd4


Detailed log of new commits:

Author: azn
Date: Tue Dec 23 16:31:43 2014 +0300

    0024826: Wrapping of parallelisation algorithms
    
    Fixes in Context Functor.

(0035643)
git (administrator)
2014-12-24 07:53

Branch CR24826 has been updated forcibly by azn.

SHA-1: 3b31bdef60b74427df6df9126825974e412223f9
(0035644)
azn (developer)
2014-12-24 08:43
edited on: 2014-12-24 08:55

I have prepared a small fix in which the context is initialized one time for each thread. It is allow to avoid performance downgrade (sometimes performance will better). In such a way this approach allows to integrate OSD_Parallel in OCCT.

But I agree that it more correct to have a thread-safety on the level of the context as it allows to increase performance and reduce memory requirements in further. But this issue may be implemented in the context of other bug-track record.

(0035645)
azn (developer)
2014-12-24 08:49

Dear Mikhail,
Please review current changes.
- BOPCol_Parallel.hxx (BOP context issue)
- OSD_Parallel.hxx (API changes of ParallelFor and ParallelForEach)
(0035705)
msv (developer)
2014-12-25 10:58

Remarks were given verbally.
(0035706)
msv (developer)
2014-12-25 11:01

In general, the proposed fix looks more better than the previous, as it does not lead to creation of context tool in each call to functor body.
So, I agree to test and integrate it. And then create additional bug track item to make context thread safe.
(0035721)
git (administrator)
2014-12-25 15:09

Branch CR24826 has been updated by azn.

SHA-1: 80aaf95ede3c516873d31d86e0aed75d12939084


Detailed log of new commits:

Author: azn
Date: Thu Dec 25 15:08:46 2014 +0300

    0024826: Wrapping of parallelisation algorithms
    
    Small fixes.

(0035751)
git (administrator)
2014-12-26 13:10

Branch CR24826 has been updated by azn.

SHA-1: 7fda8a503ea15dd7f0480594086252767f415fa6


Detailed log of new commits:

Author: azn
Date: Fri Dec 26 13:09:45 2014 +0300

    0024826: Wrapping of parallelisation algorithms
    
    Small fixes.

(0035769)
msv (developer)
2014-12-26 16:46

No more remarks. Please test.
(0035770)
msv (developer)
2014-12-26 16:51

Also, please test separately and compare performance of tests according to my request http://tracker.dev.opencascade.org/view.php?id=24826#c35339. [^] It is needed that each test case was run alone on a dedicated machine.
(0035779)
git (administrator)
2014-12-26 17:57

Branch CR24826_1 has been created by msv.

SHA-1: 1c5fc127104b083b4398bb08c7b4fa9c8b8f0e9b


Detailed log of new commits:

Author: msv
Date: Fri Dec 26 17:05:31 2014 +0300

    0024826: Wrapping of parallelisation algorithms
    
    Simple primitives to parallelize loops type "for" and "foreach" were implemented. The primitives encapsulates complete logic for creating and managing parallel context of loops. Moreover the primitives may be a wrapper for some primitives from 3rd-party library - TBB.
    
    To use it is necessary to implement TBB like interface which is based on functors. For example:
    
    Class Functor
    {
    public:
      void operator() ([proccesing instance]) const
      {
        //...
      }
    };
    
    In the body of the operator () should be implemented thread-safe logic of computations that can be performed in parallel context. If parallelized loop iterates on the collections with direct access by index (such as Vector, Array), it is more efficient to use the primitive ParallelFor (because it has no critical section).
    
    All parts of OCC code which are using tbb were changed on new primitives.
(0035780)
msv (developer)
2014-12-26 17:58

I have rebased CR24826_1 on master.
(0035956)
apv (tester)
2015-01-12 14:26

Dear BugMaster,

Branch CR24826_1 from occt git-repository (and master from products git-repository) was compiled on Linux, MacOS and Windows platforms and tested.
SHA-1: 1c5fc127104b083b4398bb08c7b4fa9c8b8f0e9b

Number of compiler warnings:
occt component:
   Linux: 18 (18 on master)
   Windows: 0 (0 on master)
products component :
   Linux: 11 (11 on master)
   Windows: 1 (1 on master)
There is a problem with building of CR24826_1 on MacOS:
/Users/mnt/tools/WOK680/wok_entities/LOC/dev/CR24826-1-master-occt/inc/BOPCol_Parallel.hxx:90:21: error: static_cast from 'Standard_ThreadId' (aka '_opaque_pthread_t *') to 'size_t' (aka 'unsigned long') is not allowed

Regressions/Differences:
Not detected

Testing cases:
Not needed

Testing on Linux:
Total MEMORY difference: 369003916 / 369143040
Total CPU difference: 49313.14000000019 / 46134.27000000006

Testing on Windows:
Total MEMORY difference: 276191868 / 276918412
Total CPU difference: 35455.875 / 38326.15625
(0035968)
msv (developer)
2015-01-12 16:31

Dear azn, please correct the error.
(0036336)
git (administrator)
2015-01-21 16:11

Branch CR24826_1 has been updated forcibly by azn.

SHA-1: ae517975e04b90fe84fad5c60266340a227b49a9
(0036683)
git (administrator)
2015-01-27 08:08

Branch CR24826_1 has been updated forcibly by azn.

SHA-1: 63af1e28b6a46249c533b6f46f6ffb0d35adea91
(0036684)
azn (developer)
2015-01-27 08:08

Dear Mikhail,
Compilation errors have been corrected. Branch has been rebased on new master. Please update status of this ticket and send on the test.
(0036690)
msv (developer)
2015-01-27 11:11

Alexander, I think the line OSD_Parallel.hxx:144 contains error ("->" vs ".").
(0036793)
git (administrator)
2015-01-29 09:38

Branch CR24826_1 has been updated by azn.

SHA-1: e30c8b8a17c0a1e3dad85a925dae2e5ac6d93a45


Detailed log of new commits:

Author: azn
Date: Thu Jan 29 09:36:34 2015 +0300

    0024826: Wrapping of parallelisation algorithms
    
    Small fix.

(0036796)
msv (developer)
2015-01-29 10:53

Reviewed.
Please, test. I would like to remind:

Also, please test separately and compare performance of tests according to my request 0024826:0035339. It is needed that each test case was run alone on a dedicated machine.
(0036929)
git (administrator)
2015-01-30 17:47

Branch CR24826_1 has been updated forcibly by apv.

SHA-1: b22a2191a632f970b55c1c5a4cf6187a6a36bc63
(0036930)
apv (tester)
2015-01-30 17:51

Branch CR24826_1 has been rebased on the current master
(0037035)
apv (tester)
2015-02-03 18:19

Dear msv, please have a look at file CR24826-perf_01.xls
(0037039)
msv (developer)
2015-02-03 19:20

The content of the file shows that the parallel run performs longer than serial. Something strange. What kind of time you used? Is it CPU time or wall clock time? We need to consider only wall clock time.
(0037090)
apv (tester)
2015-02-04 18:09

Dear msv, please have a look at file CR24826-perf_02.xls. It consists tests execution time comparison between CR24826 and master. Execution time was checked according to pkv's recommendation.
(0037091)
msv (developer)
2015-02-04 18:13

Dear apv, thank you for analysis. Now it is obvious for me that the fix does not contain performance regressions.
So, it can be considered as tested.
(0037101)
apv (tester)
2015-02-05 11:16

Dear BugMaster,

Branch CR24826_1 from occt git-repository (and master from products git-repository) was compiled on Linux, MacOS and Windows platforms and tested.
SHA-1: b22a2191a632f970b55c1c5a4cf6187a6a36bc63

Number of compiler warnings:
occt component:
   Linux: 18 (18 on master)
   Windows: 0 (0 on master)
products component :
   Linux: 11 (11 on master)
   Windows: 1 (1 on master)

Regressions/Differences:
Not detected

Testing cases:
Not needed

Testing on Linux:
Total MEMORY difference: 369861088 / 370076844
Total CPU difference: 53683.34999999986 / 49863.81000000002

Testing on Windows:
Total MEMORY difference: 275489696 / 276284192
Total CPU difference: 38727.5625 / 36894.109375
(0038489)
git (administrator)
2015-03-18 13:32

Branch CR24826 has been deleted by inv.

SHA-1: 7fda8a503ea15dd7f0480594086252767f415fa6
(0038490)
git (administrator)
2015-03-18 13:32

Branch CR24826_1 has been deleted by inv.

SHA-1: b22a2191a632f970b55c1c5a4cf6187a6a36bc63

- Related Changesets
occt: master c7b59798
Timestamp: 2015-02-05 12:49:35
Author: msv
Committer: bugmaster
Details ] Diff ]
0024826: Wrapping of parallelisation algorithms

Simple primitives to parallelize loops type "for" and "foreach" were implemented. The primitives encapsulates complete logic for creating and managing parallel context of loops. Moreover the primitives may be a wrapper for some primitives from 3rd-party library - TBB.

To use it is necessary to implement TBB like interface which is based on functors. For example:

Class Functor
{
public:
  void operator() ([proccesing instance]) const
  {
    //...
  }
};

In the body of the operator () should be implemented thread-safe logic of computations that can be performed in parallel context. If parallelized loop iterates on the collections with direct access by index (such as Vector, Array), it is more efficient to use the primitive ParallelFor (because it has no critical section).

All parts of OCC code which are using tbb were changed on new primitives.

0024826: Wrapping of parallelisation algorithms

Small fix.
mod - src/BOPAlgo/BOPAlgo_BuilderSolid.cxx Diff ] File ]
mod - src/BOPAlgo/BOPAlgo_Builder_2.cxx Diff ] File ]
mod - src/BOPAlgo/BOPAlgo_Builder_3.cxx Diff ] File ]
mod - src/BOPAlgo/BOPAlgo_PaveFiller_2.cxx Diff ] File ]
mod - src/BOPAlgo/BOPAlgo_PaveFiller_3.cxx Diff ] File ]
mod - src/BOPAlgo/BOPAlgo_PaveFiller_4.cxx Diff ] File ]
mod - src/BOPAlgo/BOPAlgo_PaveFiller_5.cxx Diff ] File ]
mod - src/BOPAlgo/BOPAlgo_PaveFiller_6.cxx Diff ] File ]
mod - src/BOPAlgo/BOPAlgo_PaveFiller_7.cxx Diff ] File ]
mod - src/BOPAlgo/BOPAlgo_PaveFiller_9.cxx Diff ] File ]
mod - src/BOPAlgo/BOPAlgo_ShellSplitter.cxx Diff ] File ]
mod - src/BOPAlgo/BOPAlgo_WireSplitter.cxx Diff ] File ]
add - src/BOPCol/BOPCol_Parallel.hxx Diff ] File ]
rm - src/BOPCol/BOPCol_TBB.hxx Diff ] File ]
mod - src/BOPCol/FILES Diff ] File ]
mod - src/BOPDS/BOPDS_Iterator.cxx Diff ] File ]
mod - src/BOPTest/BOPTest_CheckCommands.cxx Diff ] File ]
rm - src/BOPTest/BOPTest_Chronometer.hxx Diff ] File ]
mod - src/BOPTest/BOPTest_PartitionCommands.cxx Diff ] File ]
mod - src/BOPTest/FILES Diff ] File ]
mod - src/BOPTools/BOPTools_AlgoTools_1.cxx Diff ] File ]
mod - src/BRepMesh/BRepMesh_FastDiscret.cxx Diff ] File ]
mod - src/BRepMesh/BRepMesh_IncrementalMesh.cxx Diff ] File ]
mod - src/BRepMesh/BRepMesh_WireChecker.cxx Diff ] File ]
mod - src/BRepMesh/BRepMesh_WireInterferenceChecker.cxx Diff ] File ]
mod - src/BRepMesh/BRepMesh_WireInterferenceChecker.hxx Diff ] File ]
mod - src/MeshTest/MeshTest_PluginCommands.cxx Diff ] File ]
mod - src/OpenGl/OpenGl_SceneGeometry.cxx Diff ] File ]
mod - src/OSD/EXTERNLIB Diff ] File ]
mod - src/OSD/FILES Diff ] File ]
add - src/OSD/OSD_Parallel.cxx Diff ] File ]
add - src/OSD/OSD_Parallel.hxx Diff ] File ]
mod - src/QABugs/QABugs_19.cxx Diff ] File ]
mod - src/QANCollection/QANCollection_Stl.cxx Diff ] File ]

- Issue History
Date Modified Username Field Change
2014-04-14 10:16 Istvan Csanady New Issue
2014-04-14 10:16 Istvan Csanady Assigned To => abv
2014-04-14 11:48 szv Description Updated View Revisions
2014-04-15 14:15 kgv Note Added: 0028844
2014-04-15 14:20 kgv Relationship added related to 0021961
2014-04-15 14:21 kgv Relationship added related to 0024639
2014-04-25 13:47 Istvan Csanady Note Added: 0029073
2014-08-05 12:21 abv Relationship added related to 0025115
2014-08-05 12:22 abv Assigned To abv => azn
2014-08-05 12:22 abv Status new => assigned
2014-08-05 12:22 abv Target Version => 6.8.0
2014-08-05 12:28 abv Relationship added related to 0022146
2014-08-19 10:46 git Note Added: 0030869
2014-09-11 10:24 abv Target Version 6.8.0 => 7.1.0
2014-09-19 11:02 git Note Added: 0031884
2014-09-25 12:03 git Note Added: 0032124
2014-09-29 11:22 dbp Note Added: 0032287
2014-09-29 11:23 dbp Note Edited: 0032287 View Revisions
2014-09-29 23:03 kgv Note Added: 0032340
2014-09-29 23:04 kgv Note Edited: 0032340 View Revisions
2014-10-01 13:14 git Note Added: 0032503
2014-10-03 12:58 git Note Added: 0032620
2014-10-03 13:08 git Note Added: 0032622
2014-10-08 15:40 azn Assigned To azn => abv
2014-10-08 15:40 azn Status assigned => resolved
2014-10-15 15:59 abv Note Added: 0033146
2014-12-03 17:08 git Note Added: 0034975
2014-12-03 20:38 kgv Note Added: 0034985
2014-12-03 20:38 kgv Assigned To abv => azn
2014-12-03 20:38 kgv Status resolved => assigned
2014-12-05 18:39 git Note Added: 0035084
2014-12-08 13:34 msv Relationship added related to 0025545
2014-12-08 13:37 msv Note Added: 0035128
2014-12-09 03:06 msv Note Added: 0035177
2014-12-10 14:30 abv Note Added: 0035262
2014-12-11 12:03 msv Note Added: 0035314
2014-12-11 16:40 msv Note Added: 0035339
2014-12-17 13:13 oan Note Added: 0035458
2014-12-17 13:13 oan Assigned To azn => msv
2014-12-17 13:13 oan Status assigned => feedback
2014-12-17 13:15 oan Note Edited: 0035458 View Revisions
2014-12-22 10:28 msv Note Added: 0035541
2014-12-22 10:41 msv Note Added: 0035542
2014-12-22 10:41 msv Assigned To msv => azn
2014-12-22 10:41 msv Status feedback => assigned
2014-12-23 14:22 git Note Added: 0035594
2014-12-23 16:31 git Note Added: 0035612
2014-12-24 07:53 git Note Added: 0035643
2014-12-24 08:43 azn Note Added: 0035644
2014-12-24 08:49 azn Note Added: 0035645
2014-12-24 08:50 azn Assigned To azn => msv
2014-12-24 08:55 azn Note Edited: 0035644 View Revisions
2014-12-25 10:57 msv Assigned To msv => azn
2014-12-25 10:58 msv Note Added: 0035705
2014-12-25 11:01 msv Note Added: 0035706
2014-12-25 15:09 git Note Added: 0035721
2014-12-26 07:24 azn Assigned To azn => msv
2014-12-26 13:10 git Note Added: 0035751
2014-12-26 16:44 msv Status assigned => resolved
2014-12-26 16:44 msv Steps to Reproduce Updated View Revisions
2014-12-26 16:46 msv Note Added: 0035769
2014-12-26 16:46 msv Assigned To msv => bugmaster
2014-12-26 16:46 msv Status resolved => reviewed
2014-12-26 16:51 msv Note Added: 0035770
2014-12-26 17:04 mkv Assigned To bugmaster => apv
2014-12-26 17:57 git Note Added: 0035779
2014-12-26 17:58 msv Note Added: 0035780
2015-01-12 14:26 apv Note Added: 0035956
2015-01-12 14:26 apv Assigned To apv => msv
2015-01-12 14:26 apv Status reviewed => assigned
2015-01-12 14:26 apv Test case number => Not needed
2015-01-12 16:31 msv Assigned To msv => azn
2015-01-12 16:31 msv Note Added: 0035968
2015-01-21 16:11 git Note Added: 0036336
2015-01-27 08:08 git Note Added: 0036683
2015-01-27 08:08 azn Note Added: 0036684
2015-01-27 08:08 azn Assigned To azn => msv
2015-01-27 08:08 azn Status assigned => resolved
2015-01-27 11:11 msv Note Added: 0036690
2015-01-27 11:11 msv Assigned To msv => azn
2015-01-27 11:11 msv Status resolved => assigned
2015-01-29 09:38 git Note Added: 0036793
2015-01-29 09:39 azn Assigned To azn => msv
2015-01-29 09:39 azn Status assigned => resolved
2015-01-29 10:53 msv Note Added: 0036796
2015-01-29 10:53 msv Assigned To msv => bugmaster
2015-01-29 10:53 msv Status resolved => reviewed
2015-01-30 14:45 mkv Assigned To bugmaster => apv
2015-01-30 17:47 git Note Added: 0036929
2015-01-30 17:51 apv Note Added: 0036930
2015-02-03 18:18 apv File Added: CR24826-perf_01.xls
2015-02-03 18:19 apv Note Added: 0037035
2015-02-03 18:19 apv Assigned To apv => msv
2015-02-03 18:19 apv Status reviewed => feedback
2015-02-03 19:20 msv Assigned To msv => apv
2015-02-03 19:20 msv Note Added: 0037039
2015-02-04 18:02 apv File Added: CR24826-perf_02.xls
2015-02-04 18:09 apv Note Added: 0037090
2015-02-04 18:09 apv Assigned To apv => msv
2015-02-04 18:13 msv Note Added: 0037091
2015-02-04 18:14 msv Assigned To msv => apv
2015-02-04 18:14 msv Status feedback => acknowledged
2015-02-04 18:14 msv Status acknowledged => reviewed
2015-02-05 11:16 apv Note Added: 0037101
2015-02-05 11:16 apv Assigned To apv => bugmaster
2015-02-05 11:16 apv Status reviewed => tested
2015-02-06 15:38 bugmaster Changeset attached => occt master c7b59798
2015-02-06 15:38 bugmaster Status tested => verified
2015-02-06 15:38 bugmaster Resolution open => fixed
2015-02-06 18:10 emv Relationship added parent of 0025801
2015-02-09 11:04 bugmaster Target Version 7.1.0 => 6.9.0
2015-03-18 13:32 git Note Added: 0038489
2015-03-18 13:32 git Note Added: 0038490
2015-05-14 15:29 user533 Status verified => closed
2015-05-14 15:32 user533 Fixed in Version => 6.9.0
2016-09-08 21:34 kgv Relationship added related to 0027854


Copyright © 2000 - 2018 MantisBT Team
Powered by Mantis Bugtracker