Stream: brlcad

Topic: g-stl multicore?


view this post on Zulip Nathan McCorkle (Feb 24 2020 at 19:34):

Hi, it seems g-stl might be using 2 cores (I see two processes in top with roughly the same run time of 500+ minutes, but maybe I accidentally started 2 commands without realizing, or forgetting)... is there any way to get it to use more cores? I have a 22 core machine I'd like to use to speed things up, if possible

view this post on Zulip Sean (Feb 24 2020 at 19:35):

All of the converters are single-threaded currently. There's not much technical barrier that would prevent them from running in parallel, but it's definitely something that hasn't been worked on -- area for someone to work on.

view this post on Zulip Sean (Feb 24 2020 at 19:43):

@Nathan McCorkle 10+ hours for an export is not typical -- the few instances I've seen that happen are when the booleans are repetitive (lots of wasted recomputation) or when a machine is thrashing because it doesn't have enough memory for the task or when there's been an evaluation bug in the triangle boolean evaluator.

view this post on Zulip Sean (Feb 24 2020 at 19:44):

And there's not a real good way to distinguish "really long running" conversions from "running forever" conversions

view this post on Zulip Nathan McCorkle (Feb 24 2020 at 20:31):

hmm, the G database was generated in about 15-30 seconds and looks fine, even when I raytrace a few frames

view this post on Zulip Nathan McCorkle (Feb 24 2020 at 20:31):

I can post the TCL, give me a few mins

view this post on Zulip Nathan McCorkle (Feb 24 2020 at 21:38):

here's the G https://github.com/nmz787/microfluidic-cad/blob/master/BRLCAD/tobacco_mesophyll_protoplast_fusion_device/tobacco_mesophyll_protoplast_fusion_device.g
the TCL:
https://github.com/nmz787/microfluidic-cad/blob/master/BRLCAD/tobacco_mesophyll_protoplast_fusion_device/tobacco_mesophyll_protoplast_fusion_device.tcl
and the Python that generates the TCL:
https://github.com/nmz787/microfluidic-cad/blob/master/BRLCAD/tobacco_mesophyll_protoplast_fusion_device.py

view this post on Zulip Nathan McCorkle (Feb 24 2020 at 21:38):

draw the object "slab_minus_bot_and_io" in mged

view this post on Zulip Nathan McCorkle (Feb 25 2020 at 05:27):

@Sean so I think I might be wasting computation as you put it... how do I clone an object so it doesn't waste computation? What mged/TCL command?

view this post on Zulip Nathan McCorkle (Feb 25 2020 at 05:28):

for example, I have 800 of these similar lines in the TCL:
in brlcad_tcl__tgc1.s tgc 15 350 0 0 0 55 15 0 0 0 10 0 15 10
in brlcad_tcl__tgc2.s tgc 15 390 0 0 0 55 15 0 0 0 10 0 15 10
where only the name and first two numbers change

view this post on Zulip Sean (Feb 27 2020 at 04:09):

@Nathan McCorkle that's pretty cool! Screen-Shot-2020-02-26-at-11.04.59-PM.png

view this post on Zulip Sean (Feb 27 2020 at 04:11):

And yes, looking at the output database, I suspect that you encountered O(N^3) exponential time

view this post on Zulip Sean (Feb 27 2020 at 04:12):

each triangle for each of those tiny cylinders is getting tessellated against the entirety preceding, which gets increasingly slower and slower as it progresses

view this post on Zulip Sean (Feb 27 2020 at 04:36):

There are a couple minor changes that would likely speed things up tremendously. First would be to try changing the tree structure so that the tgc's are all grouped together before being unioned into the larger structure.

view this post on Zulip Sean (Feb 27 2020 at 04:38):

So instead of "A u B u C u D ..." you have "A u G1" where G1 is "B u C u D ..." which are clusters of those small cylinders.

view this post on Zulip Sean (Feb 27 2020 at 04:39):

that way, the tessellation code will resolve the majority of triangles only once against the larger A structure

view this post on Zulip Nathan McCorkle (Feb 27 2020 at 05:53):

Hmm, so I see in the TCL it shows after a set of 100 TGCs being created, a line like this:
g bifurcated_posts.g brlcad_tcl__tgc1.s brlcad_tcl__tgc2.s brlcad_tcl__tgc3.s ... ...

view this post on Zulip Nathan McCorkle (Feb 27 2020 at 05:54):

So aren't they already grouped before being unioned?

view this post on Zulip Nathan McCorkle (Feb 27 2020 at 05:55):

The immediate next line is:
comb funnel.c u lengthened_polygon.c - bifurcated_posts.g

view this post on Zulip Nathan McCorkle (Feb 27 2020 at 05:56):

It sounds like you're saying to union all the TGCs instead of grouping them, then make the unioned output a group? But I thought objects had to be touching or overlapping for a union operation to work

view this post on Zulip Nathan McCorkle (Feb 27 2020 at 05:56):

I'll give it a try though

view this post on Zulip Nathan McCorkle (Feb 27 2020 at 08:18):

does this look any better?
https://pastebin.com/stBH14Qq

view this post on Zulip Nathan McCorkle (Feb 27 2020 at 08:22):

I'll need to change my script a bit to further cluster all the groups of sets of small TGCs... at this point there are 10 combinations of the sets of small TGCs unioned

view this post on Zulip Sean (Feb 27 2020 at 16:12):

Nathan McCorkle said:

So aren't they already grouped before being unioned?

I thought I saw that they weren't but now you have me doubting what I saw. I have a facetization going now and it's been crunching for hours, so I should have a better idea soon what's going on.

view this post on Zulip Sean (Feb 27 2020 at 16:13):

Nathan McCorkle said:

It sounds like you're saying to union all the TGCs instead of grouping them, then make the unioned output a group? But I thought objects had to be touching or overlapping for a union operation to work

It should work either way. It's also possible they simply need to be nudged off of being co-planar so the evaluation doesn't have to guess the intent.

view this post on Zulip Nathan McCorkle (Feb 27 2020 at 17:59):

Sean said:

It should work either way. It's also possible they simply need to be nudged off of being co-planar so the evaluation doesn't have to guess the intent.

hmm, this would be destined for semiconductor-style nanfabrication... the resolution of the fabrication wouldn't be atomic for this model but certainly some of the things that I plan to do could be single or say <=10 atom layers thick...

view this post on Zulip Sean (Feb 28 2020 at 12:10):

@Nathan McCorkle and that would be fine... I'm referring to the cases where you're combining two shapes with a union, but they're defined as going from |---A---|---B---| to define some |--------------| region that's "A u B". Instead, you'd position the interior face such that they overlap ever so slightly. that way it can distinguish whether you meant two regions that happen to coincide (i.e., |-------||-------| ) or clearly one region by overlapping them (even as little as 0.0000000001).


Last updated: Oct 09 2024 at 00:44 UTC