vrplib is a Python package for working with Vehicle Routing Problem (VRP) instances. The main features are:
- reading VRPLIB and Solomon instances and solutions, and
- writing VRPLIB-style instances and solutions.
vrplib works with Python 3.8+ and only depends on numpy. It may be installed in the usual way as
pip install vrplibimport vrplib
# Read VRPLIB formatted instances (default)
instance = vrplib.read_instance("/path/to/X-n101-k25.vrp")
solution = vrplib.read_solution("/path/to/X-n101-k25.sol")
# Read Solomon formatted instances
instance = vrplib.read_instance("/path/to/C101.txt", instance_format="solomon")
solution = vrplib.read_solution("/path/to/C101.sol") # only 1 solution formatinstance and solution are dictionaries that contain all parsed data.
>>> instance.keys()
dict_keys(['name', ..., 'edge_weight'])
>>> solution.keys()
dict_keys(['routes', 'cost'])The functions write_instance and write_solution provide a simple interface to writing instances and solutions in VRPLIB-style:
write_instanceadds indices to data sections when necessary (EDGE_WEIGHT_SECTIONandDEPOT_SECTIONare excluded).write_solutionadds theRoute #{idx}prefix to routes.
Note that these functions do not validate instances: it is up to the user to write correct VRPLIB-style files.
import vrplib
instance_loc = "instance.vrp"
instance_data = {
"NAME": "instance",
"TYPE": "CVRP",
"VEHICLES": 2,
"DIMENSION": 1,
"CAPACITY": 1,
"EDGE_WEIGHT_TYPE": "EUC_2D",
"NODE_COORD_SECTION": [[250, 250], [500, 500]],
"DEMAND_SECTION": [1, 1],
"DEPOT_SECTION": [1],
}
vrplib.write_instance(instance_loc, instance_data)NAME: instance
TYPE: CVRP
VEHICLES: 2
DIMENSION: 1
CAPACITY: 1
EDGE_WEIGHT_TYPE: EUC_2D
NODE_COORD_SECTION
1 250 250
2 500 500
DEMAND_SECTION
1 1
2 1
DEPOT_SECTION
1
EOF
import vrplib
solution_loc = "solution.sol"
routes = [[1], [2, 3], [4, 5, 6]]
solution_data = {"Cost": 42, "Vehicle types": [1, 2, 3]}
vrplib.write_solution(solution_loc, routes, solution_data)Route #1: 1
Route #2: 2 3
Route #3: 4 5 6
Cost: 42
Vehicle types: [1, 2, 3]
Warning
This functionality is deprecated and will be removed in the next major version.
import vrplib
# Download an instance and a solution file
vrplib.download_instance("X-n101-k25", "/path/to/instances/")
vrplib.download_solution("X-n101-k25", "/path/to/solutions/")
# List all instance names that can be downloaded
vrplib.list_names() # All instance names
vrplib.list_names(low=100, high=200) # Instances with between [100, 200] customers
vrplib.list_names(vrp_type="cvrp") # Only CVRP instances
vrplib.list_names(vrp_type="vrptw") # Only VRPTW instancesThe VRPLIB format is the standard format for the Capacitated Vehicle Routing Problem (CVRP). An example VRPLIB instance looks as follows:
NAME: Example
EDGE_WEIGHT_TYPE: EUC_2D
NODE_COORD_SECTION
1 0 0
2 5 5
SERVICE_TIME_SECTION
1 0
2 3
DEPOT_SECTION
1
EOFA VRPLIB instance contains problem specifications and problem data.
- Specifications are key-value pairs separated by a colon. In the example above,
NAMEandEDGE_WEIGHT_TYPEare the two data specifications. - Data are explicit array-like values such as customer coordinates or service times.
Each data section should start with a header name that ends with
_SECTION, e.g.,NODE_COORD_SECTIONandSERVICE_TIME_SECTION. It is then followed by rows of values and each row must start with an index representing the depot or customer. There are two exceptions: values inEDGE_WEIGHT_SECTIONandDEPOT_SECTIONshould not start with an index.
Besides the rules outlined above, vrplib is not strict about the naming of specifications or sections.
This means that you can use vrplib to read VRPLIB instances with custom specifications like MY_SPECIFICATION: SOME_VALUE and custom section names like MY_SECTION.
Reading the above example instance returns the following dictionary:
{'name': 'Example',
'edge_weight_type': 'EUC_2D',
'node_coord': array([[0, 0], [5, 5]]),
'service_time': array([1, 3]),
'depot': array([0]),
'edge_weight': array([[0. , 7.07106781], [7.07106781, 0. ]])}The depot section specifies which location index corresponds to the depot data.
The convention is to let index 1 represent the depot.
vrplib subtracts one from the depot value to make it easier to index.
Note that the example instance did not include any explicit information about the edge weights, yet the output includes edge weights data.
This is because vrplib automatically computes the edge weights based on the instance specifications, if applicable.
In the example, the edge weight type specification and node coordinates data are used to compute the Euclidean distance.
You can set the compute_distances argument in read_instance to disable this feature.
Following the VRPLIB conventions, the edge weights are computed based on the EDGE_WEIGHT_TYPE specification, and in some cases the EDGE_WEIGHT_FORMAT specification. vrplib currently supports two categories of edge weight types:
*_2D: Euclidean distances based on the node coordinates data.EUC_2D: Double precision distances without rounding.FLOOR_2D: Round down all distances to down to an integer.EXACT_2D: Multiply the distances by 1000, round to the nearest integer.
EXPLICIT: the distance data is explicitly provided, in partial or full form. TheEDGE_WEIGHT_FORMATspecification must be present. We support the following two edge weight formats:LOWER_ROW: Lower row triangular matrix without diagonal entries.FULL_MATRIX: Explicit full matrix representation.
Lines starting with # are interpreted as comments and not parsed when reading the instance.
The VRPLIB format is an extension of the TSPLIB95 format. Additional information about the VRPLIB format can be found here.
The Solomon format was used to introduce the Solomon instances for the Vehicle Routing Problem with Time Window (VRPTW) and also the extended instance set by Homberger and Gehring. A Solomon instance looks like this:
Example
VEHICLE
NUMBER CAPACITY
50 200
CUSTOMER
CUST NO. XCOORD. YCOORD. DEMAND READY TIME DUE DATE SERVICE TIME
0 70 70 0 0 1351 0
1 33 78 20 750 809 90Reading this Solomon instance returns the following dictionary:
{'name': 'Example',
'vehicles': 50,
'capacity': 200,
'node_coord': array([[70, 70], [33, 78]]),
'demand': array([ 0, 20]),
'time_window': array([[ 0, 1351], [ 750, 809]]),
'service_time': array([ 0, 90]),
'edge_weight': array([[ 0. , 37.85498646], [37.85498646, 0. ]])}The edge weights are computed by default using the Euclidean distances.
Here's an example of a solution format:
Route #1: 1 2 3
Route #2: 4 5
Cost: 100
A solution is represented by a set of routes, where each route specifies the sequence of customers to visit.
Each route should start with "Route", followed by the route number, and followed by a colon.
The customers to be served on the route are then listed.
The solution file can also include other keywords like Cost, which will be separated on the first colon or whitespace.
The convention is that customer indices start counting from 1, but vrplib simply parses the file without strict requirements about those indices.
Reading the above example solution returns the following dictionary:
{'routes': [[1, 2, 3], [4, 5]], 'cost': 100}- The
XML100benchmark set is not listed inlist_namesand cannot be downloaded through this package. You can download these instances directly from CVRPLIB. - In the literature, some instances use rounding conventions different from what is specified in the instance. For example, X instance set proposed by Uchoa et al. (2017) assumes that the distances are rounded to the nearest integer. When you use the
vrplibpackage to read this instance, it will return non-rounded Euclidean distances because the instance specifies theEUC_2Dedge weight type which implies no rounding. To adhere to the convention used in the literature, you can manually round the distances matrix. - For large instances (>5000 customers) it's recommended to set the
compute_edge_weightsargument toFalseinread_instance.
![pre-commit-ci[bot] avatar](https://avatars.githubusercontent.com/in/68672?v=4 "pre-commit-ci[bot]")
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent