Search code examples
constraintsredhatoptaplanner

Optaplanner: Dynamic number of planning variable based on ProblemFactCollectionProperty


Problem: Truck assignment with limited quantity to deliver to the customers.

The truck has to be assigned to the customer. As the truck has limited quantity, the truck needs to return back to reload again to deliver to the next customer.

Trip - load at Depot, unload at customer/few customers, come back to depot.

The problem facts are available trucks and customers to be delivered. We need to find dynamically how many trips can be possible from truck-based on few timing-related conditions(like truck available time, driver hours, etc).

The solution I can think off: Pre-compute max number of trips by the truck based on business understanding- use this as a planning variable. Provide hard score for violating time constraints, so few trips will be left unassigned if truck exceeds the available truck/trip time.

Need Help: For every solved example, we have a fixed number of planning variables before planning. Even In the chained planning variable(Like TSP,VRP), we have the fixed number of trucks beforehand.

Any help is appreciated. If there is no direct solution, is the approach I have come up is the best possible?


Solution

  • That solution is indeed recommended currently:

    1. Provide enough trucks in the anchorValueRange to make sure a feasible solution can be found. Defining that number can be tricky: typically double the average usage. For example, if you have 300 visits and do on average 100 visits per truck, give it 6 trucks, as you never expect it to use more than 6 trucks (and probably a lot less). If trucks have skills or affinity, this becomes a bunch more complex.

    2. Add an extra score level: if you're on HardSoftScore, switch to HardMediumSoftScore.

    3. Add a medium constraint to penalize the number of trucks used. This is softer than the hard constraints (capacity etc) and harder than the soft constraints (distance etc).

    (The alternative, adding/removing values to the value ranges on the fly, is only theoretically possible in OptaPlanner's architecture at the moment (don't use addProblemFactChanges for this!). It might sound like the perfect solution, but there are many subsystems that profit from a fixed value range, so that approach would have severe trade-offs.)