RobotLocomotion
Consider supporting reading/writing AMPL files from MathematicalProgram
From discussion today with @RussTedrake it would be nice to be able to share MathematicalProgram optimizations with tools outside of Drake. Reading models from (and writing them to) AMPL files would be one way of accomplishing that. There's some related work in https://github.com/JuliaOpt/AmplNLWriter.jl which uses AMPL's .nl file format for this purpose.
I just wanted to bump this again; @rahulyesantharao is trying out mixed-integer NLP for his footstep planning work, and having .nl support would be the easiest way to get Couenne working from Drake.
Writing a nonlinear constraints to .nl file requires our Constraint::Eval function to support symbolic input. Unfortunately we currently only support input of type double and Eigen::AutoDiffScalar (https://github.com/RobotLocomotion/drake/blob/master/solvers/evaluator_base.h#L42~L62). This will be a major change to add support for symbolic variables in constraint/cost.
I think it would be easier if we add a wrapper for Couenne. @jwnimmer-tri , Couenne uses EPL license. Is it compatible with Drake's license?
@rdeits . Do you think Couenne would be a good solver for your MINLP? Are you also trying out other solvers?
Ah, I see. Yeah, as far as I know Couenne should be a good choice for the problem.
I'm not sure how helpful special-casing Couenne support would be, though. It would obviously be great to have fully symbolic nonlinear constraints in MathematicalProgram, but if that's not possible then the next easiest thing is probably to use JuMP from python to call Couenne.
Hongkai, when you mean a wrapper for Couenne, do you mean a wrapper that doesn't go through MathematicalProgram?
Sorry, I mean a derived class of MathematicalProgramSolverInterface for Couenne, like GurobiSolver for Gurobi. This wrapper converts constraint/cost in drake MathematicalProgram to solver format, by calling the right API of the solver.
I see. But would that support nonlinear expressions, or just scalar/autodiff?
Fwiw, I’m definitely in favor of having couenne available as a supported solver. (If it makes sense)
@rdeits MathematicalProgram can accept nonlinear symbolic expressions as cost/constraint. And then we will need to call Couenne in our solver wrapper.
@RussTedrake I agree it makes sense to add Couenne as a supported solver, if the license works.
@hongkai-dai EPL should be fine for solver back-ends. (We already use CoinUtils and Clp under EPL terms as part of dReal.) You can grep for EPL-1 in tools/workspace/** to see such uses, as well as the manifest posted at #4045.
We could add an AMPLSolver to drake, that writes an .amp or .mod file, that is readeable by humans. And then the user passes the .amp/.mod file generated by drake to AMPL solvers, which will convert these human-readable file to a different format.
BTW, we currently support writing to SDPA format, which is commonly used for SDP.
Curious if there are any further developments on this issue, either implementing an interface for couenne, or exporting mathematical programs in standard file formats?
@cohnt unfortunately there has not been any progress on this issue yet. What data format do you want? We do support outputing MathematicalProgram to SDPA format, would that work for you?
I'm looking to export nonlinear programs, in order to feed them into global optimization solvers (including couenne, for example). I didn't think SDPA format supported such objectives and constraints.