Currently, the linear solvers (KLU, SparseLU, etc.) are using default solver settings. These default settings may not be optimal for each simulation. Therefore, it would be reasonable to have a configuration-object that can be passed to each linear solver (which inherit from DirectLinearSolver) , from which each solver can read the required configuration. Configuration options could be:
Ordering, such as
AMD
COLAMD
specialised orderings for partial refactorization, if applicable
Scaling
Partial refactorization method (Refactorization Restart or Factorization Path), if applicable
If a option is not available in the solver, it could make sense to log this circumstance as information to the user and default to a certain option. This would require the DirectLinearSolver-classes would have access to spdlog, which is not the case now.
Currently, the linear solvers (
KLU,SparseLU, etc.) are using default solver settings. These default settings may not be optimal for each simulation. Therefore, it would be reasonable to have a configuration-object that can be passed to each linear solver (which inherit fromDirectLinearSolver) , from which each solver can read the required configuration. Configuration options could be:If a option is not available in the solver, it could make sense to log this circumstance as information to the user and default to a certain option. This would require the
DirectLinearSolver-classes would have access to spdlog, which is not the case now.