bd_warehouse.gears vs gggears

[kcleung]

Both bd_warehouse.gears

https://github.com/gumyr/bd_warehouse

and gggears by @GarryBGoode

https://github.com/GarryBGoode/gggears

are build123d-based tools that make gears.

At the moment, gggears can make many more types of gears than bd_warehouse, the latter of which can only make involute gears by simple extrusion of a 2D gear tooth profile.

I had a look at source code of both projects, and it appears that the mechanism of gggears is much more complicated in order to make gears such as helical and bevel, which cannot be simply done by simple extrusion of a 2D profile.

Just wonder what is the plan for bd_warehouse on gears in the near future? Would it be a good idea to amalgamate the gggears project into the gear department of bd_warehouse?

[gumyr]

Contributions to bd_warehouse are welcome but having independent part libraries is great - I see no need to merge them. gggears is listed in External Tools and Libraries in the docs.

[GarryBGoode]

I don't see any need or ambition to merge gggears into bd_warehouse. For one thing, gggears can get really slow, which is the price of complicated math in python on 1 thread. This could be rather out of place in bd_warehouse.

If a user just needs to use a standard gear, bd_warehouse implementation should be more than enough.
If a user would like to design a gear with its nitty-gritty details, they can come to gggears.

[kcleung]

I don't see any need or ambition to merge gggears into bd_warehouse. For one thing, gggears can get really slow, which is the price of complicated math in python on 1 thread. This could be rather out of place in bd_warehouse.

If a user just needs to use a standard gear, bd_warehouse implementation should be more than enough. If a user would like to design a gear with its nitty-gritty details, they can come to gggears.

Ahhh I see. Would it be possible parallelize the parts so that they run multithread? Maybe in a separate topic you can point out to all parts that are inefficient, and I can see if I can parallelize those parts. My postgraduate degree was on improvement of application performance on multithreaded, multicore and distributed architectures :)

[GarryBGoode]

Oh my. There are obvious parallelization possibilities. If you're truly intrigued, check out the generate_nurbs function in gggears_convert.py. It is a rather heavy solver computation that is run on an array of ~2...9? input datasets. 22 in case of stress test. Last time I tried it failed for a simple banal reason: pickle.

I tried the multiprocessing module which handles parallel computing for python, and it needs to pickle the functions (objects?) related to the computation, and pickle somehow doesn't like them being inside class/object methods. There are workarounds, something to do with declaring them global, but it didn't take me far. It kept running into newer objects it didn't like. It seemed like I might need to turn my whole class hierarchy inside out to comply with pickle for that, so I let it go.

So anyway, if you're interested, here's a thread about the slow gears: GarryBGoode/gggears#4