IVR Solve RequestSolve Request

Overview

The solve request houses the model and the action that should be performed on the model.

Applicable models

• IVR7 ivr7-kt461v8eoaif
• IVR8 ivr8-yni1c9k2swof

Endpoint

• POST: https://api.icepack.ai/vehicle-router/solve/

Solve Request

Schema definition

message SolveRequest {
  optional Model model = 1;     // either model or modelId should be specified
  optional string modelId = 2;  // the model ID from a previously optimised
                                // request (for use with evaluate solve type)
  repeated TaskSequence routes = 3;  // for solveType = [Evaluate, ReOptimise].
  optional SolveType solveType = 4 [default = Optimise];
}

Fields

model

The target model which should be solved (commonly specified). If not specified, the modelId field should be provided with a valid reference to an existing model.

modelId

A GUID which refers to a valid model which has recently been solved. Model data are stored in a hot cache for 24 hours after which they are deleted. If a modelId references a model which no longer exists on the server, an error is returned indicating that the target model could not be found.

routes

An optional list of routes which specify the task sequence, typically used in conjunction with the modelId and the solve types Evaluate and ReOptimise. The task sequence is also available as a field within the model definition where the task sequence specified in the SolveRequest will override any task sequence specified in the encapsulating model. This allows one to run multiple evaluate requests without having to redefine a model for each evaluate request. This is a desireable design pattern when implementing user interfaces (UIs) where a drag-and-drop functionality is desired. The model can be solved, results returned to a UI and then changes to the solution can be evaluated by using the primary request ID (returned by the initial solve request with the complete model) to identify the upstream model which should be used, in conjunction with the specified task sequence. This allows for rapid evaluation of user-edit in terms of feasibilities, costs and network routing.

solveType

An enumerator which defines the target solver behaviour required for the specified model.

Notes

• Either a complete model or a valid previous requestID for the modelId should be specified.
• Predefined routes are optional and will be ignored for solveType Optimise

Solve Request Solve Type

Schema definition

enum SolveType {
    Optimise = 0;               // Ignores provided routes. Solves using internal seed mechanisms.
    Evaluate = 1;               // Evaluates the provided route sequence. Single solution response.
    ReOptimise = 2;             // Uses routes as starting solution and continues to optimise.
}

Fields

Optimise

Issues an Optimise request which aims to find a feasible solution to the provided model (either a provided model, or reference to an existing model).

Evaluate

Issues an Evaluate request which is used in conjunction with a defined set of routes. The feasibility status of the prescribed routes is returned in the solution response.

ReOptimise

Issues a ReOptimise request which is used in conjunction with a defined set of routes. If the routes provided are feasible with respect to the model referenced, this is used as a candidate starting solution in the search algorithm. If the solution is feasible, the solution returned by the engine is guarenteed to be better than or equal in cost to the provided task sequence. There are several use cases for type of solve request. Small modification may be made to a model which perhaps change the context of a given solution slightly. By providing a high quality starting solution to the solver, the solve time may be reduced somewhat. Another use case is that on much larger models, a heuristic design is employed by the solver. By providing a starting solution, additional search time may be given to the solve around the neighbourhood specified.