SLSQP does not strictly follow problem bounds

[Tarnarmour]

I am running into a lot of issues because the SLSQP algorithm does not strictly follow bounds. In multiple cases this has resulted in the optimization terminating with values outside of bounds even when the initial values were feasible and in bounds. From what I've been able to find elsewhere this may be a known issue. If so is there a hack around this? And if not this seems to me like a pretty significant issue.

[ewu63]

This is a known issue with the original version of SLSQP, which is the version included in pyOptSparse. Several other packages that provide SLSQP has patched this themselves (e.g. scipy and I suspect slsqp as well).

There are no plans for pyOptSparse to fix this at the moment, since most of us do not use SLSQP. In the longer term, I personally would prefer to move the SLSQP source code to an external dependency such as the package by jacobwilliams, such that we don't have to duplicate any bugfix efforts. We would instead manage the Python interface as we currently do with IPOPT. Alternatively to improve the installation process, we could vendor one of those better-maintained SLSQP codes and ship it as part of pyOptSparse, assuming that the license allows for it. What do you think about such approaches?

[Tarnarmour]

This makes total sense to me, and I agree that there's no point in duplicating work when there are existing patches available. I suppose my problem now is just getting more familiar with other options; with my current experience, getting versions of SLSQP in other languages to work is going to be difficult and I quite like the pyOptSparse interface. I would totally support the idea of external dependencies under the current interface.

I hope this isn't too off topic but what alternatives do you or others currently prefer? I suppose I still feel very unaware of options right now.

[ewu63]

As far as I'm aware, here are the alternative implementations of SLSQP out in the wild:

• Scipy is probably the most widely used, and has a number of bug fixes (see here for a history)
• Stand-alone SLSQP that has been modified to use modern Fortran. It's a standalone Fortran module that does not have a Python interface, and the existing f2py wrapper will need to be heavily modified to be compatible
• NLopt which similar to Scipy has also modified the original source code. However, they've also converted it to C.

Out of all these options, the easiest for us is probably to just ship the Scipy version of SLSQP directly (license permitting), and periodically check and fetch any updates from them. That allows us to keep the Python wrapper and most of the interface intact while offering any bug fixes provided by the scipy team. There are also probably benefits of the other implementations, but there would be more work to include them:

• for the standalone module, we have to create the f2py wrapper from scratch
• for NLopt, they offer a Python wrapper but we still have to interface with it

and in either case, I think it's probably easier to ship Fortran code that get compiled, rather than tell people that SLSQP is now an external dependency and they have to install it manually themselves.

A while ago, @marcomangano had looked into performance comparisons between Scipy and the version in pyOptSparse, and if I remember correctly, the results were inconclusive. However, if Scipy's version has critical bug fixes, I think it makes sense to port them over.

Thoughts?

[Tarnarmour]

Take this with a hefty pinch of salt, since I don't know the internals of any of these algorithms, but in the specific project that I'm working on I've found Scipy to run faster but generally have much poorer convergence. Again, that could just be setup issues on my part.

Personally I think just wrapping the Scipy version would be fine and worth it if there is real evidence of useful bug fixes. If I have time I'll try to do a little testing on my own to see specifically if the strict bounds issue has been fixed there. Thanks for all the help, by the way.

[ewu63]

Yeah I wouldn't be surprised if the other two projects I mentioned run better than Scipy, since they seem to be better maintained. It would be interesting to for example run the cutest test suite on each and benchmark them. However, doing that probably requires a bit of work and I doubt anyone in the MDO Lab is interested in that work at the moment, especially since none of us really use SLSQP.

[A-CGray]

@Tarnarmour I presume you're using SLSQP because it is freely available rather than anything specific about the algorithm, if so have you tried installing IPOPT or ParOpt? Both are available for free and can match the performance of SNOPT on some problems. I would recommend trying IPOPT first as the setting for ParOpt are a lot more complicated and not so well documented.

[ewu63]

Superseded by #303.