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

ENH: Enable custom solver #177

Merged
merged 7 commits into from Jun 18, 2018

Conversation

Projects
None yet
2 participants
@bocklund
Collaborator

bocklund commented Jun 8, 2018

  • Makes a new SolverBase class that InteriorPointOptimzer subclasses. All subclasses of SolverBase must implement a solve method.
  • solve must take a pycalphad.core.problem.Problem class and return a pycalphad.core.solver.SolverResult named tuple.
  • equilibrium takes a solver argument that takes an instance of SolverBase or a subclass, which is passed to the _solve_eq_at_conditions function.
  • Pull out instantiating solver objects from inside a while loop nested in _solve_eq_at_conditions to being instantiated either outside equilibrium or at the top level of _solve_eq_at_conditions.

The idea here is that users can

  1. Instantiate their own InteriorPointOptimizer with custom IPOPT options (with an easy interface to set them - just a dict)
  2. Create subclasses of SolverBase that use different solvers.

Can close #174

This also removes some dead code and adds/improves documentation. CompiledModel and the now unused global constants in pycalphad.core.constants are removed.

@bocklund

This comment has been minimized.

Collaborator

bocklund commented Jun 8, 2018

@richardotis made a comment in #174:

User-developed custom Solver subclasses can have any signature they want, of course, depending on what makes sense for their work.

The current method proposed here is that the solve cannot have any signature, but must take some kind of Problem instance. Instead of having any signature for a solver.solve method, users should encode any additional information options in their solver.__init__ method at instantiation time or in a custom Problem class, which is passed directly to solver.solve.

I think the configuration API for the builtin Solver should be very limited, to avoid users hard-coding solver constants for an optimization package which is subject to change in the future.

IMO we don't provide guarantees that any options will work, but I think it's within scope of pycalphad as a tool for method development to allow users to do this. We should make it easy for users (particularly developers) to tinker and possibly optimize for their use case (e.g. maybe you are developing a high-throughput simulation and want to turn down tolerance to meet performance constraints). I also hope that our test suite continues to develop into a benchmark of solver correctness that can be part of validating solvers and global minimization algorithms.

@bocklund bocklund requested a review from richardotis Jun 14, 2018

@bocklund bocklund merged commit c5c8df6 into develop Jun 18, 2018

5 checks passed

continuous-integration/appveyor/branch AppVeyor build succeeded
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details
coverage/coveralls Coverage increased (+0.003%) to 87.823%
Details

@bocklund bocklund deleted the ENH-enable-custom-solver branch Jul 17, 2018

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