Extend CutSolver to accept multiple stock lengths/number of stock

Question

Extend CutSolver to accept multiple stock lengths/number of stock

Closed this issue 9 months ago · 5 comments

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?

Answer 1 · 2022-08-24T13:48:43.000Z

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.

Answer 2 · 2024-04-02T21:21:13.000Z

@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

Answer 3 · 2024-04-07T08:22:22.000Z

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 <#52 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGZ4T2ACFY27UPDQZVSHUATY3MON7AVCNFSM57PHKSIKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMBTGMYTEMBYGUYA>. You are receiving this because you were mentioned.

Answer 4 · 2024-04-07T19:43:23.000Z

Perfect, I will continue work on the implementation then.

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

Answer 5 · 2024-04-09T22:27:42.000Z

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

old:

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

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.