In my previous post, I looked at how slack variables were used to determine the maximum cost value of a node on a route, and how that value could be assigned as a “cost” for the entire route. The program, vrp_node_max.py. was developed by Mizux and is really clever. However, as I mentioned in my previous post, the final note in the original forum thread from Guy was a note that the approach did not seem to work in practice. With this post, I want to explore what that means and how to fix it.

A few weeks ago while working on a project I came across a very interesting program in the OR-Tools code base. The origin of the code started from a question from Guy on the OR-Tools forum. When the question was originally posted last summer, I didn’t have the opportunity to dig into the proposed result, but now I do, and I discovered it is a very interesting (ab)use of the slack dimension. Since I haven’t written anything here in ages, it seemed like a good idea to write up a blog post on the code and my understanding of how it works.

Recently a question was asked on the OR Tools forum about how to convert a single-day TSP problem into a multi-day TSP problem. The original poster was thorough, and cross posted to Stack Overflow and posted his original code as a gist on GitHub. The problem is interesting in that it takes a away from an idealized lab problem toward integrating real-world constraints. So I responded to the question with my solution, and decided to write it up properly here.

A lot of stuff in the ClojureScript/React world is documented through implication, as in “In a similar way you can do X, Y, and Z just as you would in a React project without much difficulty”.

My last post on this blog (it’s been a while, apparently) documented how I set up Traefik to front my Elixir and ClojureScript Docker containers. In that post I said that I didn’t yet know how to expose two ports from a container.

I figured out how to set up the Traefik Edge Router to front my Elixir and ClojureScript Docker containers. My setup is a bit strange, and I couldn’t find a clear example in the extensive Traefik docs.

Continuing the theme of writing up my work on optimizing street sweeping routes for Glendale, California, in this post I’m going to talk about how I made an animation to visualize the solutions generated by Google’s OR-Tools.

My last post went into a lot of detail on setting things up to solve edge covering problems. Despite the torrent of words I threw at the topic, I wanted to highlight the step of extracting map data from OpenStreetMap for a city.

We recently submitted a proposal to optimize street sweeping and garbage collection routes for the city of Glendale, California. This blog post covers some things we learned about setting up the problem using open source data, tools, and libraries.

I was working through an example CP-SAT program on sports team scheduling, and I found a bit of AddBoolOr logic that I didn’t understand. So I wrote up a short program to explore what was going on.

We went a couple of times to Lava Lava Lounge for dinner.

Another day, another coffee on the balcony, that’s for sure.

Once again we are vacationing in Kauai, on the eastern shore near the mouth of the Wailua river..

A series of questions on the Google OR Tools mailing list recently led me to question what was really going on with the use of disjunctions. The original poster was kind enough to share his original code with me, but it was in C#. So I took the time to convert the code to python and test out various things. The result surprised me a bit, but I think I understand better how disjunctions work. This post will first present the original problem, then my solution, and then finally explore the interesting issues that came up while using disjunctions.

For many applications of Google’s OR Tools routing library, I find a counting dimension to be quite useful. I’ve talked about it before, but this post focused just on the counting dimension.

Keeping with my pattern of posts based on OR Tools GitHub issues, (issue #968) asked how to model having multiple alternatives for pickup locations and dropoff locations.

A question was posed recently on the Google OR Tools GitHub issues (issue #922) that asked whether it was possible to set up FIFO or LIFO constraints. I’d never done that before, but it seemed straightforward to implement. There were a few wrinkles though, so I thought I’d write them up for my future self.

Generating random pickup and delivery pairs has been a pain point for me in the past. The problem comes with generating reasonable destination time windows. In my latest cycle of coding up a test environment for pickup and delivery problems with time windows (PDPTW), I had an insight that both makes generating random deliveries easier, and also improves the actual solution process of the PDPTW problem.

We’ve recently been doing a lot of work with Google’s OR Tools. One of our clients discovered a surprising result while setting disjunctions. As expected, with no disjunctions, all nodes are required. But if you set just one disjunction, most nodes are dropped. We didn’t have a good answer for what was going on, so I decided to explore the situation in this post.

Grace came home last weekend for her fall break, and we had some great discussions about the state of the world. On the drive to our favorite place to eat the girls started talking about the recent IPCC report on keeping the world at or below a 1.5°C rise in temperature from pre-industrial levels.

Google’s OR Tools is incredibly useful, but can be tricky to use. I subscribe to the mailing list to keep up on other users’ questions and solutions, and usually I just read and learn. But yesterday a question popped up on the OR-Tools mailing list that I could answer: how to force some node to occur before another node.

This is the first post on our new blog. Over the past two weeks, I (James) have re-done our website twice. First I migrated from a custom node.js site to Jekyll, and then from Jekyll to Hugo.