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
cut_then_merge.py
Description: Binary data
_______________________________________________ Pythonocc-users mailing list Pythonocc-users@gna.org https://mail.gna.org/listinfo/pythonocc-users
