This document contains instructions for the Optaplanner workshop. Most exercises come from Red Hat Optaplanner instructions bundle.
The customer’s use case closely resembles the OptaPlanner example CloudBalancing. But there’s 1 big difference:
- Don’t assign too many processes to the same computer
-
Create a new run configuration:
- Main class: org.optaplanner.examples.cloudbalancing.app.CloudBalancingApp
- VM parameters (optional): -Xmx512M -server
-
Run the run configuration.
- Quick open 4computer-12processes.xml, solve it and terminate solving early after about 20 seconds.
- Notice how the solution assigns 6 processes to computer 0.
- Leave this window open to compare it later with your modified version.
Add a new hard constraint: no computer should have more than 4 processes assigned to it.
- Open and solve 4computer-12processes.xml. It should no longer have a computer with more than 4 processes.
- Open and solve 100computer-300processes.xml, in both the old and the new window. Compare the results.
- Both solutions should become feasible (0hard).
- The old window’s soft score is clearly better because it has more flexibility.
- Add a new score rule in the file cloudBalancingScoreRules.drl. No other files require changes.
- Read up about score traps, especially if 100computer-300processes.xml does not become feasible.
The customer’s use case closely resembles the OptaPlanner example CloudBalancing. But there’s 1 big difference:
- Don’t let a process hog half the CPU power of a computer (unless the computer doesn’t have much CPU).
- Create a new run configuration:
- Main class: org.optaplanner.examples.cloudbalancing.app.CloudBalancingApp
- VM parameters (optional): -Xmx512M -server
- Run the run configuration.
- Quick open 4computer-12processes.xml, solve it and terminate solving early after about 20 seconds.
- Click on the button Details of computer 3 to find out which process id’s are assigned to it.
- Notice how process 9 hogs 87.5% of the CPU of computer 3.
- Leave this window open to compare it later with your modified version.
- A process is hogging the CPU of a computer if it requires more than half of the computer’s CPU power.
- Exception: A computer with 6 CPU or less is never considered hogged.
- Add a new hard constraint: no process should hog the CPU of a computer.
- The customer has decided that they want the hogging implementation formula in Java, not in DRL. 1.But the constraint itself should be in DRL.
- Open and solve 4computer-12processes.xml. It should no longer assign process 9 to computer 3
- It must be feasible (0hard).
- Process 5 is (probably) still assigned to computer 1 and 2, because those computers have 6 CPU.
- Open and solve 100computer-300processes.xml, in both the old and the new window. Compare the results.
- Both solutions should become feasible (0hard).
- The old window’s soft score is probably better because it has more flexibility.
- Add a new Java method that checks if a process is hogging its computer.
- Add a new score rule in the file cloudBalancingScoreRules.drl and reuse that method.
The customer’s use case closely resembles the OptaPlanner example CloudBalancing. But there are differences:
- The computers are already bought, so we might as well use them all
- All computers have the same network bandwidth.
- The network bandwidth should be load balanced (= distributed fairly) across all computers.
-
Create a new run configuration:
- Main class: org.optaplanner.examples.cloudbalancing.app.CloudBalancingApp
- VM parameters (optional): -Xmx512M -server
-
Run the run configuration.
- Quick open 100computer-300processes.xml, solve it and terminate solving early after about 20 seconds.
- Notice how the used network bandwidth heavily differs per computer (and that capacity clearly limits it).
- Leave this window open to compare it later with your modified version.
- Remove the hard constraint requiredNetworkBandwidthTotal
- Remove the soft constraint computerCost
- Add a new soft constraint: The network bandwidth used per computer should be as equal as possible (evenly distributed).
Note: The GUI will still show the network bandwidth capacity per computer and color it red. Just ignore that.
- Open and solve 100computer-300processes.xml.
- It must be feasible (0hard).
- All computers must be used.
- The total network bandwidth used per computer must be close to each other, except if the computer has a single process which uses far more network bandwidth.
- Compare the results with the old window.
*Remove 2 score rules and add a new score rule in the file cloudBalancingScoreRules.drl. No other files require changes. *Read up about fairness score constraints. *There is no law which says that a score (hard or soft) should converge to 0.
Decide in which US states half of the population plus one should vote for the gamer candidate, for that candidate to win with as little votes as possible.
Presume everyone US citizen votes and there are only 2 candidates.
Hard constraints:
- The gamer candidate must collect at least 270 EC votes. Soft constraints:
- Minimize the number of votes for the gamer candidate.
- Try to speedup the process by setting up Difficulty Comparator and a Strength Comparator.
Customers can order deliveries to be made before a specific time. The set of rules contains a rule "arrivalAfterDueTime" that enforces a delivery to be made before its due time. The entity TimeWindowedCustomer contains a variable "arrivalTime". The arrivalTime at a Customer depends on previous visits. Because of this the variable needs to be updated after the solver makes a change. As the ShadowVariable annotations says there is a listener class that listens to changes made to the previousStandstill (the trigger to update this variable).
- Create a new run configuration:
- Main class: org.optaplanner.examples.vehiclerouting.app.MixedVehicleRoutingApp
- VM parameters (optional): -Xmx512M -server
With the code in the current state the solver cannot compute a solution yet.
Fill in the holes in the org.optaplanner.examples.vehiclerouting.domain.timewindowed.solver.ArrivalTimeUpdatingVariableListener class.
- All trips are delivered before their due time.
- Use the existing logic for computing the arrivalTime
- Enable full assert to verify the working the VariableListener
Use one of the cvrptw input files.
Documentation on shadow variables Hint before setting a variable relevant to the planning engine (PlanningVariables and ShadowVariables) notify the solver about this using scoreDirector.beforeVariableChanged method.
Constructions very similar are useful when making changes to the plan while solving.
Documentation on environment modes
This lab uses the code written by Geoffrey de Smet for the mixed vehicle routing problem.
For a package delivery service that picks up and delivers packages it is important that for a 'Ride' the contained 'Visit's are made by a single vehicle. And the pickup visit is performed before the delivery Visit.
-
Create a new run configuration:
- Main class: org.optaplanner.examples.vehiclerouting.app.MixedVehicleRoutingApp
- VM parameters (optional): -Xmx512M -server
-
Run the run configuration.
- Quick open cvrp-32customers, solve it and terminate solving early after about 20 seconds.
- Notice how not all pickup and deliveries that were initially connected are not serviced by a single vehicle.
- Leave this window open to compare it later with your modified version.
Define hard constraints that:
- Implement the VisitIndexVariableListener
- Enforces a pickup and delivery visit of a ride are performed by a single truck
- Pickup visit is made before a delivery visit using the 'visitIndex' variable
- All pickups and deliveries of a single ride are made by a single vehicle
- The pickup visit of a ride is always scheduled before the delivery visit
- Enable full assert to verify the working the VariableListener
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent