in reply to Re^2: Tricky chemicals optimization problem
in thread Tricky chemicals optimization problem
I read and re-read your further description, but I cannot make any sense of it.
As far as data goes, I cannot provide the real data but will do my best to mock up a dummmy dataset that represents similar idea and post ASAP
You wouldn't need to identify exactly what the data represented, so it would be useless to a competitor.
The problem with "mocked up" data is that unless the mocking up is done with an good understanding of the problem -- which you've identified you do not yet have -- it usually misses the subtleties of the real problem; and you end up wasting time solving the wrong problem.
The purpose of asking for data and required output was to allow us to perhaps help you arrive at your understanding of the problem by getting many brains looking at the problem.
One thing that I've learnt over the years -- probably above all other hard won lessons -- is that until you understand the problem you are trying to solve to the level you can adequately explain it to others, you stand very little chance of finding a good solution.
At this point, on the basis of the information so far, I personally have literally no idea where to start, nor even what questions to ask.
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^4: Tricky chemicals optimization problem
by Anonymous Monk on Jan 10, 2017 at 13:50 UTC | |
Read more... (9 kB)
the goal is to achieve the daily required processing time ( column three) for each unique chemical on as few machines as possible. Chemicals of the same identifier (same type)can be consolidated onto one machine. Chemicals of different types cannot be consolidated onto one nozzle on one machine. If a chemical is placed on a machine, its required demand must detract from that machines overall capacity. the end goal is to hit the demand with the fewest machines. Is this a bit more clear? I've tried to take all the jargon out of it best I can. | [reply] [d/l] |
|
Re^4: Tricky chemicals optimization problem
by Anonymous Monk on Jan 10, 2017 at 13:52 UTC | |
here is a snap shot of one days data
Each machine has a max processing capacity to run at 95% of the day (so 24hrs*60mins*60seconds*95%) - this is constant to simplify, and it represents 100% of capacity for each machine. The processing time of each chemical below will take up a portion or all of this capacity. On a machine each chemical requires its own nozzle, but each chemical only needs one nozzle, so if you have three nozzles for C4 on three different machines you could consolidate all three to one nozzle on one of the machines if capacity on that machine allows for it. Here is some data
Read more... (9 kB)
The goal is to achieve the daily required processing time (column three) for each unique chemical on as few nozzles as possible. Chemicals of the same identifier (same type) can be consolidated onto one machine. Chemicals of different types cannot be consolidated onto one nozzle on one machine. If a chemical is placed on a machine, its required demand must detract from that machines overall capacity. the end goal is to hit the demand with the fewest nozzles first, and then fewest machines second. Is this a bit more clear? I've tried to take all the jargon out of it best I can. | [reply] [d/l] |
by haukex (Archbishop) on Jan 10, 2017 at 14:15 UTC | |
Hi Anonymous, I actually had to do a diff of your two replies to figure out if there are differences, and it appears that there are, but only in the last paragraph in a few words. I'll consider the other node for reaping, but I'd strongly recommend you register an account so that you can edit nodes. (Update: That would have been useful in the case of this node as well.) Regards, | [reply] |
by LanX (Saint) on Jan 10, 2017 at 15:24 UTC | |
Unfortunately I've already considered the newer duplicate, while you considered the older original, which already got a reply in the meantime. And I think I've checked if there are any consideration conflicts before doing so. So hopefully people will now do the right thing. .. :)
Cheers Rolf
| [reply] |
by haukex (Archbishop) on Jan 10, 2017 at 15:36 UTC | |
by BrowserUk (Patriarch) on Jan 10, 2017 at 15:08 UTC | |
Okay. A simple 2 field sort shows us that each machine has multiple chemicals and multiple nozzles for some of those chemicals. And multiple machines are serving the same chemical:
Each machine has a max processing capacity to run at 95% of the day (so 24hrs*60mins*60seconds*95%) - this is constant to simplify, and it represents 100% of capacity for each machine. What you haven't supplied:
My first pass intuition is that the Greedy approximation method would get pretty close to an optimal solution, and would be pretty fast. It would certainly serve as a starting point from which you might run a Genetic Algorithm for a few hours or days to see if it can find much by way of further savings. With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority". The enemy of (IT) success is complexity.
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] [d/l] |
by BrowserUk (Patriarch) on Jan 10, 2017 at 22:10 UTC | |
How do these results sets look (assuming an unlimited number of nozzles per machine)?
Each run requires a couple of seconds and would take no more if you have a different capacity for each machine; but you would have to supply them. With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority". The enemy of (IT) success is complexity.
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] [d/l] [select] |
by Anonymous Monk on Jan 11, 2017 at 08:40 UTC | |
by BrowserUk (Patriarch) on Jan 11, 2017 at 11:06 UTC | |
| |
