Fixed Cost behaves oddly #2957
Replies: 8 comments
-
|
seems related to #880 |
Beta Was this translation helpful? Give feedback.
-
|
Indeed, I thought 880 was closed. |
Beta Was this translation helpful? Give feedback.
-
|
Hi, |
Beta Was this translation helpful? Give feedback.
-
|
Yes, according to the team it is an open issue. |
Beta Was this translation helpful? Give feedback.
-
|
So, the behavior I described should be expected? |
Beta Was this translation helpful? Give feedback.
-
|
AFAIK during the local search there is no heuristic which try to insert a "bunch of nodes" then see if it reduce the objective value or try without taking into account the fixed cost first then compare both result... I'll try to write a minimal example to show the issue |
Beta Was this translation helpful? Give feedback.
-
|
Hi, I've seem this has been removed from the backlog. Was there any progress on this issue? |
Beta Was this translation helpful? Give feedback.
-
|
sorry, team is still aware of it but AFAIK currently there is no one working on it. |
Beta Was this translation helpful? Give feedback.
-
Seems that vehicle FixedCost is evaluated vs. a single Node's disjunction penalty: if the FixedCost is slightly higher the vehicle is not used and similarly no vehicle was used and all Nodes were dropped.
10 Vehicles, 80 Orders.
If Solver would have allocated the vehicle, it would server multiple Nodes and reduce penalty substantially.
When FixedCost was even a bit lower than disjunction penalty (of one Node) all necessary vehicles were allocated and served the Nodes.
Looks like the criteria to allocate was just based one vehicle vs. one Node. Correct?
If I'm not wrong, this creates undesired results.
Beta Was this translation helpful? Give feedback.
All reactions