Streamline Solver Selection

[phumthep]

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]

Closed with the following commits:

• e1eb3d673b6abbae9924860ce638c0b11971a6c2
• 99e1e04f725f510df141177b2265dbb709634af7