Nextmv version 0.8.0 is here! This release features significant performance improvements for solving complex routing problems with the addition of ALNS and brings Dash (simulation) into the code
repo in GitHub. Version 0.8.0 introduces breaking changes that will need to be addressed prior to upgrading.
Note: Cloud customers are not affected by these changes at this time and we will notify you when v0.8.0 is available for use on Nextmv Cloud.
Dash
Moved to code monorepo
Before downloading v0.8.0, it is important to note that we’ve added Dash to the code monorepo on GitHub. This means import paths have changed (github.com/nextmv-io/dash
is now github.com/nextmv-io/code/dash
) and this must be reflected when using the go get
command.
Version 0.7.3 and before | Version 0.8.0 and above |
---|---|
github.com/nextmv-io/dash | github.com/nextmv-io/code/dash |
Hop
Heuristic modeling with ALNS (Adaptive Large Neighborhood Search)
This version includes the addition of support for adaptive large neighborhood search (ALNS), a heuristic solver for finding more improving solutions faster. The addition of ALNS brings significant performance improvements. This can be particularly beneficial when grouping many vehicles together in a fleet and solving large-scale routing problems.
ALNS is now supported in the vehicle and fleet engines by default. No additional upgrade steps are required to use ALNS for users employing vehicle.DefaultSolver(state, opt)
or fleet.DefaultSolver(state, opt)
. However, for users employing solve.Minimizer(outputState, opt)
, solve.Minimizer(outputState,opt)
will need to be replaced with vehicle.Solver(root, opt)
or fleet.Solver(root, opt)
to use ALNS in the vehicle or fleet engine, respectively.
Default operators and parameters are provided for use with ALNS. Custom inputs are supported if required. See the package docs for additional details. Further support will be provided for ALNS in vehicle and fleet engines in future releases.
Hop API changes
A context.Context
argument has been added to the following method declarations:
model.State.Next()
solve.Solver.All()
solve.Solver.Last()
While this argument is now required when calling implementations of these methods, it is not required that a user do anything with it. Its purpose is to empower a user to end a run sooner in the process of diagram construction, so as to better respect a prescribed time limit.
Aditionally, diagram node generation stops after n
nodes. Previously, n
nodes were explored, but many more may have been generated. Upgrading and not adjusting n
may result in fewer good solutions, so higher n
values may be required to achieve the same results.
Hop API additions
To support hybrid optimization with ALNS, two new interfaces have been added:
solve.Hybrid
solve.Inferrer
The first enables the combination of different solvers and the parallelization of multiple solvers. The second can be used to share results between solvers.
Engines (formerly HopM)
We have renamed HopM to engines. This means import paths have changed (github.com/nextmv-io/code/engines
) and this must be reflected in your go get
command.
Version 0.6.6 and before | Version 0.7.0 - 0.7.3 | Version 0.8.0 and above |
---|---|---|
github.com/nextmv-io/hopm | github.com/nextmv-io/code/hopm | github.com/nextmv-io/code/engines |
Engines API changes
As above, a context.Context
argument has been added to the following method declarations:
fleet.Router.Feasible
fleet.Router.Optimal
fleet.Router.WarmFeasible
This argument is required when calling implementations of these methods. See above in Hop's "API Changes" section for some additional notes on this change.
Also, service times durations []int
and maximum waiting times before each window waitMax []int
now need to be provided when constructing a window measure. Previously, service and waiting times were part of a measure. Now, times are provided to a measure. This enables the specification of maximum wait time, for example.
Engines API additions
When using a CustomRouter
, a function must now be passed in for each phase. Two new default functions are available for use (these are used for the DefaultRouter
):
fleet.SolverFuncGenerator
fleet.AlnsSolverFuncGenerator
New methods have been added to the fleet Engine to enable the following:
- Set a vehicle's state (
fleet.State.SetVehicle
) - Set list of locations for a vehicle (
vehicle.State.SetLocations
) - Set and validate routes for a vehicle (
vehicle.State.SetRoute
) - Specify a custom compatibility constraint for a vehicle and a location (
fleet.CustomVehicleFilter()
)
Enforcement of assignment
Default UnassignedPenalties
behavior has changed:
- If no unassigned penalties are provided, assignment will be enforced (note, this could result in no feasible solutions being returned).
- If unassigned penalties are provided, assignment will not be enforced. Unassignment will be discouraged (more or less, based on the penalty value).
If using a penalty to prevent unassigned locations, it is advised to remove it in order to benefit from the new default behavior for the fleet engine: if no UnassignedPenalties
are provided, all locations are assigned a vehicle. Note, the enforcement of assignment could result in no feasible solutions being returned. To discourage (but still allow for some) unassigned locations, we suggest to add unassigned penalties (see best practices for more on unassignment penalties).
Measures
Measures API changes
Index interfaces, such as haversineByIndex
and euclideanByIndex
, will be soon deprecated. ByIndex
measures should now be generated with the Indexed
function.
Extend
There is a new suite of modules, called extend
, which use third-party dependencies such as AWS Lambda or OSRM. This may be a breaking change as these same features used to be part of dash
, hop
and hopm
(now engines
). This means import paths have changed (github.com/nextmv-io/code/hopm/measure/osrm
is now github.com/nextmv-io/code/extend/measure/osrm
) and this must be reflected when using the go get
command.