MantisBT - Open CASCADE
View Issue Details
0030511Open CASCADE[OCCT] OCCT:Meshpublic2019-02-21 17:362019-07-09 14:53
abv 
apn 
normalminor 
closedfixed 
 
[OCCT] 7.4.0[OCCT] 7.4.0 
bugs mesh bug30511
0030511: Mesh - too long meshing of assembly containing single solid (shared)
Attached BREP file contains assembly where single solid (box) is replicated ~ 93000 times. Meshing of this shape takes ~ 30 sec, which looks too much since the actual geometry is just a box.
pload MODELING
restore [locate_data_file hugeassembly0.brep] a
nbshapes a
dchrono s restart
incmesh a 0.1
dchrono s stop show
No tags attached.
related to 0030497closed apn [REGRESSION] Mesh - wrong Poly_Polygon3D within local selection of located shape 
? hugeassembly0.brep (45,852) 2019-02-21 17:41
https://tracker.dev.opencascade.org/
png hige-brep.png (378,672) 2019-02-22 09:49
https://tracker.dev.opencascade.org/
png huge-step.png (378,327) 2019-02-22 09:49
https://tracker.dev.opencascade.org/
png cad_assistant_1.0-2018-02-14.png (230,808) 2019-02-22 12:54
https://tracker.dev.opencascade.org/
png cad_assistant_1.1-2018-09-11.png (396,579) 2019-02-22 12:54
https://tracker.dev.opencascade.org/
png cad_assistant_1.3-2019-02-11.png (335,557) 2019-02-22 12:54
https://tracker.dev.opencascade.org/
Issue History
2019-02-21 17:36abvNew Issue
2019-02-21 17:36abvAssigned To => oan
2019-02-21 17:41abvFile Added: hugeassembly0.brep
2019-02-21 18:45oanNote Added: 0082284
2019-02-21 18:45oanAssigned Tooan => abv
2019-02-21 18:45oanStatusnew => feedback
2019-02-22 09:49kgvFile Added: hige-brep.png
2019-02-22 09:49kgvFile Added: huge-step.png
2019-02-22 12:54oanNote Added: 0082298
2019-02-22 12:54oanFile Added: cad_assistant_1.0-2018-02-14.png
2019-02-22 12:54oanFile Added: cad_assistant_1.1-2018-09-11.png
2019-02-22 12:54oanFile Added: cad_assistant_1.3-2019-02-11.png
2019-02-23 21:49abvAssigned Toabv => oan
2019-02-23 21:51abvNote Added: 0082320
2019-02-25 13:48oanRelationship addedrelated to 0030497
2019-02-25 14:06oanNote Added: 0082336
2019-02-25 14:06oanAssigned Tooan => abv
2019-02-25 14:07oanNote Edited: 0082336bug_revision_view_page.php?bugnote_id=82336#r20713
2019-03-04 09:46gitNote Added: 0082573
2019-03-04 09:48oanNote Added: 0082574
2019-03-04 09:48oanStatusfeedback => resolved
2019-03-07 12:18kgvNote Added: 0082757
2019-03-07 12:28oanNote Added: 0082758
2019-03-07 12:37kgvNote Added: 0082759
2019-03-07 12:55oanNote Added: 0082760
2019-03-07 13:22oanAssigned Toabv => msv
2019-03-12 14:48kgvNote Added: 0082874
2019-03-12 14:49kgvNote Edited: 0082874bug_revision_view_page.php?bugnote_id=82874#r20823
2019-03-12 15:20msvNote Added: 0082875
2019-03-12 15:20msvAssigned Tomsv => bugmaster
2019-03-12 15:20msvStatusresolved => reviewed
2019-03-12 16:25apnTest case number => bugs mesh bug30511
2019-03-12 16:25apnStatusreviewed => tested
2019-03-13 16:44gitNote Added: 0082921
2019-03-15 18:19abvSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=20862#r20862
2019-03-15 19:16gitNote Added: 0083008
2019-03-17 15:40apnChangeset attached => occt master ad4b0429
2019-03-17 15:40apnAssigned Tobugmaster => apn
2019-03-17 15:40apnStatustested => verified
2019-03-17 15:40apnResolutionopen => fixed
2019-03-19 10:32gitNote Added: 0083074
2019-07-09 14:53abvNote Added: 0085508

Notes
(0082284)
oan   
2019-02-21 18:45   
Andrey,

Generally, comparing to OCCT 7.3.0 there is a significant performance improvement on this case on my machine:

OCCT 7.3.0:
41.21642 Seconds
This shape contains 1119744 triangles

current master:
25.2386381 Seconds
This shape contains 1119744 triangles

However, could you please express your considerations why it should be faster in more detail rather than pure statement that it is just boxes, it seems subjective as far as there are 93312 distinct shapes whatever kind they are and it is a challenging task to process such a huge number of shapes anyway.

Mesher explodes entire model on edges and processes them, then explodes entire model on faces and processes them. So, the greater number of unique edges and unique faces the more time needed to process entire model, it is logical.

Moreover, I know use case when it works much more slower even on a single shape:
psphere s 1000
incmesh s 0.001

Production of 1119744 triangles even on a single shape is always a resource intensive task.

What performance do you expect finally, please specify?
Elsewhere we ought to go to no-ending optimization, probably without possibility to achieve better goals.

For attached model the best solution to achive universe performance is to use shapes with shared TShape and different locations.

In this case performance should be equal to time needed to process only one box.
(0082298)
oan   
2019-02-22 12:54   
Kirill,

thanks for screenshots, I have checked behaviour on various versions of CAD Assistant using attached BRep file and seems it is actual even on earlier versions of OCCT.

However, it is 20 seconds faster since CAD Assistant version 1.1 (see additional screenshots). Maybe due to revision of BRepMesh.

Newertheless, here we should specify what performance is expected.
I suppose we can go in different way rather than performance improvement of BRepMesh, probably, we can simplify it in order to replace similar parts by instances with different locations.
(0082320)
abv   
2019-02-23 21:51   
Oleg, this shape contains 1 (one) box solid, shared many times within the assembly structure. Since it is still the same single box, it should be triangulated very fast unless it is either triangulated 93 K times or there are some enormous overhead expenses.
(0082336)
oan   
2019-02-25 14:06   
(edited on: 2019-02-25 14:07)
Andrey,

OK, according to 0030497, seems that BRepMesh spends the most of processing time on extraction and tessellation of edges of the model.

The matter is that all edges are added to the model despite of the fact that they share the same TEdge, because of different locations.

However, only faces with unique TFace are used for further processing.
Due to this fact model contains entire set of edges, but only unique faces, so some edges can be left unused within discrete model. Nevertheless, by design all edges are tessellated despite of relation to any face.

Patch 0030497 improves performance of this case up to ~ 3.5 secs.

I suppose it can be closed after integration of that fix.

(0082573)
git   
2019-03-04 09:46   
Branch CR30511 has been created by oan.

SHA-1: 69e89a52f1177dee86ec57ddf1ce12d0ff55318c


Detailed log of new commits:

Author: oan
Date: Mon Mar 4 09:41:34 2019 +0300

    0030511: Mesh - too long meshing of assembly containing single solid (shared)
    
    Added test case.
(0082574)
oan   
2019-03-04 09:48   
Andrey,

to my mind, issue has been completely fixed by 0030497.

Branch CR30511 contains test case only.

Please review.
(0082757)
kgv   
2019-03-07 12:18   
Another funny script:
pload MODELING VISUALIZATION
set nx 50; set ny 50; set nz 50;
set bb {}
for {set x 1} {$x <= $nx} {incr x} { for {set y 1} {$y <= $ny} {incr y} { for {set z 1} {$z <= 
$nz} {incr z} { box b${x}_${y}_${z} $x $y $z 0.5 0.5 0.5; lappend bb b${x}_${y}_${z} } } }

meminfo
dchrono t stop;dchrono t reset;dchrono t start
# meshing Compound instead of independent boxes (they are all independent)
# is a heck of slow...
#compound {*}$bb cc; incmesh cc 0.001 -parallel
for {set x 1} {$x <= $nx} {incr x} { for {set y 1} {$y <= $ny} {incr y} { for {set z 1} {$z <= 
$nz} {incr z} { box b${x}_${y}_${z} $x $y $z 0.5 0.5 0.5; incmesh b${x}_${y}_${z} 0.001 } } }
dchrono t stop;dchrono t show
meminfo
(0082758)
oan   
2019-03-07 12:28   
Hi Kirill,

the last script represents different case comparing to reported problem.
Initial one is fixed by 0030497.

So please report new issue and we will consider it in further.
(0082759)
kgv   
2019-03-07 12:37   
> the last script represents different case comparing to reported problem.
Sure, just shared some new scripts, not sure if it is critical to analyze it.
(0082760)
oan   
2019-03-07 12:55   
Maybe it is not critical, but it would be better if we will have as much use cases as possible anyway.

You know that such approach allows to maintain the component much more stable than without it.

So, thanks for an additional use case.
(0082874)
kgv   
2019-03-12 14:48   
(edited on: 2019-03-12 14:49)
> Maybe it is not critical, but it would be better
> if we will have as much use cases as possible anyway.
> So, thanks for an additional use case.
pload MODELING VISUALIZATION
set nx 50; set ny 50; set nz 10;
set bb {}
for {set x 1} {$x <= $nx} {incr x} { for {set y 1} {$y <= $ny} {incr y} { for {set z 1} {$z <= 

$nz} {incr z} { box b${x}_${y}_${z} $x $y $z 0.5 0.5 0.5; lappend bb b${x}_${y}_${z} } } }
compound {*}$bb cc

# meshing as individual objects
tclean cc
dchrono t stop;dchrono t reset;dchrono t start
for {set x 1} {$x <= $nx} {incr x} { for {set y 1} {$y <= $ny} {incr y} { for {set z 1} {$z <= 

$nz} {incr z} { box b${x}_${y}_${z} $x $y $z 0.5 0.5 0.5; incmesh b${x}_${y}_${z} 0.001 } } }
dchrono t stop;dchrono t show

# meshing as compound, parallel OFF
tclean cc
dchrono t stop;dchrono t reset;dchrono t start
incmesh cc 0.001
dchrono t stop;dchrono t show

# meshing as compound, parallel ON
tclean cc
dchrono t stop;dchrono t reset;dchrono t start
incmesh cc 0.001 -parallel
dchrono t stop;dchrono t show


On current master:
# meshing as individual objects
Elapsed time: 0 Hours 0 Minutes 37.8191607763 Seconds
CPU user time: 18.203125 seconds
CPU system time: 19.234375 seconds

# meshing as compound, parallel OFF
Elapsed time: 0 Hours 0 Minutes 34.7572358875 Seconds
CPU user time: 16.015625 seconds
CPU system time: 18.375 seconds

# meshing as compound, parallel ON
Elapsed time: 0 Hours 0 Minutes 23.2027255736 Seconds
CPU user time: 49.609375 seconds
CPU system time: 56.125 seconds

So OK, there is no more such issue.

(0082875)
msv   
2019-03-12 15:20   
Reviewed.
(0082921)
git   
2019-03-13 16:44   
Branch CR30511 has been updated by apn.

SHA-1: 83228e33339528695d274ed48fa0e55383761271


Detailed log of new commits:

Author: apn
Date: Wed Mar 13 16:38:55 2019 +0300

    //Correct test case

(0083008)
git   
2019-03-15 19:16   
Branch CR30511 has been updated forcibly by apn.

SHA-1: bbd9ac8498eb56047793be84bd4c26c1ed12f124
(0083074)
git   
2019-03-19 10:32   
Branch CR30511 has been deleted by inv.

SHA-1: bbd9ac8498eb56047793be84bd4c26c1ed12f124
(0085508)
abv   
2019-07-09 14:53   
I confirm that on current master the time of execution of the reproducer script is much less than in 7.3.0 (2.5 sec vs. 31 sec).