Multiple Supply Demand in Python
Supply chain optimization example in Python
Note
This documentation is for a prior release of Kinetica. For the latest documentation, click here.
Supply chain optimization example in Python
The following is a complete example, using the Python API, of matching stores (demands) to depots/trucks (suppliers) via the /match/graph endpoint using an underlying graph created from a modified OpenStreetMap (OSM) dataset. For more information on Network Graphs & Solvers, see Network Graphs & Solvers Concepts.
The prerequisites for running the match graph example are listed below:
The native Kinetica Python API is accessible through the following means:
The Python package manager, pip, is required to install the API from PyPI.
Install the API:
|
|
Test the installation:
|
|
If Import Successful is displayed, the API has been installed as is ready for use.
In the desired directory, run the following, but be sure to replace <kinetica-version> with the name of the installed Kinetica version, e.g., v7.1:
|
|
Change directory into the newly downloaded repository:
|
|
In the root directory of the unzipped repository, install the Kinetica API:
|
|
Test the installation (Python 2.7 (or greater) is necessary for running the API example):
|
|
The example script references the dc_roads.csv
data file,
mentioned in the Prerequisites, in the current local directory, by default.
This directory can specified as a parameter when running the script.
The dc_shape dataset is a HERE dataset and is analogous to most road network datasets you could find in that it includes columns for the type of road, the average speed, the direction of the road, a WKT linestring for its geographic location, a unique ID integer for the road, and more. The graph used in the example is created with two columns from the dc_shape dataset:
You'll notice later that the shape column is also part of an inline calculation for distance as weight during graph creation using the ST_LENGTH and ST_NPOINTS geospatial functions.
This example is going to demonstrate matching supply trucks to different demand points within Washington, D.C., relying on truck sizes, road weights, and proximity to determine the best path between supply trucks and demands.
Several constants are defined at the beginning of the script:
SCHEMA -- the name of the schema in which the tables supporting the graph creation and match operations will be created
Important
The schema is created during the table setup portion of the script because the schema must exist prior to creating the tables that will later support the graph creation and match operations.
TABLE_DC -- the name of the table into which the D.C. roads dataset is loaded
TABLE_D / TABLE_S -- the names for the tables into which the datasets in this file are loaded. TABLE_D is a record of each demand's (store) ID, WKT location, size of demand, and their local supplier's ID; TABLE_S is a record of each supplier's ID, WKT location, truck ID, and truck size.
GRAPH_DC -- the D.C. roads graph
TABLE_GRAPH_DC_S1 / TABLE_GRAPH_DC_S2 -- the names for the tables into which the solutions are output
|
|
Before the supplies and demands datasets are generated, the D.C. roads dataset is loaded from a local CSV file. First, the D.C. roads table is created using the GPUdbTable interface:
|
|
Then, the CSV file is uploaded into KiFS and loaded into the table:
|
|
The demands table is also created using the GPUdbTable interface:
|
|
Note
There should not be multiple demand records for the same supplier, e.g., two separate demands of 5 and 10 for Store ID 1 should be combined for one demand of 15
Then the demands records are defined and inserted into the table. Six stores are created in various locations throughout the city with varying demands but they all use the same supplier. Note that the higher the priority number, the greater the priority (e.g., 3 is the highest priority in this example and 0 is the lowest):
|
|
Lastly, the supplies table is created using the GPUdbTable interface:
|
|
Five supplies records are defined and inserted into the table: five trucks with varying sizes are assigned to the same supplier.
|
|
One graph is used for the match graph example utilized in the script: dc_roads_graph, a graph based on the dc_roads dataset (one of the CSV files mentioned in Prerequisites).
The dc_roads_graph graph is created with the following characteristics:
|
|
The graph output to WMS:
Both the supplies and demands match identifier combinations are provided to the /match/graph endpoint so the graph server can match the supply trucks to the demand locations and with respect to priority. Using the multiple supply demand match solver results in a solution table for each unique supplier ID; in this case, one table is created: dc_roads_graph_solved.
|
|
The example script utilizes /get/records to extract the results from the solution table:
|
|
Important
The WKT route was left out of the displayed results for readability.
For each truck from the supplies table that is involved in the solution, the solution table presents the store(s) visited (by ID), how much "supply" is dropped off at each store, the route taken to the store(s) and back to the supplier, and the cost for the entire route.
Based on the results, you can see that the priority stores' demands were met first: store IDs 46, 45, and 13. Truck ID 24 made a stop at Store 46 and dropped off its entire supply. Once a truck has exhausted its supply in the solution, it is no longer used. Truck ID 25 made a stop at Store ID 46 and 11: it stopped at Store 46 to fulfill the rest of the store's demand and supplied Store 11 with the rest of its available supply. Trucks will drop off as much supply as they are able; if some supply is left on the truck after a drop-off, the truck will continue to the next most optimal drop-off location regardless of priority. Truck ID 23 made a stop at Store ID 45 to fulfill the store's entire demand and Store ID 12 to drop off the rest of its available supply. Truck ID 21 made a stop at Store ID 13 to fulfill the store's entire demand and Store ID 11 to drop off the rest of its available supply. Truck ID 22 made a stop at Store ID 12, 44, and 11 to either fulfill the store's entire demand (44) or to complete the rest of the store's demand (12, 11).
Similarly to the example above, both the supplies and demands match identifier combinations are provided to the /match/graph endpoint so the graph server can match the supply trucks to the demand locations and with respect to priority and the max trip cost. Max trip cost affects this example by preventing trucks from supplying another store if the cost to travel to that store is greater than the provided cost. Using the multiple supply demand match solver results in a solution table for each unique supplier ID; in this case, one table is created: dc_roads_graph_solved_w_max_trip.
|
|
The example script utilizes /get/records again to extract the results from the second solution table:
|
|
Important
The WKT route was left out of the displayed results for readability.
Included below is a complete example containing all the above requests, the data files, and output.
To run the complete sample, ensure that:
match_graph_dc_multi_supply_demand.py
script is in the
current directorydc_roads.csv
file is in the current directory or use the
data_dir parameter to specify the local directory containing itThen, run the following:
|
|