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

rethink MIP callbacks (from scratch) #170

Open
chriscoey opened this Issue Jun 9, 2017 · 3 comments

Comments

Projects
None yet
3 participants
@chriscoey
Member

chriscoey commented Jun 9, 2017

to be discussed at the meetup

see #16 for discussion of branching and incumbent callbacks

@ccoffrin

This comment has been minimized.

ccoffrin commented Jun 15, 2017

An attempt collect solver callback documentation.

Significant Callback Support

Minor/Unclear Callback Support

@ccoffrin

This comment has been minimized.

ccoffrin commented Jun 15, 2017

Notes from meetup discussion,

  • we will not attempt to generalize over callbacks, there is too much diversity in the solvers
  • we should try to design a clean callback architecture pattern for users working at the MPB level
  • Cplex.jl's dependency on JuMP for implementing callbacks is undesirable
  • a good test of the any proposed architecture is an approach that can work for SCIP.jl, Cplex.jl, and Guorbi.jl
  • lack of clarity about what is going on at the JuMP level is undesirable for example,
    • what is the cb object?
    • what is the semantics of @lazyconstraint?
@mlubin

This comment has been minimized.

Member

mlubin commented Jun 29, 2017

More discussions with @chriscoey: don't port over callbacks to the new API until we have a first pass of the JuMP implementation. At that point we can reevaluate if we should port them over or design a new API.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment