-
-
Notifications
You must be signed in to change notification settings - Fork 42
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
feat: NonlinearSolveBase
+ BracketingNonlinearSolve
+ SimpleNonlinearSolve
#458
Conversation
@time begin
using SimpleNonlinearSolve
prob_brack = IntervalNonlinearProblem{false}(
(u, p) -> u^2 - p, (0.0, 25.0), 5)
solve(prob_brack, ITP())
end
# 1.574422 seconds (1.17 M allocations: 81.038 MiB, 2.57% gc time, 6.58% compilation time)
@time begin
using BracketingNonlinearSolve
prob_brack = IntervalNonlinearProblem{false}(
(u, p) -> u^2 - p, (0.0, 25.0), 5)
solve(prob_brack, ITP())
end
# 0.504557 seconds (429.92 k allocations: 30.137 MiB, 6.16% gc time, 25.34% compilation time) |
NonlinearSolveBase
+ BracketingNonlinearSolve
+ SimpleNonlinearSolve
Should we move the DiffEqBase/solve.jl to SciMLBase? We probably should and make that a bit more generic, and then reuse it in more contexts anyways. |
You also want the diffeqbase.jl functionwrappers though. |
I think so. They don't seem to be diffeq specific.
Not sure what you are referring to |
2768ae8
to
734b2f8
Compare
Ok bracketing solvers are now done. We are still not as fast as loading julia> @time_imports using BracketingNonlinearSolve
0.2 ms ConcreteStructs
0.2 ms CommonSolve
0.8 ms ArrayInterface
0.2 ms FastClosures
0.1 ms Compat → CompatLinearAlgebraExt
┌ 0.0 ms DocStringExtensions.__init__()
92.6 ms DocStringExtensions 99.23% compilation time
10.7 ms RecipesBase
0.6 ms StaticArraysCore
0.3 ms ArrayInterfaceStaticArraysCoreExt
0.5 ms RuntimeGeneratedFunctions
┌ 0.0 ms InverseFunctions.__init__()
1.0 ms InverseFunctions
0.2 ms ConstructionBase
0.1 ms CompositionsBase
0.1 ms CompositionsBaseInverseFunctionsExt
0.2 ms ConstructionBaseLinearAlgebraExt
┌ 0.0 ms Accessors.__init__()
11.7 ms Accessors
2.5 ms SymbolicIndexingInterface
0.1 ms InverseFunctionsDatesExt
0.2 ms AccessorsDatesExt
0.2 ms Adapt
0.3 ms GPUArraysCore
0.1 ms ArrayInterfaceGPUArraysCoreExt
18.2 ms RecursiveArrayTools
0.3 ms SciMLStructures
5.7 ms FunctionWrappers
0.2 ms FunctionWrappersWrappers
0.2 ms EnumX
2.2 ms ADTypes
81.4 ms MLStyle
5.7 ms Expronicon
0.2 ms Reexport
8.2 ms SciMLOperators
0.2 ms SciMLOperatorsStaticArraysCoreExt
┌ 0.0 ms SciMLBase.__init__()
69.2 ms SciMLBase
1.5 ms NonlinearSolveBase
6.3 ms BracketingNonlinearSolve |
Also I am not sure how to do the SimpleNonlinearSolve move without breaking older versions. If we change the path to SimpleNonlinearSolve to this repo in the registry, then older versions don't exist in the git history right? IIUC it would still exist in the pkg server, but do we want to do that 😅 |
51ea0df
to
c238914
Compare
07cc36c
to
1d75d7f
Compare
abb6366
to
5485267
Compare
5ebe24c
to
30487a1
Compare
40c4df9
to
173dd01
Compare
30487a1
to
12cebe7
Compare
947fb85
to
b2d061a
Compare
12cebe7
to
7fb5062
Compare
dcf2c7f
to
d6167c9
Compare
280b8d4
to
f6041af
Compare
b49e42d
to
f5a06cb
Compare
f3a7ccc
to
f36989a
Compare
This PR is now in a mergeable state finally! Was able to keep breaking changes to a minimal - Use of termination conditions from `DiffEqBase` has been removed. Use the termination
conditions from `NonlinearSolveBase` instead.
- If no autodiff is provided, we now choose from a list of autodiffs based on the packages
loaded. For example, if `Enzyme` is loaded, we will default to that (for reverse mode).
In general, we don't guarantee the exact autodiff selected if `autodiff` is not provided
(i.e. `nothing`). |
da057e7
to
7f57584
Compare
7f57584
to
8f5ecf3
Compare
I will merge and get registrations going. We are not releasing the new NonlinearSolve right now anyways till #481 is finished. |
First step in cutting down on load times. This is mostly independent of #456
DiffEqBase
toNonlinearSolveBase
in theSimple
packages.SimpleNonlinearSolve
into (SimpleNonlinearSolve
has longer load times thanLux
which sounds extremely wrong)SimpleNonlinearSolve
-- retains its current functionality but drops DiffEqBase and loads NonlinearSolveBase and BracketingNonlinearSolveBracketingNonlinearSolve
NonlinearSolveBase
have?DifferentiationInterface -- SparseArrays Reduce load time? JuliaDiff/DifferentiationInterface.jl#416FiniteDiff -- again SparseArraysMaybeInplace -- again SparseArrays (fixed by refactor: move SparseArrays into an extension MaybeInplace.jl#11)DiffEqBase loads NonlinearSolveBase and addsget_concrete_problem
There's a bunch of stuff in NonlinearSolve that can eventually be moved into base, but that is something to do later on.
Tasklist
LiFukushimaLineSearch
LineSearch.jl#11