MathProgBase wrapper

[mlubin]

Here's my attempt at a MathProgBase wrapper for AMPL.jl.

The ampl_ipopt.jl script calls Ipopt using it's MathProgBase interface. Seems to work on rosenbr.nl. Obviously not too practically useful because Ipopt has its own ASL interface, but it's a proof of concept.

There are a couple of places where I wasn't sure how to implement the methods; these are indicated with comments.

The only modifications I needed to make to the core was returning the Jacobian and Hessian in sparse triplet form. The sparse function in Julia deletes structural zeros, which is problematic for detecting the sparsity pattern. I'd say this format is a bit simpler, and the user can easily call sparse if desired. If you'd prefer to keep the original functionality, I'll just need an alternative method to access the triplet form.

I also added some editorializing to the README, suggesting that solvers should be written using the MathProgBase interface instead of being tied to AMPL directly. This is just my opinion, but this policy would be a great step in the direction of interoperability between solvers and modeling interfaces in Julia. If you have a different view, we can certainly discuss the wording.

CC @IainNZ @joehuchette @tkelman

[IainNZ]

My brain isn't functioning at 100% - this allows you to model an optimization problem in Julia through MathProgBase (and thus JuMP) and the run it through ampl.jl to get an NL file?

[mlubin]

It's the other direction. You can write a solver in Julia, taking the MPB interface as input, and users can call it from AMPL.

[IainNZ]

Oooooh. Wow, yes, that makes sense. Very cool.

[mlubin]

@dpo, any comments on this?

[dpo]

@mlubin Sorry I've been caught up with other stuff. Thanks for all this! I don't mind implementing methods that return sparse matrices in coordinate format. I'll still have convenience functions that return Julia sparse matrices though.

I'm wondering if the best place for the MPB interface is here (as opposed to your MPB repository). If a user wants to use IPOPT, it seems they'll have to install a substantial amount of stuff from JuMP. And if they require AMPL access, it's just a small additional package. But what about a user who just requires AMPL access? It seems they now have to also install MPB, etc.?!

Another point is that the AMPL API isn't likely to change much (if at all), whereas the MPB interface could (I suppose?)

[mlubin]

No worries, thanks for taking a look at this.

I'm wondering if the best place for the MPB interface is here (as opposed to your MPB repository). If a user wants to use IPOPT, it seems they'll have to install a substantial amount of stuff from JuMP. And if they require AMPL access, it's just a small additional package. But what about a user who just requires AMPL access? It seems they now have to also install MPB, etc.?!

MPB is just a small pure-Julia library (<500 lines) that doesn't include any implementations or binary dependencies. By design, there's no dependency on JuMP if you were to write a solver using the MPB interface. Eventually when this repo becomes a proper Julia package (which I'm assuming is your intent?), MPB could be an optional dependency if you prefer. An alternative is to split this code off into a separate package (like GLPK and GLPKMathProgInterface).

Another point is that the AMPL API isn't likely to change much (if at all), whereas the MPB interface could (I suppose?)

That's certainly true, but if you're writing a solver in Julia, you should already be expecting syntax and API changes in the language itself, at least before a Julia 1.0 release. I would say that any potential changes in the MPB interface would be smaller in magnitude than some upcoming breaking changes in Julia, for example, returning views versus copies when taking an array slice.

[dpo]

Sorry for the delay. I just committed new methods jac_coord and hess_coord to return sparse matrices in coordinate format. Based on your arguments, I'm thinking the best is probably to host the MPB/AMPL interface in a separate repo. Does that work?

Yes, the plan is to make this module a proper Julia package. Shouldn't be difficult.

[dpo]

Ok, ampl.jl should now be a friendly Julia package.

[mlubin]

Cool, yes, I can move this code into a separate repo. Now that this is a proper package, I think it would be a good addition to JuliaOpt if you're interested in moving under the organization. Practically, this would improve the discoverability of the package, and we (the JuliaOpt team) would help out with setting up the binary dependencies for a seamless install across platforms.

[dpo]

That would be great indeed. You'll probably be able to enlighten me on something: currently, ampl.jl relies on users installing the ASL with Homebrew. I know Julia packages can install Homebrew bottles, but is there a way to avoid having two separate ASL libs (one from Julia/Homebrew, and one from the user's Homebrew)? So far, that's had me stay away from binary dependencies.

[tkelman]

@dpo if a user installs their own ASL manually via homebrew/science, BinDeps should be able to see it and won't need to go through Homebrew.jl to download a bottle.

[dpo]

Then, that's a good idea! Thanks @tkelman.

[tkelman]

@dpo do you know if ASL is using a real license yet? I'm setting up cross-compiled binaries of the COIN-OR stack on the OpenSUSE build service, I'm at the point where I'd like to do ASL too, which would make this package painlessly usable on Windows as well. But I think I'd have trouble getting it accepted if it doesn't have a recognized license. I don't see ASL in any Linux distributions either, maybe for this same reason?

[tkelman]

Scratch that, nevermind, I just wasn't looking at the source carefully. It's older-style MIT, but definitely a normal license. I'm experimenting with the new cmake version of ASL here https://github.com/ampl/mp hoping the netlib pieces will still be equivalent. Saves me the trouble of having to figure out downloading the source code separately from the build harness, the way it's done in Ipopt.

[vitaut]

@tkelman the code in https://github.com/ampl/mp/tree/master/src/asl/solvers is actually more up to date than the one on Netlib: http://www.netlib.org/ampl/, because the Netlib update service is no longer functional. AMPL/MP also includes the C++ API used by new solver connections (IBM/ILOG CPLEX & CP Optimizers, Gecode, JaCoP & LocalSolver).

[mlubin]

This PR will be made into a separate package. Closing for now, with discussion continuing in #6.

[mlubin]

FYI I've moved this code to https://github.com/mlubin/AMPLMathProgInterface.jl.