Version 0.8.0 released

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.

go get 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.

go get 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.