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

ENH: Enable custom solver #177

merged 7 commits into from
Jun 18, 2018

ENH: Enable custom solver #177

merged 7 commits into from
Jun 18, 2018


Copy link

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

Copy link
Collaborator Author

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 merged commit c5c8df6 into develop Jun 18, 2018
@bocklund bocklund deleted the ENH-enable-custom-solver branch July 17, 2018 20:07
bocklund added a commit to bocklund/pycalphad that referenced this pull request Aug 17, 2021
…ndmember` (pycalphad#177)

The overall functionality of `plot_parameters` is now contained in `plot_interaction` and `plot_endmember` which are more clear about the form. `plot_parameters` is deprecated and set to be removed in ESPEI 0.9. The design of these now plots one property at a time on given axes. Both functions expose options to customize how matplotlib plots predicted values and observed values. Closes pycalphad#60.

The new API is superior because there's more fine control over which properties are plotted, regardless of the existing data and whether `require_data` is passed or not.

To recover the full functionality of `plot_parameters` where multiple plots are in the same figure, users should use matplotlib subplots.

Bar charts comparing data to parameters are no longer possible because they are an uncommon plot type and not usually seen in publications. They are not much more informative than a line plot.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet

Successfully merging this pull request may close these issues.

changing constants in equilibrium calculation without reinstaling
2 participants