It’s been awhile since I’ve had an update, but rest assured that there’s been lots of activity. To give some back story, OptimoJoe’s primary business is creating custom codes to solve a variety of engineering and scientific problems. Often, we use Optizelle on these contracts, which works well for our customers since Optizelle’s BSD license means that our clients are not obligated to disclose their custom enhancements. We also benefit from this exercise since it provides a very clear metric of what works and what doesn’t work in terms of algorithms and software design.
As an example of a lesson learned, I spent a couple of months earlier in the year visiting Norway, where I worked as a postdoc earlier in my career. While I was out there, I made a short trip to Oslo to work with Simon Funke at Simula on integrating Optizelle into dolfin-adjoint. By the way, Simon just won the 2015 Wilkinson Prize for Numerical Software, which is a huge deal, so congratulations to him, Patrick Farrel, and David Ham! Also, Simula has some really amazing research and expertise on applying continuum mechanics based models to medical applications, so if anyone is looking for assistance in that area, they’re definitely worth a look. Anyway, part of integrating Optizelle into dolfin-adjoint involved getting the interior point algorithm to work properly on some test problems. Basically, Optizelle requires a discrete adjoint for the inequality constraints that’s consistent with the inner product, which can sometimes be a pain to get just right with PDE constrained optimization problems. In order to diagnose our problem, I rapidly added new diagnostics to Optizelle’s code, which required me to add new variables to the optimization state. Unfortunately, every time I added a new variable, I needed to add code in over a dozen different places. Simply, there is code for serialization, parameter checking, reading parameters from file, C++ interfaces, Python interfaces, MATLAB/Octave interfaces, the user manual, and so on and so forth. And, as it turns out, adding code in all of these different places is error prone. As such, the lesson from that trip is that I need to add in a much better meta-programming facility to the Optizelle code base where all of this code is automatically generated from a file that contains all of the information in one place. As such, I’ve been working the last several months working out these details and writing this code. With any luck, we’ll have some results and code for this new design over the next few months.
While I was out at Simula, I also gave a presentation on different HPC (high-performance computing) considerations that optimization codes should account for. Certainly, the points that I bring up in the presentation are not exhaustive, but represent some of the lessons that I learned over the years working on different projects. Of note, I discuss
-
Why parallelism in optimization codes needs to be defined by the user
-
What interfaces optimization codes need to implement in order for the user to effectively define this parallelism
-
How PDE constrained optimization problems have implicit bounds on parameters due to numerical considerations such as von Neumann stability and CFL conditions
-
How handling NaNs properly allows us to deal with the above stability conditions
-
How inequality constraints help us better deal with the above stability conditions
-
Why a checkpoint/restart mechanism is important for a robust code
Many of these lessons helped form the foundation for Optizelle.
In any case, let me reiterate that we’re hard at work improving our core software as well as on releasing a few new packages. Stay tuned for future updates!