Re: [Pythonocc-users] BRepAlgoAPI_Cut performance issues

[Jelle Feringa]

Hi Charles,I made a rudimentary fix of your script.The memory magic ( I got 8GB and am feeling lucky ;) is most likely due to the boolean_fuse function using the .Destroy method )def boolean_fuse(shapeToCutFrom, joiningShape):    from OCC.BRepAlgoAPI import BRepAlgoAPI_Fuse    join = BRepAlgoAPI_Fuse(shapeToCutFrom, joiningShape)    join.RefineEdges()    join.FuseEdges()    shape = join.Shape()    join.Destroy()    return shapeI strongly encourage you to use the functions found in OCC.Utils.Construct!This makes the program dramtatically less verbose and provides a more polished API ( and cleans up after you, raises exceptions with informative messages, all that good stuff )This should be able to build your geometry, perhaps you need a 64 bit binary, but perhaps not…However, the *only* right way to do this, is to build the geometry you want to subtract as a compound, as Fotios pointed out.Recently, we fixes a minor issue that prevented this pattern:    BRep_Builder B;    TopoDS_Compound C;    B.MakeCompound(C);    for (ind = 1; ind <= nbshapes; ind++) {  B.Add(C, aShape_i);    }    aCompoundShape = C;This works in SVN, so perhaps an interesting exercise to implement the correct version?It will be infinitely faster and more stable than this approach, but hey, what ever works.Oh, and pay attention to the ipd.set_trace() trick.It will show your geometry in the GUI as it continues to build.Note that the viewer is interactive.Makes life much easier.Best,-jellefrom OCC.BRepPrimAPI import *
import OCC.gp
import OCC.GC
import OCC.BRepBuilderAPI
import OCC.Geom
import OCC.BRepPrimAPI
import OCC.BRepAlgoAPI
import OCC.Utils.DataExchange.STEP
import OCC.Utils.DataExchange.STL
import OCC.TopoDS
import OCC.BRep
import OCC.GarbageCollector
import numpy as NP
import math
import multiprocessing as processing

gc = OCC.GarbageCollector.GarbageCollector()

# pythonic 
from OCC.Utils.Construct import *
# GUI
from OCC.Display.SimpleGui import init_display
display, start_display, add_menu, add_function_to_menu = init_display()


length = 594.6
width = 136.0
thickness = 5.0
spacing = 2.1
groove_width = 0.175
groove_depth = 0.03
number_of_slices = int(math.floor(length/spacing))
box = BRepPrimAPI_MakeBox(spacing,width,thickness).Shape()
# Make the transverse groove
print('Adding transverse groove')
pnt1 = OCC.gp.gp_Pnt(spacing/2.0, 0., thickness - groove_depth)
pnt2 = OCC.gp.gp_Pnt(spacing/2.0 + groove_width/2.0, 0., thickness)
pnt3 = OCC.gp.gp_Pnt(spacing/2.0 - groove_width/2.0, 0., thickness)
e1 = make_edge(pnt1, pnt2)
e2 = make_edge(pnt2, pnt3)
e3 = make_edge(pnt3, pnt1)
face = make_face(make_wire([e1,e2,e3]))
v = OCC.gp.gp_Vec(0., width, 0.)

b = make_prism(face , v)
print('Making transverse cut')
lga = boolean_cut(box, b)
# Make the grooves with an arithmetic progression
a1 = 1.32 # Spacing between first two grooves
an = 0.85 # Spacing between next to the last and the last groove
d1 = 9.0 # Distance from the edge to the center of the first groove
d2 = 9.0 # Distance from the edge to the center of the last groove
sn = width - d1 - d2 # Distance from first groove to last groove
n = int(math.floor(2*sn/(a1+an))) # number of grooves
d = (an-a1)/(n-1) # difference in spacing between grooves
y = d1
print('number of grooves %d' % (n,))

for i, k in enumerate(range(40)):
#for i, k in enumerate(range(1,n+1)):
print('Adding longitudinal groove %d of %d' % (i+1, n))
print('y %s' % (y,))
pnt1 = OCC.gp.gp_Pnt(0.0, y, thickness - groove_depth)
pnt2 = OCC.gp.gp_Pnt(0.0, y + groove_width/2.0, thickness)
pnt3 = OCC.gp.gp_Pnt(0.0, y - groove_width/2.0, thickness)
e1 = make_edge(pnt1, pnt2)
e2 = make_edge(pnt2, pnt3)
e3 = make_edge(pnt3, pnt1)
face = make_face(make_wire([e1,e2,e3]))
v = OCC.gp.gp_Vec(spacing, 0., 0.)
b = make_prism(face , v)
ak = a1 + (k-1)*d
y = y + ak
print('Making longitudinal cut')
lga = boolean_cut(lga, b)
# Transform the slices
slices = [lga,]
v = OCC.gp.gp_Vec(spacing, 0., 0.)


display.DisplayShape(lga)

# merge this into a compound...
print 'n slices', number_of_slices

for i in range(1, 40):
#for i in range(1, number_of_slices):
print('Translating %s' % (i,))
#trans = OCC.gp.gp_Trsf()
#trans.SetTranslation(v)
brep_trns = translate_topods_from_vector(slices[i - 1], v, True)
slices.append(brep_trns)
lga = boolean_fuse(lga, brep_trns)
import ipdb; ipdb.set_trace()
display.EraseAll()
display.DisplayShape(lga)

def fuse(shapes):
a = shapes[0][1]
b = shapes[1][1]
return boolean_fuse(a,b)

#P = processing.Pool(7)
## each member of results is initially a tuple of the index and the shape
#results = [(i,a) for i, a in enumerate(slices[:24])]
#while len(results) > 1:
#if len(results) % 2 != 0:
#'''
#Replace the last two elements of the list with the fuse of the two
#'''
#a = results[-2]
#b = results[-1]
#del results[-2:]
#results.append(fuser((a,b)))
#res

Re: [Pythonocc-users] BRepAlgoAPI_Cut performance issues

[Thomas Paviot]

Hi Charles,

I've been working hard on this memory leaks issue. Here is a description on
what's going on in your program. Let's take for example the two following
lines:

seg1 = OCC.GC.GC_MakeSegment(pnt1, pnt2)
e1 =
OCC.BRepBuilderAPI.BRepBuilderAPI_MakeEdge(OCC.Geom.Handle_Geom_TrimmedCurve(seg1.Value()))

The seg1.Value() method returns a reference to the expected value. That
means that if seg1 is deleted, seg1.Value() looses the reference to the
value and the program crashes. The 'del seg1' statement does actually not
delete the object : it is moved to the customized gc and you have to use the
gc in order to free OCC memory (you don't need to manually insert 'del seg1'
in your method since the object is deleted when exiting the method). I've
been experimenting a fix for this issue.

I had a quick look at your program, and I feel it uses multithreading but
not multiprocessing (i.e. your program runs entirely in one process). If you
use true multiprocessing (each slice is performed in a process different
from the main one), you can exchange shapes between processes by serializing
TopoDS_Shapes (my_tds_shape=pickle.load(file_pointer) and
pickle.dump(file_pointer,my_td_shape)). The memory used by each subprocess
will be freed when the subprocess is killed.

Best Regards,

Thomas

2010/6/27 Charles McCreary 

> Alas, the technique of merging 1 to 2, 3 to 4,  and then (1,2) to
> (3,4), (5,6) to (7,8), ... and so on in parallel works, the memory
> requirements are huge. On a 64 GB memory machine, python-occ exhausts all
> available memory. The script is attached
>
> On Tue, Jun 22, 2010 at 11:10 AM, Charles McCreary <
> charles.r.mccre...@gmail.com> wrote:
>
>> Thanks for all of the very helpful suggestions. I've determined that
>> creating a thin slice, making the cuts on the thin slice, translate with
>> copy 283 times, then use multiprocessing with a map reduce algorithm to fuse
>> the slices together will be the fastest way to a solution (I haven't
>> verified this step, but I think it will work). I'll post results and code
>> when done.
>>
>>
>> On Tue, Jun 22, 2010 at 10:08 AM, Charles McCreary <
>> charles.r.mccre...@gmail.com> wrote:
>>
>>> I'm thinking of attacking this problem from a different direction. I
>>> could create a thin block with one transverse cut and 108 longitudinal cuts,
>>> copy this thin block 283 times and then sequentially fuse the thin blocks
>>> together. My thinking is that each fuse will be a simpler and faster
>>> operation than one longitudinal cut. What is the procedure for making a
>>> translated copy of a shape?
>>>
>>>
>>> On Tue, Jun 22, 2010 at 9:40 AM, Charles McCreary <
>>> charles.r.mccre...@gmail.com> wrote:
>>>
 Thanks to all for helping out! Timing runs indicate that in this case, a
 cut with a compound object is actually slower than individual cuts. Is 
 there
 any other way to make cuts on a box primitive other than using booleans?


 On Tue, Jun 22, 2010 at 8:40 AM, Charles McCreary <
 charles.r.mccre...@gmail.com> wrote:

> Thanks! I was following the bottle example in which the thread is added
> to the bottle and came up with a similar solution. But how should I cut 
> with
> the compound object?
>
> On Tue, Jun 22, 2010 at 8:27 AM, Fotios Sioutis wrote:
>
>> Below you can see a simplified code snippet from GEOM on how to create
>> a compound object.
>> It is in c++ but i think it will not be so difficult to translate in
>> python
>>
>> BRep_Builder B;
>> TopoDS_Compound C;
>> B.MakeCompound(C);
>> for (ind = 1; ind <= nbshapes; ind++) {
>>   B.Add(C, aShape_i);
>> }
>> aCompoundShape = C;
>>
>> Fotis
>>
>>
>> On Tue, Jun 22, 2010 at 3:54 PM, Charles McCreary <
>> charles.r.mccre...@gmail.com> wrote:
>>
>>> I've removed the display initialization until after all of the
>>> geometry calculations, not a factor in this case. The longitudinal cuts 
>>> take
>>> ~10 minutes each!
>>>
>>> Thanks for the excellent suggestions. I don't think parallelization
>>> will work in this particular case, but I think that it will help in a
>>> variant of this case, i'll be examining the referenced code.
>>>
>>> I'd like to try the cut with compound object but I cannot find any
>>> examples. Perhaps some pseudo-code indicating how to make a compound 
>>> object
>>> out of a list of solids.
>>>
>>> On Tue, Jun 22, 2010 at 3:42 AM, Jelle Feringa <
>>> jelleferi...@gmail.com> wrote:
>>>
 You can also speedup the slicing process by distributing the
 computation over many cores (with the help of the multiprocess python
 module). Have a look to the slides 17 and 18 of this slideshow:
 http://www.pythonocc.org/resources/presentations_events/product-data-exchange-2009-conference-pde2009/.
 This multipr

Re: [Pythonocc-users] BRepAlgoAPI_Cut performance issues

[Charles McCreary]

Alas, the technique of merging 1 to 2, 3 to 4,  and then (1,2) to (3,4),
(5,6) to (7,8), ... and so on in parallel works, the memory requirements are
huge. On a 64 GB memory machine, python-occ exhausts all available memory.
The script is attached

On Tue, Jun 22, 2010 at 11:10 AM, Charles McCreary <
charles.r.mccre...@gmail.com> wrote:

> Thanks for all of the very helpful suggestions. I've determined that
> creating a thin slice, making the cuts on the thin slice, translate with
> copy 283 times, then use multiprocessing with a map reduce algorithm to fuse
> the slices together will be the fastest way to a solution (I haven't
> verified this step, but I think it will work). I'll post results and code
> when done.
>
>
> On Tue, Jun 22, 2010 at 10:08 AM, Charles McCreary <
> charles.r.mccre...@gmail.com> wrote:
>
>> I'm thinking of attacking this problem from a different direction. I could
>> create a thin block with one transverse cut and 108 longitudinal cuts, copy
>> this thin block 283 times and then sequentially fuse the thin blocks
>> together. My thinking is that each fuse will be a simpler and faster
>> operation than one longitudinal cut. What is the procedure for making a
>> translated copy of a shape?
>>
>>
>> On Tue, Jun 22, 2010 at 9:40 AM, Charles McCreary <
>> charles.r.mccre...@gmail.com> wrote:
>>
>>> Thanks to all for helping out! Timing runs indicate that in this case, a
>>> cut with a compound object is actually slower than individual cuts. Is there
>>> any other way to make cuts on a box primitive other than using booleans?
>>>
>>>
>>> On Tue, Jun 22, 2010 at 8:40 AM, Charles McCreary <
>>> charles.r.mccre...@gmail.com> wrote:
>>>
 Thanks! I was following the bottle example in which the thread is added
 to the bottle and came up with a similar solution. But how should I cut 
 with
 the compound object?

 On Tue, Jun 22, 2010 at 8:27 AM, Fotios Sioutis wrote:

> Below you can see a simplified code snippet from GEOM on how to create
> a compound object.
> It is in c++ but i think it will not be so difficult to translate in
> python
>
> BRep_Builder B;
> TopoDS_Compound C;
> B.MakeCompound(C);
> for (ind = 1; ind <= nbshapes; ind++) {
>   B.Add(C, aShape_i);
> }
> aCompoundShape = C;
>
> Fotis
>
>
> On Tue, Jun 22, 2010 at 3:54 PM, Charles McCreary <
> charles.r.mccre...@gmail.com> wrote:
>
>> I've removed the display initialization until after all of the
>> geometry calculations, not a factor in this case. The longitudinal cuts 
>> take
>> ~10 minutes each!
>>
>> Thanks for the excellent suggestions. I don't think parallelization
>> will work in this particular case, but I think that it will help in a
>> variant of this case, i'll be examining the referenced code.
>>
>> I'd like to try the cut with compound object but I cannot find any
>> examples. Perhaps some pseudo-code indicating how to make a compound 
>> object
>> out of a list of solids.
>>
>> On Tue, Jun 22, 2010 at 3:42 AM, Jelle Feringa <
>> jelleferi...@gmail.com> wrote:
>>
>>> You can also speedup the slicing process by distributing the
>>> computation over many cores (with the help of the multiprocess python
>>> module). Have a look to the slides 17 and 18 of this slideshow:
>>> http://www.pythonocc.org/resources/presentations_events/product-data-exchange-2009-conference-pde2009/.
>>> This multiprocess slicing is enabled by the shared serialization of
>>> TopoDS_Shape objects.
>>>
>>> The source code is available at:
>>> http://code.google.com/p/pythonocc/source/browse/trunk/src/examples/Level2/Concurrency/parallel_slicer.py
>>>
>>>
>>> True, for computing slices the multi-core approach works.
>>> However -and I think this is the case we're dealing with- if you
>>> change the object than of course using several processes doesn't speed
>>> things up, since the processes will simple be waiting for another 
>>> process to
>>> finish. Fotios advice on constructing a compound object and than 
>>> performing
>>> the boolean operation is most likely the way to go. I also used that 
>>> trick a
>>> number of times with success.
>>>
>>> A note on display speed; by default, the display.DisplayShape method
>>> updates the viewer. If you use the display.DisplayShape( someShape,
>>> update=False ) the viewer will not redraw, which results in a 
>>> considerable
>>> speed up. Note that you can also supply a list of TopoDS_* instances as
>>> argument.
>>>
>>> -jelle
>>>
>>> ___
>>> Pythonocc-users mailing list
>>> Pythonocc-users@gna.org
>>> https://mail.gna.org/listinfo/pythonocc-users
>>>
>>>
>>
>>
>> --
>> Charles McCreary P.E.

Re: [Pythonocc-users] BRepAlgoAPI_Cut performance issues

[Charles McCreary]

Thanks! I was following the bottle example in which the thread is added to
the bottle and came up with a similar solution. But how should I cut with
the compound object?

On Tue, Jun 22, 2010 at 8:27 AM, Fotios Sioutis  wrote:

> Below you can see a simplified code snippet from GEOM on how to create a
> compound object.
> It is in c++ but i think it will not be so difficult to translate in python
>
> BRep_Builder B;
> TopoDS_Compound C;
> B.MakeCompound(C);
> for (ind = 1; ind <= nbshapes; ind++) {
>   B.Add(C, aShape_i);
> }
> aCompoundShape = C;
>
> Fotis
>
>
> On Tue, Jun 22, 2010 at 3:54 PM, Charles McCreary <
> charles.r.mccre...@gmail.com> wrote:
>
>> I've removed the display initialization until after all of the geometry
>> calculations, not a factor in this case. The longitudinal cuts take ~10
>> minutes each!
>>
>> Thanks for the excellent suggestions. I don't think parallelization will
>> work in this particular case, but I think that it will help in a variant of
>> this case, i'll be examining the referenced code.
>>
>> I'd like to try the cut with compound object but I cannot find any
>> examples. Perhaps some pseudo-code indicating how to make a compound object
>> out of a list of solids.
>>
>> On Tue, Jun 22, 2010 at 3:42 AM, Jelle Feringa wrote:
>>
>>> You can also speedup the slicing process by distributing the computation
>>> over many cores (with the help of the multiprocess python module). Have a
>>> look to the slides 17 and 18 of this slideshow:
>>> http://www.pythonocc.org/resources/presentations_events/product-data-exchange-2009-conference-pde2009/.
>>> This multiprocess slicing is enabled by the shared serialization of
>>> TopoDS_Shape objects.
>>>
>>> The source code is available at:
>>> http://code.google.com/p/pythonocc/source/browse/trunk/src/examples/Level2/Concurrency/parallel_slicer.py
>>>
>>>
>>> True, for computing slices the multi-core approach works.
>>> However -and I think this is the case we're dealing with- if you change
>>> the object than of course using several processes doesn't speed things up,
>>> since the processes will simple be waiting for another process to finish.
>>> Fotios advice on constructing a compound object and than performing the
>>> boolean operation is most likely the way to go. I also used that trick a
>>> number of times with success.
>>>
>>> A note on display speed; by default, the display.DisplayShape method
>>> updates the viewer. If you use the display.DisplayShape( someShape,
>>> update=False ) the viewer will not redraw, which results in a considerable
>>> speed up. Note that you can also supply a list of TopoDS_* instances as
>>> argument.
>>>
>>> -jelle
>>>
>>> ___
>>> Pythonocc-users mailing list
>>> Pythonocc-users@gna.org
>>> https://mail.gna.org/listinfo/pythonocc-users
>>>
>>>
>>
>>
>> --
>> Charles McCreary P.E.
>> CRM Engineering
>> 903.643.3490 - office
>> 903.224.5701 - mobile/GV
>>
>> ___
>> Pythonocc-users mailing list
>> Pythonocc-users@gna.org
>> https://mail.gna.org/listinfo/pythonocc-users
>>
>>
>


-- 
Charles McCreary P.E.
CRM Engineering
903.643.3490 - office
903.224.5701 - mobile/GV
___
Pythonocc-users mailing list
Pythonocc-users@gna.org
https://mail.gna.org/listinfo/pythonocc-users

Re: [Pythonocc-users] BRepAlgoAPI_Cut performance issues

[Jelle Feringa]

> Thanks for all of the very helpful suggestions. I've determined that creating 
> a thin slice, making the cuts on the thin slice, translate with copy 283 
> times, then use multiprocessing with a map reduce algorithm to fuse the 
> slices together will be the fastest way to a solution (I haven't verified 
> this step, but I think it will work). I'll post results and code when done.

It will be interesting to see some results. Also it is useful to see an image 
to help you further.
___
Pythonocc-users mailing list
Pythonocc-users@gna.org
https://mail.gna.org/listinfo/pythonocc-users

Re: [Pythonocc-users] BRepAlgoAPI_Cut performance issues

[Charles McCreary]

Thanks for all of the very helpful suggestions. I've determined that
creating a thin slice, making the cuts on the thin slice, translate with
copy 283 times, then use multiprocessing with a map reduce algorithm to fuse
the slices together will be the fastest way to a solution (I haven't
verified this step, but I think it will work). I'll post results and code
when done.

On Tue, Jun 22, 2010 at 10:08 AM, Charles McCreary <
charles.r.mccre...@gmail.com> wrote:

> I'm thinking of attacking this problem from a different direction. I could
> create a thin block with one transverse cut and 108 longitudinal cuts, copy
> this thin block 283 times and then sequentially fuse the thin blocks
> together. My thinking is that each fuse will be a simpler and faster
> operation than one longitudinal cut. What is the procedure for making a
> translated copy of a shape?
>
>
> On Tue, Jun 22, 2010 at 9:40 AM, Charles McCreary <
> charles.r.mccre...@gmail.com> wrote:
>
>> Thanks to all for helping out! Timing runs indicate that in this case, a
>> cut with a compound object is actually slower than individual cuts. Is there
>> any other way to make cuts on a box primitive other than using booleans?
>>
>>
>> On Tue, Jun 22, 2010 at 8:40 AM, Charles McCreary <
>> charles.r.mccre...@gmail.com> wrote:
>>
>>> Thanks! I was following the bottle example in which the thread is added
>>> to the bottle and came up with a similar solution. But how should I cut with
>>> the compound object?
>>>
>>> On Tue, Jun 22, 2010 at 8:27 AM, Fotios Sioutis wrote:
>>>
 Below you can see a simplified code snippet from GEOM on how to create a
 compound object.
 It is in c++ but i think it will not be so difficult to translate in
 python

 BRep_Builder B;
 TopoDS_Compound C;
 B.MakeCompound(C);
 for (ind = 1; ind <= nbshapes; ind++) {
   B.Add(C, aShape_i);
 }
 aCompoundShape = C;

 Fotis


 On Tue, Jun 22, 2010 at 3:54 PM, Charles McCreary <
 charles.r.mccre...@gmail.com> wrote:

> I've removed the display initialization until after all of the geometry
> calculations, not a factor in this case. The longitudinal cuts take ~10
> minutes each!
>
> Thanks for the excellent suggestions. I don't think parallelization
> will work in this particular case, but I think that it will help in a
> variant of this case, i'll be examining the referenced code.
>
> I'd like to try the cut with compound object but I cannot find any
> examples. Perhaps some pseudo-code indicating how to make a compound 
> object
> out of a list of solids.
>
> On Tue, Jun 22, 2010 at 3:42 AM, Jelle Feringa  > wrote:
>
>> You can also speedup the slicing process by distributing the
>> computation over many cores (with the help of the multiprocess python
>> module). Have a look to the slides 17 and 18 of this slideshow:
>> http://www.pythonocc.org/resources/presentations_events/product-data-exchange-2009-conference-pde2009/.
>> This multiprocess slicing is enabled by the shared serialization of
>> TopoDS_Shape objects.
>>
>> The source code is available at:
>> http://code.google.com/p/pythonocc/source/browse/trunk/src/examples/Level2/Concurrency/parallel_slicer.py
>>
>>
>> True, for computing slices the multi-core approach works.
>> However -and I think this is the case we're dealing with- if you
>> change the object than of course using several processes doesn't speed
>> things up, since the processes will simple be waiting for another 
>> process to
>> finish. Fotios advice on constructing a compound object and than 
>> performing
>> the boolean operation is most likely the way to go. I also used that 
>> trick a
>> number of times with success.
>>
>> A note on display speed; by default, the display.DisplayShape method
>> updates the viewer. If you use the display.DisplayShape( someShape,
>> update=False ) the viewer will not redraw, which results in a 
>> considerable
>> speed up. Note that you can also supply a list of TopoDS_* instances as
>> argument.
>>
>> -jelle
>>
>> ___
>> Pythonocc-users mailing list
>> Pythonocc-users@gna.org
>> https://mail.gna.org/listinfo/pythonocc-users
>>
>>
>
>
> --
> Charles McCreary P.E.
> CRM Engineering
> 903.643.3490 - office
> 903.224.5701 - mobile/GV
>
> ___
> Pythonocc-users mailing list
> Pythonocc-users@gna.org
> https://mail.gna.org/listinfo/pythonocc-users
>
>

>>>
>>>
>>> --
>>> Charles McCreary P.E.
>>> CRM Engineering
>>> 903.643.3490 - office
>>> 903.224.5701 - mobile/GV
>>>
>>
>>
>>
>> --
>> Charles McCreary P.E.
>> CRM Engineering
>> 903.643.3490 - office
>> 903.224.5701 - mobile/GV
>

Re: [Pythonocc-users] BRepAlgoAPI_Cut performance issues

[Charles McCreary]

I'm thinking of attacking this problem from a different direction. I could
create a thin block with one transverse cut and 108 longitudinal cuts, copy
this thin block 283 times and then sequentially fuse the thin blocks
together. My thinking is that each fuse will be a simpler and faster
operation than one longitudinal cut. What is the procedure for making a
translated copy of a shape?

On Tue, Jun 22, 2010 at 9:40 AM, Charles McCreary <
charles.r.mccre...@gmail.com> wrote:

> Thanks to all for helping out! Timing runs indicate that in this case, a
> cut with a compound object is actually slower than individual cuts. Is there
> any other way to make cuts on a box primitive other than using booleans?
>
>
> On Tue, Jun 22, 2010 at 8:40 AM, Charles McCreary <
> charles.r.mccre...@gmail.com> wrote:
>
>> Thanks! I was following the bottle example in which the thread is added to
>> the bottle and came up with a similar solution. But how should I cut with
>> the compound object?
>>
>> On Tue, Jun 22, 2010 at 8:27 AM, Fotios Sioutis  wrote:
>>
>>> Below you can see a simplified code snippet from GEOM on how to create a
>>> compound object.
>>> It is in c++ but i think it will not be so difficult to translate in
>>> python
>>>
>>> BRep_Builder B;
>>> TopoDS_Compound C;
>>> B.MakeCompound(C);
>>> for (ind = 1; ind <= nbshapes; ind++) {
>>>   B.Add(C, aShape_i);
>>> }
>>> aCompoundShape = C;
>>>
>>> Fotis
>>>
>>>
>>> On Tue, Jun 22, 2010 at 3:54 PM, Charles McCreary <
>>> charles.r.mccre...@gmail.com> wrote:
>>>
 I've removed the display initialization until after all of the geometry
 calculations, not a factor in this case. The longitudinal cuts take ~10
 minutes each!

 Thanks for the excellent suggestions. I don't think parallelization will
 work in this particular case, but I think that it will help in a variant of
 this case, i'll be examining the referenced code.

 I'd like to try the cut with compound object but I cannot find any
 examples. Perhaps some pseudo-code indicating how to make a compound object
 out of a list of solids.

 On Tue, Jun 22, 2010 at 3:42 AM, Jelle Feringa 
 wrote:

> You can also speedup the slicing process by distributing the
> computation over many cores (with the help of the multiprocess python
> module). Have a look to the slides 17 and 18 of this slideshow:
> http://www.pythonocc.org/resources/presentations_events/product-data-exchange-2009-conference-pde2009/.
> This multiprocess slicing is enabled by the shared serialization of
> TopoDS_Shape objects.
>
> The source code is available at:
> http://code.google.com/p/pythonocc/source/browse/trunk/src/examples/Level2/Concurrency/parallel_slicer.py
>
>
> True, for computing slices the multi-core approach works.
> However -and I think this is the case we're dealing with- if you change
> the object than of course using several processes doesn't speed things up,
> since the processes will simple be waiting for another process to finish.
> Fotios advice on constructing a compound object and than performing the
> boolean operation is most likely the way to go. I also used that trick a
> number of times with success.
>
> A note on display speed; by default, the display.DisplayShape method
> updates the viewer. If you use the display.DisplayShape( someShape,
> update=False ) the viewer will not redraw, which results in a considerable
> speed up. Note that you can also supply a list of TopoDS_* instances as
> argument.
>
> -jelle
>
> ___
> Pythonocc-users mailing list
> Pythonocc-users@gna.org
> https://mail.gna.org/listinfo/pythonocc-users
>
>


 --
 Charles McCreary P.E.
 CRM Engineering
 903.643.3490 - office
 903.224.5701 - mobile/GV

 ___
 Pythonocc-users mailing list
 Pythonocc-users@gna.org
 https://mail.gna.org/listinfo/pythonocc-users


>>>
>>
>>
>> --
>> Charles McCreary P.E.
>> CRM Engineering
>> 903.643.3490 - office
>> 903.224.5701 - mobile/GV
>>
>
>
>
> --
> Charles McCreary P.E.
> CRM Engineering
> 903.643.3490 - office
> 903.224.5701 - mobile/GV
>



-- 
Charles McCreary P.E.
CRM Engineering
903.643.3490 - office
903.224.5701 - mobile/GV
___
Pythonocc-users mailing list
Pythonocc-users@gna.org
https://mail.gna.org/listinfo/pythonocc-users

Re: [Pythonocc-users] BRepAlgoAPI_Cut performance issues

[Charles McCreary]

Thanks to all for helping out! Timing runs indicate that in this case, a cut
with a compound object is actually slower than individual cuts. Is there any
other way to make cuts on a box primitive other than using booleans?

On Tue, Jun 22, 2010 at 8:40 AM, Charles McCreary <
charles.r.mccre...@gmail.com> wrote:

> Thanks! I was following the bottle example in which the thread is added to
> the bottle and came up with a similar solution. But how should I cut with
> the compound object?
>
> On Tue, Jun 22, 2010 at 8:27 AM, Fotios Sioutis  wrote:
>
>> Below you can see a simplified code snippet from GEOM on how to create a
>> compound object.
>> It is in c++ but i think it will not be so difficult to translate in
>> python
>>
>> BRep_Builder B;
>> TopoDS_Compound C;
>> B.MakeCompound(C);
>> for (ind = 1; ind <= nbshapes; ind++) {
>>   B.Add(C, aShape_i);
>> }
>> aCompoundShape = C;
>>
>> Fotis
>>
>>
>> On Tue, Jun 22, 2010 at 3:54 PM, Charles McCreary <
>> charles.r.mccre...@gmail.com> wrote:
>>
>>> I've removed the display initialization until after all of the geometry
>>> calculations, not a factor in this case. The longitudinal cuts take ~10
>>> minutes each!
>>>
>>> Thanks for the excellent suggestions. I don't think parallelization will
>>> work in this particular case, but I think that it will help in a variant of
>>> this case, i'll be examining the referenced code.
>>>
>>> I'd like to try the cut with compound object but I cannot find any
>>> examples. Perhaps some pseudo-code indicating how to make a compound object
>>> out of a list of solids.
>>>
>>> On Tue, Jun 22, 2010 at 3:42 AM, Jelle Feringa 
>>> wrote:
>>>
 You can also speedup the slicing process by distributing the computation
 over many cores (with the help of the multiprocess python module). Have a
 look to the slides 17 and 18 of this slideshow:
 http://www.pythonocc.org/resources/presentations_events/product-data-exchange-2009-conference-pde2009/.
 This multiprocess slicing is enabled by the shared serialization of
 TopoDS_Shape objects.

 The source code is available at:
 http://code.google.com/p/pythonocc/source/browse/trunk/src/examples/Level2/Concurrency/parallel_slicer.py


 True, for computing slices the multi-core approach works.
 However -and I think this is the case we're dealing with- if you change
 the object than of course using several processes doesn't speed things up,
 since the processes will simple be waiting for another process to finish.
 Fotios advice on constructing a compound object and than performing the
 boolean operation is most likely the way to go. I also used that trick a
 number of times with success.

 A note on display speed; by default, the display.DisplayShape method
 updates the viewer. If you use the display.DisplayShape( someShape,
 update=False ) the viewer will not redraw, which results in a considerable
 speed up. Note that you can also supply a list of TopoDS_* instances as
 argument.

 -jelle

 ___
 Pythonocc-users mailing list
 Pythonocc-users@gna.org
 https://mail.gna.org/listinfo/pythonocc-users


>>>
>>>
>>> --
>>> Charles McCreary P.E.
>>> CRM Engineering
>>> 903.643.3490 - office
>>> 903.224.5701 - mobile/GV
>>>
>>> ___
>>> Pythonocc-users mailing list
>>> Pythonocc-users@gna.org
>>> https://mail.gna.org/listinfo/pythonocc-users
>>>
>>>
>>
>
>
> --
> Charles McCreary P.E.
> CRM Engineering
> 903.643.3490 - office
> 903.224.5701 - mobile/GV
>



-- 
Charles McCreary P.E.
CRM Engineering
903.643.3490 - office
903.224.5701 - mobile/GV
___
Pythonocc-users mailing list
Pythonocc-users@gna.org
https://mail.gna.org/listinfo/pythonocc-users

Re: [Pythonocc-users] BRepAlgoAPI_Cut performance issues

[Charles McCreary]

Thanks! I was following the bottle example in which the thread is added to
the bottle and came up with a similar solution. But how should I cut with
the compound object?

On Tue, Jun 22, 2010 at 8:27 AM, Fotios Sioutis  wrote:

> Below you can see a simplified code snippet from GEOM on how to create a
> compound object.
> It is in c++ but i think it will not be so difficult to translate in python
>
> BRep_Builder B;
> TopoDS_Compound C;
> B.MakeCompound(C);
> for (ind = 1; ind <= nbshapes; ind++) {
>   B.Add(C, aShape_i);
> }
> aCompoundShape = C;
>
> Fotis
>
>
> On Tue, Jun 22, 2010 at 3:54 PM, Charles McCreary <
> charles.r.mccre...@gmail.com> wrote:
>
>> I've removed the display initialization until after all of the geometry
>> calculations, not a factor in this case. The longitudinal cuts take ~10
>> minutes each!
>>
>> Thanks for the excellent suggestions. I don't think parallelization will
>> work in this particular case, but I think that it will help in a variant of
>> this case, i'll be examining the referenced code.
>>
>> I'd like to try the cut with compound object but I cannot find any
>> examples. Perhaps some pseudo-code indicating how to make a compound object
>> out of a list of solids.
>>
>> On Tue, Jun 22, 2010 at 3:42 AM, Jelle Feringa wrote:
>>
>>> You can also speedup the slicing process by distributing the computation
>>> over many cores (with the help of the multiprocess python module). Have a
>>> look to the slides 17 and 18 of this slideshow:
>>> http://www.pythonocc.org/resources/presentations_events/product-data-exchange-2009-conference-pde2009/.
>>> This multiprocess slicing is enabled by the shared serialization of
>>> TopoDS_Shape objects.
>>>
>>> The source code is available at:
>>> http://code.google.com/p/pythonocc/source/browse/trunk/src/examples/Level2/Concurrency/parallel_slicer.py
>>>
>>>
>>> True, for computing slices the multi-core approach works.
>>> However -and I think this is the case we're dealing with- if you change
>>> the object than of course using several processes doesn't speed things up,
>>> since the processes will simple be waiting for another process to finish.
>>> Fotios advice on constructing a compound object and than performing the
>>> boolean operation is most likely the way to go. I also used that trick a
>>> number of times with success.
>>>
>>> A note on display speed; by default, the display.DisplayShape method
>>> updates the viewer. If you use the display.DisplayShape( someShape,
>>> update=False ) the viewer will not redraw, which results in a considerable
>>> speed up. Note that you can also supply a list of TopoDS_* instances as
>>> argument.
>>>
>>> -jelle
>>>
>>> ___
>>> Pythonocc-users mailing list
>>> Pythonocc-users@gna.org
>>> https://mail.gna.org/listinfo/pythonocc-users
>>>
>>>
>>
>>
>> --
>> Charles McCreary P.E.
>> CRM Engineering
>> 903.643.3490 - office
>> 903.224.5701 - mobile/GV
>>
>> ___
>> Pythonocc-users mailing list
>> Pythonocc-users@gna.org
>> https://mail.gna.org/listinfo/pythonocc-users
>>
>>
>


-- 
Charles McCreary P.E.
CRM Engineering
903.643.3490 - office
903.224.5701 - mobile/GV
___
Pythonocc-users mailing list
Pythonocc-users@gna.org
https://mail.gna.org/listinfo/pythonocc-users

Re: [Pythonocc-users] BRepAlgoAPI_Cut performance issues

[Fotios Sioutis]

Below you can see a simplified code snippet from GEOM on how to create a
compound object.
It is in c++ but i think it will not be so difficult to translate in python

BRep_Builder B;
TopoDS_Compound C;
B.MakeCompound(C);
for (ind = 1; ind <= nbshapes; ind++) {
  B.Add(C, aShape_i);
}
aCompoundShape = C;

Fotis

On Tue, Jun 22, 2010 at 3:54 PM, Charles McCreary <
charles.r.mccre...@gmail.com> wrote:

> I've removed the display initialization until after all of the geometry
> calculations, not a factor in this case. The longitudinal cuts take ~10
> minutes each!
>
> Thanks for the excellent suggestions. I don't think parallelization will
> work in this particular case, but I think that it will help in a variant of
> this case, i'll be examining the referenced code.
>
> I'd like to try the cut with compound object but I cannot find any
> examples. Perhaps some pseudo-code indicating how to make a compound object
> out of a list of solids.
>
> On Tue, Jun 22, 2010 at 3:42 AM, Jelle Feringa wrote:
>
>> You can also speedup the slicing process by distributing the computation
>> over many cores (with the help of the multiprocess python module). Have a
>> look to the slides 17 and 18 of this slideshow:
>> http://www.pythonocc.org/resources/presentations_events/product-data-exchange-2009-conference-pde2009/.
>> This multiprocess slicing is enabled by the shared serialization of
>> TopoDS_Shape objects.
>>
>> The source code is available at:
>> http://code.google.com/p/pythonocc/source/browse/trunk/src/examples/Level2/Concurrency/parallel_slicer.py
>>
>>
>> True, for computing slices the multi-core approach works.
>> However -and I think this is the case we're dealing with- if you change
>> the object than of course using several processes doesn't speed things up,
>> since the processes will simple be waiting for another process to finish.
>> Fotios advice on constructing a compound object and than performing the
>> boolean operation is most likely the way to go. I also used that trick a
>> number of times with success.
>>
>> A note on display speed; by default, the display.DisplayShape method
>> updates the viewer. If you use the display.DisplayShape( someShape,
>> update=False ) the viewer will not redraw, which results in a considerable
>> speed up. Note that you can also supply a list of TopoDS_* instances as
>> argument.
>>
>> -jelle
>>
>> ___
>> Pythonocc-users mailing list
>> Pythonocc-users@gna.org
>> https://mail.gna.org/listinfo/pythonocc-users
>>
>>
>
>
> --
> Charles McCreary P.E.
> CRM Engineering
> 903.643.3490 - office
> 903.224.5701 - mobile/GV
>
> ___
> Pythonocc-users mailing list
> Pythonocc-users@gna.org
> https://mail.gna.org/listinfo/pythonocc-users
>
>
___
Pythonocc-users mailing list
Pythonocc-users@gna.org
https://mail.gna.org/listinfo/pythonocc-users

Re: [Pythonocc-users] BRepAlgoAPI_Cut performance issues

[Charles McCreary]

I've removed the display initialization until after all of the geometry
calculations, not a factor in this case. The longitudinal cuts take ~10
minutes each!

Thanks for the excellent suggestions. I don't think parallelization will
work in this particular case, but I think that it will help in a variant of
this case, i'll be examining the referenced code.

I'd like to try the cut with compound object but I cannot find any examples.
Perhaps some pseudo-code indicating how to make a compound object out of a
list of solids.

On Tue, Jun 22, 2010 at 3:42 AM, Jelle Feringa wrote:

> You can also speedup the slicing process by distributing the computation
> over many cores (with the help of the multiprocess python module). Have a
> look to the slides 17 and 18 of this slideshow:
> http://www.pythonocc.org/resources/presentations_events/product-data-exchange-2009-conference-pde2009/.
> This multiprocess slicing is enabled by the shared serialization of
> TopoDS_Shape objects.
>
> The source code is available at:
> http://code.google.com/p/pythonocc/source/browse/trunk/src/examples/Level2/Concurrency/parallel_slicer.py
>
>
> True, for computing slices the multi-core approach works.
> However -and I think this is the case we're dealing with- if you change the
> object than of course using several processes doesn't speed things up, since
> the processes will simple be waiting for another process to finish. Fotios
> advice on constructing a compound object and than performing the boolean
> operation is most likely the way to go. I also used that trick a number of
> times with success.
>
> A note on display speed; by default, the display.DisplayShape method
> updates the viewer. If you use the display.DisplayShape( someShape,
> update=False ) the viewer will not redraw, which results in a considerable
> speed up. Note that you can also supply a list of TopoDS_* instances as
> argument.
>
> -jelle
>
> ___
> Pythonocc-users mailing list
> Pythonocc-users@gna.org
> https://mail.gna.org/listinfo/pythonocc-users
>
>


-- 
Charles McCreary P.E.
CRM Engineering
903.643.3490 - office
903.224.5701 - mobile/GV
___
Pythonocc-users mailing list
Pythonocc-users@gna.org
https://mail.gna.org/listinfo/pythonocc-users

Re: [Pythonocc-users] BRepAlgoAPI_Cut performance issues

[Jelle Feringa]

> You can also speedup the slicing process by distributing the computation over 
> many cores (with the help of the multiprocess python module). Have a look to 
> the slides 17 and 18 of this slideshow: 
> http://www.pythonocc.org/resources/presentations_events/product-data-exchange-2009-conference-pde2009/.
>  This multiprocess slicing is enabled by the shared serialization of 
> TopoDS_Shape objects.
> 
> The source code is available at: 
> http://code.google.com/p/pythonocc/source/browse/trunk/src/examples/Level2/Concurrency/parallel_slicer.py

True, for computing slices the multi-core approach works.
However -and I think this is the case we're dealing with- if you change the 
object than of course using several processes doesn't speed things up, since 
the processes will simple be waiting for another process to finish. Fotios 
advice on constructing a compound object and than performing the boolean 
operation is most likely the way to go. I also used that trick a number of 
times with success. 

A note on display speed; by default, the display.DisplayShape method updates 
the viewer. If you use the display.DisplayShape( someShape, update=False ) the 
viewer will not redraw, which results in a considerable speed up. Note that you 
can also supply a list of TopoDS_* instances as argument.

-jelle___
Pythonocc-users mailing list
Pythonocc-users@gna.org
https://mail.gna.org/listinfo/pythonocc-users

Re: [Pythonocc-users] BRepAlgoAPI_Cut performance issues

[Thomas Paviot]

Hi Charles,

You can also speedup the slicing process by distributing the computation
over many cores (with the help of the multiprocess python module). Have a
look to the slides 17 and 18 of this slideshow:
http://www.pythonocc.org/resources/presentations_events/product-data-exchange-2009-conference-pde2009/.
This multiprocess slicing is enabled by the shared serialization of
TopoDS_Shape objects.

The source code is available at:
http://code.google.com/p/pythonocc/source/browse/trunk/src/examples/Level2/Concurrency/parallel_slicer.py

Best Regards,

Thomas

2010/6/22 Fotios Sioutis 

> Hi Charles
>
> Just an Idea :
>
> Try to create a compound object containing all the "groove" objects, and
> then try to call BRepAlgoAPI_Cut only once.Maybe it will help with the speed
> problem.
>
> Fotis
>
>
> On Tue, Jun 22, 2010 at 12:15 AM, Dave Cowden wrote:
>
>> Hi, Charles:
>>
>> I have implemented a slicer here, which performs much much better than
>> that:
>>
>> http://code.google.com/p/emcfab
>>
>> please feel free to steal code if it
>> helps-- i have a couple of utility wraper classes for creating slices.
>>
>> Just looking briefly at your code, i'd guess that displaying your slices
>> may be your culprit. display is very very very slow-- most of the time i
>> cannot get things to run when i display lots of objects. But when i go in
>> and display only a few things it is very fast.
>>
>> HTH
>> Dave
>>
>> On Mon, Jun 21, 2010 at 4:39 PM, Charles McCreary <
>> charles.r.mccre...@gmail.com> wrote:
>>
>>> This is cross-posted to the OpenCascade forum (
>>> http://www.opencascade.org/org/forum/thread_18806/):
>>>
>>> The attached python script demonstrates a particularly difficult problem
>>> I'm trying to solve. I've tried this in SolidWorks 2009 x64 and it
>>> *eventually* creates the geometry but crashes while attempting to save as a
>>> STEP or STL file. I'm looking for recommendations on how I can speed up the
>>> process. The transverse cuts are completed rather quickly since the only
>>> intersections are with the rectangular block. The longitudinal cuts take
>>> about 20 minutes each and there are 108! The longitudinal cuts cut through
>>> each of the 283 transverse cuts as well as the rectangular blocks.
>>>
>>>
>>> --
>>> Charles McCreary P.E.
>>> CRM Engineering
>>> 903.643.3490 - office
>>> 903.224.5701 - mobile/GV
>>>
>>> ___
>>> Pythonocc-users mailing list
>>> Pythonocc-users@gna.org
>>> https://mail.gna.org/listinfo/pythonocc-users
>>>
>>>
>>
>> ___
>> Pythonocc-users mailing list
>> Pythonocc-users@gna.org
>> https://mail.gna.org/listinfo/pythonocc-users
>>
>>
>
> ___
> Pythonocc-users mailing list
> Pythonocc-users@gna.org
> https://mail.gna.org/listinfo/pythonocc-users
>
>
___
Pythonocc-users mailing list
Pythonocc-users@gna.org
https://mail.gna.org/listinfo/pythonocc-users

Re: [Pythonocc-users] BRepAlgoAPI_Cut performance issues

[Fotios Sioutis]

Hi Charles

Just an Idea :

Try to create a compound object containing all the "groove" objects, and
then try to call BRepAlgoAPI_Cut only once.Maybe it will help with the speed
problem.

Fotis

On Tue, Jun 22, 2010 at 12:15 AM, Dave Cowden  wrote:

> Hi, Charles:
>
> I have implemented a slicer here, which performs much much better than
> that:
>
> http://code.google.com/p/emcfab
>
> please feel free to steal code if it
> helps-- i have a couple of utility wraper classes for creating slices.
>
> Just looking briefly at your code, i'd guess that displaying your slices
> may be your culprit. display is very very very slow-- most of the time i
> cannot get things to run when i display lots of objects. But when i go in
> and display only a few things it is very fast.
>
> HTH
> Dave
>
> On Mon, Jun 21, 2010 at 4:39 PM, Charles McCreary <
> charles.r.mccre...@gmail.com> wrote:
>
>> This is cross-posted to the OpenCascade forum (
>> http://www.opencascade.org/org/forum/thread_18806/):
>>
>> The attached python script demonstrates a particularly difficult problem
>> I'm trying to solve. I've tried this in SolidWorks 2009 x64 and it
>> *eventually* creates the geometry but crashes while attempting to save as a
>> STEP or STL file. I'm looking for recommendations on how I can speed up the
>> process. The transverse cuts are completed rather quickly since the only
>> intersections are with the rectangular block. The longitudinal cuts take
>> about 20 minutes each and there are 108! The longitudinal cuts cut through
>> each of the 283 transverse cuts as well as the rectangular blocks.
>>
>>
>> --
>> Charles McCreary P.E.
>> CRM Engineering
>> 903.643.3490 - office
>> 903.224.5701 - mobile/GV
>>
>> ___
>> Pythonocc-users mailing list
>> Pythonocc-users@gna.org
>> https://mail.gna.org/listinfo/pythonocc-users
>>
>>
>
> ___
> Pythonocc-users mailing list
> Pythonocc-users@gna.org
> https://mail.gna.org/listinfo/pythonocc-users
>
>
___
Pythonocc-users mailing list
Pythonocc-users@gna.org
https://mail.gna.org/listinfo/pythonocc-users

Re: [Pythonocc-users] BRepAlgoAPI_Cut performance issues

[Dave Cowden]

Hi, Charles:

I have implemented a slicer here, which performs much much better than that:

http://code.google.com/p/emcfab

please feel free to steal code if it
helps-- i have a couple of utility wraper classes for creating slices.

Just looking briefly at your code, i'd guess that displaying your slices may
be your culprit. display is very very very slow-- most of the time i cannot
get things to run when i display lots of objects. But when i go in and
display only a few things it is very fast.

HTH
Dave

On Mon, Jun 21, 2010 at 4:39 PM, Charles McCreary <
charles.r.mccre...@gmail.com> wrote:

> This is cross-posted to the OpenCascade forum (
> http://www.opencascade.org/org/forum/thread_18806/):
>
> The attached python script demonstrates a particularly difficult problem
> I'm trying to solve. I've tried this in SolidWorks 2009 x64 and it
> *eventually* creates the geometry but crashes while attempting to save as a
> STEP or STL file. I'm looking for recommendations on how I can speed up the
> process. The transverse cuts are completed rather quickly since the only
> intersections are with the rectangular block. The longitudinal cuts take
> about 20 minutes each and there are 108! The longitudinal cuts cut through
> each of the 283 transverse cuts as well as the rectangular blocks.
>
>
> --
> Charles McCreary P.E.
> CRM Engineering
> 903.643.3490 - office
> 903.224.5701 - mobile/GV
>
> ___
> Pythonocc-users mailing list
> Pythonocc-users@gna.org
> https://mail.gna.org/listinfo/pythonocc-users
>
>
___
Pythonocc-users mailing list
Pythonocc-users@gna.org
https://mail.gna.org/listinfo/pythonocc-users