-
Notifications
You must be signed in to change notification settings - Fork 5
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
Introduce DifferentiationInterface.jl
for Jacobian computation
#2134
Comments
Yes, nice writeup. I assume this would need SciML/OrdinaryDiffEq.jl#2567? Which luckily seems quite close. |
Ah, I wasn't aware of that PR. We don't necessarily have to wait for that to investigate, as we can pass our own Jacobian function (which @SvenWesterbeek knows all about ^^) using the DI API for in-place Jacobians directly |
Happy to share my findings if you ever need it @SouthEndMusic :) |
Just popping by to say that I'll be happy to help you integrate DI into your package. As far as preallocation is concerned, are you aware of |
Quite a while back we put a lot of effort in getting
ForwardDiff.jl
to work as an automatic differentiation (AD) method for computing Jacobians for implicit solvers (see e.g. #550). Then after a while we decided to make finite difference the standard differentiation method again (see #1832).This is a pity, because AD should in general be more accurate and AD is very well supported in the SciML ecosystem. The newest efforts there are for supporting DifferentiationInterface.jl, which should make it as easy to switch between different AD backends as it is now already to switch between different solver algorithms.
One of the things that makes AD support complex is (pre)allocating the right caches for intermediate results.
DifferentiationInterface.jl
attempts to automate this but that is not always possible when computations are in-place (as ours are). We currently usePreallocationTools
for this, which is somewhat intrusive in our codebase, quite magical to the uninitiated and is quite fiddly to get to work well together with continuous control types, i.e.ContinuousControl
andPidControl
. Therefore it would be nice of we could use an AD backend that does not require this 'manual' caching, for which Enzyme.jl is a promising candidate that is gaining popularity in the SciML community.One potential hurdle with
Enzyme.jl
is that it might make our current executable significantly bigger, but that is all the more reason to work towards static compilation 🙂The text was updated successfully, but these errors were encountered: