The number of iterations the optimiser will run for. Each iteration may result in an improved solution and hence a higher number of iterations increases the probability of finding a better solution. This comes at the cost of increasing the duration the optimiser will run for.
Batched loads is a scheduling constraint that enforces a strict “Pickup - Delivery” cycle where once a vehicle begins making deliveries, it cannot pick up new orders until it has delivered all its current orders. (See Section 2.20 for further information.)
Colocated pickups refers to a scheduling constraint that all orders in a load must have come from the same location.
If sticky deliveries are enabled, then the optimiser will attempt to assign all the orders being delivered to an individual location to the same vehicle. The intention of this is to reduce the number of different vehicles that make deliveries at a location.
A scaling factor can be applied to speeds, costs, weights and volumes in the scenario. This allows the user to increase the effect that a particular variable has on the optimiser. A value of 0 means that no scaling is applied. The scaling factors include speed scale, cost scale, weight scale and volume scale.
The optimiser can be restricted to only consider orders and vehicles that are located within a specific geographic area. This area is called a geofence and it takes the form of a bounding box that is defined by the latitudes of its southern and northern boundaries and by the longitudes of its western and eastern boundaries.
The geofence can operate in one of two modes: hard and soft.
If the geofence is in hard mode, then the optimiser will report an error for any order that has pickup or delivery locations outside the geofence. It will also report an error for any vehicle that has start or finish locations outside of the geofence. In the event of such errors being detected, optimisation will not proceed.
If the geofence is in soft mode, then the optimiser will not assign any order whose pickup or delivery location is outside the geofence. It will not use any vehicle whose start or finish location is outside the geofence. In this mode optimisation will proceed using orders and vehicles that are within the geofence.
The maximum size of the neighbourhood for the optimiser. At each iteration of the optimiser, the solution is unpacked and changed to find a new solution with the neighbourhood being the amount to unpack. Smaller neighbourhoods are quicker to change but may result in worse quality solutions, while larger neighbourhoods need longer running time but may lead to better quality solutions. Note that the maximum neighbourhood size must be at least ten.
If preferred vehicles are specified for an order, then there are three types of rewards that can be specified.
Preferred Vehicle Fixed Reward
This is a fixed reward for assigning the order to one of its preferred vehicles.
Preferred-Vehicle Weight Reward
This reward is multiplied by the weight of the order if it is assigned to one of its preferred vehicles. It can be used to give a higher priority to assigning heavier orders to their preferred vehicles.
Preferred-Vehicle Volume Reward
This reward is multiplied by the volume of the order if it is assigned to one of its preferred vehicles. It can be used to give a higher priority to assigning larger orders to their preferred vehicles.
Each order that is not assigned by the optimiser incurs a hidden cost, called the unassigned penalty. Typically, you want the optimiser to assign all the orders in the input. Consequently, the unassigned penalty is usually very large relative to any other costs (monetary or hidden) in the scenario. There are multiple different methods for setting the value of the unassigned penalty for the orders in a scenario. Each method is called an unassigned penalty scheme.
There following unassigned penalty schemes are supported:
Fixed
There is a fixed unassigned penalty for each order. You can set the size of this penalty in the input. This scheme is the default.
Legacy
The unassigned penalty for each order is 4,500,000 divided by the number of orders in the scenario. This scheme is deprecated and will be deleted in a future release.
Some orders may be too large or heavy to fit on a compatible vehicle in the fleet. Order splitting lets the optimiser automatically split up such orders into smaller orders that will fit on a vehicle. How this occurs depends upon the composition of the orders and is controlled by the optimiser’s order splitting strategy.
Currently, the following order splitting strategies are supported:
None
No order splitting is allowed.
Split By Weight
Orders will be split into multiple orders, each of which will have weight equal to maximum weight capacity of the largest compatible vehicle. Any remaining weight will be allocated to an additional order.
Note: All orders must have zero volume to use this scheme.
Split By Volume
Orders will be split into multiple orders, each of which will have volume equal to the maximum volume capacity of the largest compatible vehicle. Any remaining volume will be allocated to an additional order.
Note: All orders must have zero weight to use this scheme.
Example:
Consider the case where we have an order with identifier Order_1 and volume 24. The largest vehicle in the fleet that is compatible with Order_1 has a maximum volume capacity of 10. If splitting by volume is enabled, then this order will be split into the three separate orders shown in Table 1. Each of the split orders is assigned a new identifier that consists of the identifier of the original order, followed by an underscore (“_”) and then an integer “split index”.