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

Streamline Solver Selection #15

Open
phumthep opened this issue Jul 12, 2024 · 0 comments
Open

Streamline Solver Selection #15

phumthep opened this issue Jul 12, 2024 · 0 comments
Assignees
Labels
enhancement New feature or request help wanted Extra attention is needed question Further information is requested

Comments

@phumthep
Copy link
Collaborator

Issue Description

Currently, the Simulation class handles solver selection and instantiation directly, leading to some code duplication and potential for errors. The goal of this enhancement is to improve flexibility, maintainability, and testability by introducing a factory pattern to abstract solver interactions.

Current Workflow

Simulation class tightly coupled to Gurobipy The current implementation heavily relies on Gurobipy, making it difficult to switch or add new solvers seamlessly. There is also a temporary file creation: writing and deleting an MPS file for HiGHs introduces unnecessary overhead and potential I/O issues.

Proposed Solution

The idea is to adopt the Factory pattern.

  • Create an abstract base class or interface (SolverInterface) that defines the common methods for interacting with solvers (e.g., add_variables, add_constraints, optimize). This probably is a lot of work.
  • Implement concrete classes (e.g., GurobiSolver, HighsSolver) that inherit from SolverInterface and provide the specific implementation for each solver
  • Create a factory class (SolverFactory) responsible for instantiating the appropriate solver object based on configuration or user input

Benefits of Factory Pattern

  • Centralized solver management makes it easier to add, remove, or modify solver implementations without affecting the core simulation logic
  • Eliminates conditional logic and temporary file handling within the Simulation class
  • Simplifies unit testing of the Simulation class
  • Adheres to the open/closed principle by allowing the addition of new solvers without modifying existing code.

Additional Considerations:

  • Not sure if this is the best way. Any ideas?
@phumthep phumthep added enhancement New feature or request help wanted Extra attention is needed question Further information is requested labels Jul 12, 2024
@phumthep phumthep self-assigned this Jul 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed question Further information is requested
Projects
None yet
Development

No branches or pull requests

1 participant