Bridging Python and Matlab: Passing callbacks and optimization

This blog post is about a bridge I created that allows you to pass callbacks to Python functions directly to Matlab code without having to resort to things like sockets or COM.

Background

Designing our UAVs involves a number of different codes that interact & must be coordinated to solve what is essentially a Multidisciplinary Design Optimization (MDO) problem.  One of those codes is written in Python and involves a constrained optimization problem of the following kind:

Find the minimum of a problem specified by

xbbeqlb, and ub are vectors, A and Aeq are matrices, c(x) and ceq(x) are functions that return vectors, and f(x) is a function that returns a scalar. f(x), c(x), and ceq(x) can be nonlinear functions.

In our case we have 10 variables (x has length 10), 28 nonlinear constraint functions c(x), 4 nonlinear equality constraint functions ceq(x) and box constraints on most variables.  The objective function f(x) and all constraint functions are pure python functions.

Thus to optimize f(x) you need an optimizer that can handle python functions, and for that there is the excellent openopt library.  This is what I did and after trying out the different NLP solvers I settled on the scipy_slsqp solver for most runs as it seemed to consistently give the best results.

However, as the optimization problem was tweaked and as we did more runs, we did run into cases where it would not solve and the aeronautical engineers I work with were not always happy with its robustness.  Also nobody had ever worked with the openopt library but everybody knew and trusted the various Matlab solvers.  Besides, us being part of the Computational Engineering Design Group, a number of powerful in-house Matlab solvers had been developed and were available to me.  Thus, the least I could do was to try to use those and see if that improved anything.

Python-Matlab bridge

So I started searching the web for tools / libraries that allowed me to bridge python/Matlab, specifically tools that supported passing callbacks between the two languages.  A promising project seemed mlabwrap but while it was great for evaluating Matlab expressions,  it does (at the time of writing) not support callbacks.

In the end I decided to see if I could scratch my own itch.  I really did not want to deal with sockets or any kind of network protocol and I also wanted the solution to be crossplatform, so no COM.  Since both Python and Matlab have well documented interfaces with C/C++ code, that seemed to be the way to go.

So I sat down with the ctypes & mex documentation and with a little help from Mathworks support was able to cobble together a simple example using fminsearch.  By the way, I had never done any Python – C work before, but ctypes is awesome and a joy to use.  The little trick to make it all work is that you just have to treat the function handle as an integer (it’s just a memory address after all).  Then all you are really doing is passing an integer around which is straightforward.

With fminsearch working the goal was to extend to fmincon since that would give us all the basic functionality needed.  This took a bit of debugging and deciphering Matlab crash dumps but I finally got it working.  The final flow of events looks like this:

You start off with writing a matlab file that wraps the optimizer you are interested in (in this case fmincon) and exposes its signature.  This m file forwards all function handle arguments to a mex file which converts the integer to a function pointer and calls it.  This is how we get the callback to a C function.  A simple bridge library is then needed which is loaded by ctypes and converts the arguments into something the Matlab shared library file understands.

From my initial tests I see it is finding the same optima as scipy_slsqp was using openopt. Now I just need to do more extensive testing to see if performance is any more robust. After that I can start looking into the other solvers provided by Matlabs optimization toolboxes as well as our own solvers.

Source code

All the code is available on github.  I hope it is useful to somebody and I’d be very happy to receive patches or improvements.  I guess this may even be of use to the mlabwrap / openopt projects.

–Dirk

“Click here” to design and build your UAV

This blog post summarizes the work I have been doing the past 8 months or so on an automated design system for (civillian) UAVs.  Ive been meaning to do this post for a long time but wanted the tools to be in a beta quality state before writing about them.  In good software engineering tradition there have been a few hiccups and detours along the way but Im happy to say beta stage has been reached.

I will go over the vision behind the system, its architecture, and the various tools I have used to put it together.  For the impatient, this is the idea: we need a system that allows us to rapidly go through this process:

Agile UAV design if you want to call it that. Tools I will talk about include PythonNumpy, RabbitMQ, Redis, Flask, Django, Bootstrap,  Knockout.jsVagrant and how they link up with application specific codes such as Ansys Fluent, SolidWorks, Vanguard and Anylogic.

This post is an extension of the talk I gave at PyConUK 2011 a couple of months ago and is also what I will cover in my upcoming talk at Imperial College and at the upcoming AIAA conference in Honolulu in April 2012.

Continue reading

Solving Boggle with Python

I attended my first Python Dojo in London last night and have to say it was great fun.  As I’ve said before these kinds of events are great to get to know people and learn something new.

The challenge settled on for last night was to solve a Boggle puzzle. For those not familiar with the game, the idea is that you get an n-by-n grid of letters and you have to form as many words as you can by ‘snaking’ through the grid.  Every grid cell may only be used once for a word.  For example, this is how you would form the word MURALS, starting from M:

Everybody got about an hour to hack on a solution after which each team presented their code to the rest.  It was interesting to see the diversity of style and solution. There was a team that used 5 or 6 classes in their solution with extra facilities for caching, ours was more straightforward & procedural, while another did the proper thing and used a Trie.

Since our code did not quite work yet I finished it on the train home and then took some time this morning to clean it up.  For kicks I also used python’s multiprocessing module to have a version that would solve large grids in paralllel.

I pushed the code to github and, while nothing fancy or super optimized, it should do the job.  As always, patches & improvements are welcome 🙂

Props to @ntoll and @tjguk for organizing the event and hopefully I can make the next one as well.

–Dirk

Pycel: Compiling Excel spreadsheets to Python and making pretty pictures

Background

As described in my previous post, my job is to assemble a software suite that is used by aerospace engineers to design civillian UAVs.  Our main use case being search and rescue.

Every aircraft design starts its life in a concept tool where the configuration choice (V-tail, canard, flying wing, …) is made and where the principal geometrical parameters (wing area, CoG, tail volume, …)  are decided.  This then allows the calculation of the approximate weight and performance of the aircraft (e.g., maximum speed, range, endurance, …).

While this concept stage is only a rough approximation it already involves (in our case) some 250 variables which are interlinked in a complex web of equations.  These sizing equations capture a great deal of knowledge about the physics of flying an aircraft as well as empirical relationships drawn from historical & experimental data.  Solving these equations is really a Multidisciplinary Design Optimization (MDO) problem, a whole field of research in its own right.

After working with the Pacelab Suite for a year we have (for various reasons) switched to spreadsheets for implementing & experimenting with the sizing equations.   This brings great flexibility for the designer but makes things more tricky to parallelize & optimize for me.  For example, I cant just throw Excel on the 8000+ core linux cluster we have here.  Also, while the inbuilt solver plugin is easy and quick for solving small scale systems.  As our equation system got more complex the process just breaks down.

It was also clear that our sizing complexity had outgrown the spreadsheet UI and had become hard to understand for a newcomer.

Early experiments

Being a programmer I feel more at home manipulating code than manipulating spreadsheets.   Early on I had already experimented with visualizing the sizing logic by customizing and extending the Trace addin.  This resulted in images like this:

With some more graphviz magic you could add some structure by grouping related parameters:

And trace the impact of a particular parameter:

However, I soon ran into limitations of the static graphviz model and VBA (the language Trace is written in) is not the most happy place to be (to put it politely).

Python to the rescue

This work then lay dormant as I was sidetracked by other stuff.  However, with Pacelab being abandoned and the spreadsheet itch still being there I could not resist having a go at rewriting my own excel visualization library and throwing in some compilation for good measure.  The goal being to:

  • Allow better visualization and exploration of the sizing equations, to understand how variables influence each other
  • Compile the spreadsheet into code that can be manipulated, transformed and executed independently from excel.

There are already a number of commercial tools for compiling spreadsheets but I did not find an open source library which did what I needed.  And anyways, I did not want to look too hard since it would be something fun to do myself.  Why python? Its the language I was using at the time and one I particularly enjoy.

Piecing things together

A core problem in making all of this work is tokenizing an excel formula properly. Luckily this had already been solved and after a small patch to the python port that was working. Throw in shunting yard, the conversion to an AST, and I was ready to emit code.  For example:

Formula:  =3 + 4 * 2 / ( 1 - 5 ) ^ 2 ^ 3
RPN:  3|4|2|*|1|5|-|2|^|3|^|/|+
Python code:  3+((4*2)/(((1-5)**2)**3))

or

Formula:  =If(SUM(A1:A5) > 0, sin(0.3), ln(2.5))
RPN:  A1:A5|SUM|0|>|0.3|sin|2.5|ln|If
Python code:  sin(0.3) if xsum(eval_range("A1:A5"))>0 else xlog(2.5)

As you can see this means mapping excel functions/operators onto python ones and adding python equivalents where necessary.

Dependency tracking

Besides the issue of function mapping there is the issue of dependency tracking when updating cells.  So if A1 contains the formula B1 + 5 then you need to be aware of this dependency and update A1 whenever B1 changes.  For this I used a graph as the base data model as it is most intuitive.  Thanks to pythons networkx this was very easy to do.

The final result is a small python library that:

  • takes an excel spreadsheet & one or more seed cells
  • follows the dependency graph, starting from the seeds
  • generates a graph where each node is a cell or range and contains the python equivalent of the excel formula

This graph can then be serialized to disk and run independently of Excel (e.g., on linux).  Caching and lazy evaluation ensures the calculation and update process is relatively fast.  I have tested extensively with a spreadsheet with multiple sheets and over 1000 formulae.  Full calculation times are around 50ms which is plenty fast for our application.  Also, I can now run multiple instances in parallel, something that was virtually impossible to do by orchestrating Excel via Pthon over COM (yes I know there is solution from Microsoft for running Excel on a cluster but I did just not want to go there).

Pretty pictures

This means its now time for an intermezzo with some pretty pictures, courtesy of Gephi. The node color is determined by the worksheet the node comes from and the size of a node is determined by how many cells it depends on.  Ever think an aircraft design problem could look pretty? 🙂

Using some layout algorithms you can start pulling things apart:

And look at the macroscopic structure:

Or zoom in for the microscopic structure:

Here the colors represent which variable group the node belongs to. Stripping out things further you can look at one particular variable, for example the wing area, and see how it influences others:

Finally, optimization

Ok, so I could now serialize an excel spreadsheet to a python graph.  However, the ultimate goal is to build an aircraft that can actually fly, or in aero speak, it is balanced (lift equals the weight, center of gravity is in the right place, etc.)  This still involves an optimization process which now had to be done in Python.  For this I added an extra layer on top of the compilation process using OpenOpt.  After some bugfixing and testing I am happy to report that, without doing anything fancy, it solves in 98% of the time and takes 30 seconds to 1 minute to solve.  Compared with the original 65% and 10 minutes.

As a sanity check I then did some parameter sweeps to generate surface plots such as these:

Roughly this plot tells you that as you increase the payload weight and the importance of a low landing speed, your dry weight (the weight without fuel) goes up.  Which is exactly as you would expect (ignore the ridge at the bottom left).

Where is the code?

My employer has been kind enough to let me release the code which is now available on github!  An example is included and the readme lists the pro’s and con’s of the current functionality.  May the patches roll in 🙂

Thoughts and Future work

So far this has been an interesting little side project and been very useful in the wider design system.  Recall from my previous post that this is just one small piece in the puzzle.  In the wider system this is linked up with CFD simulations, costing codes, an operational model and what have you.  One disadvantage of spreadsheets, though, is that designers tend to use large tables to interpolate out equations instead of writing a few lines of code.  This can add large numbers of nodes/edges to the graph, thus increasing the visual complexity, without adding much to the true problem complexity.

I think there is potential to explore this topic further, but this would really need an application specific layer on top of a graph-only tool like gephi.  However, it does not look like this is where my priorities will lay, but maybe it will inspire somebody else 🙂

There is a good chance I will be revisiting this type of work when we look at visualizing design rationale data and how it evolves during the aircraft design process.  But that is a separate topic for a separate post 🙂

Thoughts, comments, suggestions, constructive criticism, patches? Dont be shy!

–Dirk