search

ModischFabrications / CutSolver

Webservice to determine ideal cut placement on stocks
https://cutsolver.modisch.me
GNU Lesser General Public License v3.0
31 stars 6 forks source link

Extend CutSolver to accept multiple stock lengths/number of stock #52

Closed erikhagemeijer closed 3 months ago

erikhagemeijer commented 1 year ago

Hello,

Is it possible to extend CutSolver to be able to accept multiple number/length tuples for stock and a default length, so I can use this solution to optimize the use of available stock?

ModischFabrications commented 1 year ago

It should be technically possible, but I'm not working on it at the moment. I'm marking it as a possible extension, I'm more than happy to look at a pull requests for it though.

ModischFabrications commented 3 months ago

@erikhagemeijer have a look at the output example in my branch feature/multi-stocks : https://github.com/ModischFabrications/CutSolver/blob/feature/multi-stocks/tests/res/out/testresult_multi.json

This is what you would expect from the API, right? I might change a few things, but that's the rough sketch I have in mind

erikhagemeijer commented 3 months ago

Hello Robin,

I've read your mail and example and I am pleased with it! Sorry I forgot to reply that to you...

The information you provide is rich and easy to process.

A bit hesitant to ask, but maybe not so difficult to implement as you start working on the agreed specs: there are 2 kinds of rest pieces, the one you throw away and one you can store for later use. A rest piece with a minimum length will be stocked, if it is shorter it will be garbage. So next to the max_length there can be a min_length. If this means a lot of extra work this can be something for a future addition.

With kind regards,

Erik Hagemeijer.

Op 2 apr 2024, om 23:21 heeft Robin Modisch @.***> het volgende geschreven:

@erikhagemeijer https://github.com/erikhagemeijer have a look at the output example in my branch feature/multi-stocks : https://github.com/ModischFabrications/CutSolver/blob/c35e8a6d6616975cad345add740db4c43002910a/tests/res/out/testresult_multi.json

This is what you would expect from the API, right? I might change a few things, but that's the rough sketch I have in mind

— Reply to this email directly, view it on GitHub https://github.com/ModischFabrications/CutSolver/issues/52#issuecomment-2033120850, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGZ4T2ACFY27UPDQZVSHUATY3MON7AVCNFSM57PHKSIKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMBTGMYTEMBYGUYA. You are receiving this because you were mentioned.

ModischFabrications commented 3 months ago

Perfect, I will continue work on the implementation then.

I will add your request to #68 , could be a nice addition there.

ModischFabrications commented 3 months ago

Relevant for replacement vs additional path solution is the execution time for old-style jobs.

old: image

new (only bruteforce migrated, others are have cheap workarounds): image

Going from 4, 3, 2 to 5, 3, 2 in test_m increases runtime of bruteforce to 720ms and 83ms (wow!), seems like the new permutations increase performance a lot more than the new solver type slows it down. Old solution has speedup from 8s to 0.2s for 8, 3, 2, which makes even larger jobs possible.

New structure shows minor slowdown, but I think it's worth it, at least for the bruteforce solver. Unifying the codebase will also make testing more thorough and maintenance much easier.