writeproblem for nonlinear

[tkelman]

Will need AbstractNLPEvaluator in order to access objective and constraint expressions. It's of course possible to implement a writer as solve(m), but also fairly awkward when writing and solving are separate steps. Could come up with a contrived set of "solver" options for whether or not to actually run the solver, and which sub-solver and other options are selected, but this would really not be the most elegant interface.

Also probably want a version of loadnonlinearproblem! that can populate an AbstractMathProgModel and an AbstractNLPEvaluator from a filename, to load optimization problems that were created and saved in other formats.

[mlubin]

How are you planning on implementing the derivative callbacks from a serialized file?

[tkelman]

That would be more in the realm of what you might use something like AMPL.jl for, right?

I could relatively easily load from a serialized osil file and create a JuMP model from it. But where would that be implemented? A "solver" package shouldn't need to depend on the larger modeling language package, right?

[mlubin]

Take a look at my defunct PR for an MPB wrapper for AMPL.jl: JuliaSmoothOptimizers/AmplNLReader.jl#4.

I'm not sure if "write but don't solve" is a common enough use case that we couldn't just have a special "solver" option for it as you mentioned. We could also implement a writeOSiL method from JuMP as a nicer interface for the same thing.

I could relatively easily load from a serialized osil file and create a JuMP model from it. But where would that be implemented? A "solver" package shouldn't need to depend on the larger modeling language package, right?

Worst case we make separate OSiLReader and OSiLWriter packages?

[tkelman]

Take a look at my defunct PR for an MPB wrapper for AMPL.jl: JuliaSmoothOptimizers/AmplNLReader.jl#4.

The only thing that's capable of is read-and-immediately-solve. I'm thinking more advanced, read into a format that MPB-compatible modeling layers can understand and implement translation from (so inputting a problem directly through expressions, most likely). That would allow you to read a problem from a nl or osil file (or sif at some point?), modify parameters or change something from JuMP (or Convex.jl at some point?), then do anything else you would want to do with the JuMP model.

Write but don't solve is also more useful than you think - remote solution via NEOS or some non-Julia-managed cluster, or for transferring saved problem formulations to embedded systems that can't run Julia code, assembling sets of test problems, etc. "The Julia script that generates the problem" is really not sufficient for any of these purposes, particularly if model generation involves some expensive IO, data collection, transformation, etc.

Both managing things through fake solver options, and splitting out into 3 packages for largely overlapping functionality, are really messy solutions to these problems that I'd rather avoid. MathProgBase is a decent narrow waist for getting modeling languages to talk to solvers, and some aspects of MIP solvers talking back, but otherwise it's one-way right now. Making it truly bidirectional opens up a lot more possibilities.

[mlubin]

This discussion is stale. See https://github.com/JuliaOpt/AmplNLWriter.jl