Using mixed integer programming to assign air cargo to flights

User requests aren't always "here's a problem + the data, solve this to optimal". Here are other examples:

1. "here's the problem + data, solve it well enough within 10s" 2. "here's the problem + data, solve it well enough with a subset of the data" 3. "here's the problem + data, solve it partially, and then when near real-time updates come in, update solution to take new information into account"

1) Most of this work is a simplified copy of the papers I linked to. Special thanks to James Bookbinder and his team at University of Waterloo.

2) I'm an OR novice, and this is my first optimization project. I feel now that I can roughly model the flight assignment domain, but what the solvers do is a mystery to me, and when I read about Lagrangian relaxation and column generation, I'm lost. Fortunately I haven't needed those techniques in this project.

3) The mathematical model, when written down, looks mystifying even to me, the author, and that's unfortunate. My goal in writing this post was to reduce the mystery and explain the model in plain English (plus math notation), but in the end I'm afraid it still looks eye-glazingly complicated. Data science can be all too happy to cloak itself in mystery by writing down what are actually pretty basic equations. I don't have a good solution to this.

Most of all, I got such joy out of building the model one constraint at a time and seeing the solver follow my directions and spit out optimal solutions. I couldn't believe it worked. It was like I discovered electricity. Lastly, much credit goes to Flexport leadership for allowing me, an OR novice, to embark on this optimization project.

I didn't mean you shouldn't use the standard mathematical notation, which seems to be what you're talking about. I meant you should use it in the standard way. Don't use superscripts that are neither powers nor variables; for example, don't use U^M to mean "max weight capacity" and U^V to mean "max volume capacity". UM and UV, M and V, or even U_M and U_V would be an improvement. Don't typeset your display math with the subscripts to the right of the Σ as if it were part of a paragraph; put them underneath. Don't put extra spaces in the middle of your subscripts. If you only have two subscripts (with numeric values, not things like "M" and "V"), it's okay and probably better to make one of them a superscript, especially if you parenthesize it to reduce the chance that people will mistake it for a power. Don't leave out your variable of summation when you write Σyⱼcⱼ or, as you did in another case, write it in upper case. Don't write sets as comma-separated sequences of elements without {} around them.

Alternatively you could write the whole model down in GNU MathProg, which is more verbose but not that much, arguably more precise, and universally understood by people who work in the field in anything other than pure theory. Or Pyomo, which I've never written anything in, but assume can't be that much worse or nobody would use it. Either way it would be easier to use multi-letter names for your variables and parameters if you thought that made things clearer.

I don't think the standard mathematical notation is keeping people away from the field; students who already know basic algebra don't seem to have much trouble with the notation. Figuring out how to make reasonable MILP models or how to diagnose the problem when the solver says your model is infeasible, those seem to take a lot more work.

> Flexport uses the Medium.com platform,

Why? You want to screen people out of your recruiting process that haven't signed up for Medium accounts? Or you want to signal that you're a nontechnical company that can't figure out how to install Wordpress? There are Docker images for that now, you know.