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