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 <charles.r.mccre...@gmail.com>
> 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 <sfo...@gmail.com>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.
>>>>>>> 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
>>>
>>
>>
>>
>> --
>> 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
