Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider supporting reading/writing AMPL files from MathematicalProgram #7635

Open
rdeits opened this issue Dec 18, 2017 · 14 comments
Open

Consider supporting reading/writing AMPL files from MathematicalProgram #7635

rdeits opened this issue Dec 18, 2017 · 14 comments
Assignees
Labels
component: mathematical program Formulating and solving mathematical programs; our autodiff and symbolic libraries priority: backlog type: feature request

Comments

@rdeits
Copy link
Contributor

rdeits commented Dec 18, 2017

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.

@hongkai-dai hongkai-dai self-assigned this Dec 18, 2017
@hongkai-dai
Copy link
Contributor

This is a great idea, I will work on it.

@rdeits
Copy link
Contributor Author

rdeits commented May 4, 2018

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.

@hongkai-dai
Copy link
Contributor

hongkai-dai commented May 5, 2018

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?

@rdeits
Copy link
Contributor Author

rdeits commented May 5, 2018

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?

@hongkai-dai
Copy link
Contributor

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.

@rdeits
Copy link
Contributor Author

rdeits commented May 5, 2018

I see. But would that support nonlinear expressions, or just scalar/autodiff?

@RussTedrake
Copy link
Contributor

Fwiw, I’m definitely in favor of having couenne available as a supported solver. (If it makes sense)

@hongkai-dai
Copy link
Contributor

@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.

@jwnimmer-tri
Copy link
Collaborator

@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.

@hongkai-dai
Copy link
Contributor

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.

@jwnimmer-tri jwnimmer-tri added the component: mathematical program Formulating and solving mathematical programs; our autodiff and symbolic libraries label May 14, 2020
@hongkai-dai
Copy link
Contributor

BTW, we currently support writing to SDPA format, which is commonly used for SDP.

@cohnt
Copy link
Contributor

cohnt commented Jun 23, 2023

Curious if there are any further developments on this issue, either implementing an interface for couenne, or exporting mathematical programs in standard file formats?

@hongkai-dai
Copy link
Contributor

@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?

@cohnt
Copy link
Contributor

cohnt commented Jun 25, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component: mathematical program Formulating and solving mathematical programs; our autodiff and symbolic libraries priority: backlog type: feature request
Projects
None yet
Development

No branches or pull requests

5 participants