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

Improvements to IDAKLU solver #2217

Closed
6 of 13 tasks
martinjrobins opened this issue Aug 5, 2022 · 5 comments
Closed
6 of 13 tasks

Improvements to IDAKLU solver #2217

martinjrobins opened this issue Aug 5, 2022 · 5 comments
Assignees

Comments

@martinjrobins
Copy link
Contributor

martinjrobins commented Aug 5, 2022

Description

Many things still left to do on the IDAKLU solver, here is the copied list from #1863

  • we're allocating memory for return vectors in the solve, this could be done in solver setup
  • we initialise ida_mem and everything every time, could do this once when solver is created, or only on the 1st solve etc
  • create an options dict to pass to the solver, e.g. option to print solver stats, don't/do use jacobian
  • add option to use iterative solvers
  • add option to use other linear solvers in ida
  • add option to use dense jacobian
  • add option to use banded solvers
  • benchmarks for all of the above solver options
  • investigate if we need to densify the rhs_algebraic casadi evaluation, could it return a sparse vector?
  • investigate if constructing a new casadi function for the residual (rather than doing it manually in c++) is faster
  • investigate if constructing a new casadi function for the sensitivity calculations (rather than doing it manually in c++) is faster
  • we calculate consistent initial conditions at the start of the idklu solve, so we might not need to do it in the BaseSolver setup
  • Sundials v6 has a slightly different API using a context object, need to update code to support both this and version 5

Motivation

  1. The IDAKLU solver can be faster than casadi, so we want to expose more functionality from sundials
  2. Make the solver more efficient

Possible Implementation

No response

Additional context

No response

@martinjrobins martinjrobins self-assigned this Aug 5, 2022
@martinjrobins
Copy link
Contributor Author

"we're allocating memory for return vectors in the solve, this could be done in solver setup"
Need to think more on this one, if we re-use this memory for subsequent solves will overwrite solution returned to user :(

@valentinsulzer
Copy link
Member

There are still scenarios where that's ok - e.g. parameter estimation - so it could be an optional feature?

martinjrobins added a commit that referenced this issue Aug 10, 2022
martinjrobins added a commit that referenced this issue Aug 16, 2022
martinjrobins added a commit that referenced this issue Aug 26, 2022
martinjrobins added a commit that referenced this issue Aug 26, 2022
martinjrobins added a commit that referenced this issue Aug 26, 2022
martinjrobins added a commit that referenced this issue Sep 8, 2022
@valentinsulzer
Copy link
Member

Been reading a bit more about Sundials. Super excited to see these changes when they're ready! For pack modeling it could be extremely useful

@valentinsulzer
Copy link
Member

Are we now in a place where we can make the IDAKLU solver the default if it's installed (and fall back to casadi otherwise)?
Would be interesting to test/benchmark

@martinjrobins
Copy link
Contributor Author

I think so, we just have to first add the idaklu solver to the benchmarks so we've got some evidence for making it the default, I've opened #2599 for this

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

No branches or pull requests

3 participants