ChrisRackauckas
commented
1 week ago I think there may be a regression in compilation times for very stiff ODE functions with StaticArrays types
But the MWE is non-stiff?
Open cadojo opened 1 week ago
ChrisRackauckas
commented
1 week ago I think there may be a regression in compilation times for very stiff ODE functions with StaticArrays types
But the MWE is non-stiff?
ChrisRackauckas
commented
1 week ago And it took less than 3 seconds?
2.841622 seconds (15.83 M allocations: 969.635 MiB, 5.62% gc time, 99.99% compilation time)
cadojo
commented
1 week ago And it took less than 3 seconds?
When the ODEProblem has a state vector type of Vector (the default in the example), it compiles quickly (a couple of seconds). When you uncomment the MVector line, though, it takes tens of minutes to compile (around one hour in CI). I've replaced the MRE with a modified version that shows both input types. Could you try running that again?
But the MWE is non-stiff?
Ah, sorry about that. I misunderstood the definition of stiff. The reason I tried to characterize the dynamics at all (e.g. stiff) is I think I have seen some equations which compile quickly with MVector state vector types, and so I thought there was an "ODE sensitivity" check somewhere in the stack that triggered extra compilation for some problems and not others. I thought that would be information that might help flag the issue, but I think I'm mistaken.
ChrisRackauckas
commented
1 week ago When the ODEProblem has a state vector type of Vector (the default in the example), it compiles quickly (a couple of seconds). When you uncomment the MVector line, though, it takes tens of minutes to compile (around one hour in CI). I've replaced the MRE with a modified version that shows both input types. Could you try running that again?
I did that. It compiled just fine with MVector.
cadojo
commented
1 week ago I did that. It compiled just fine with MVector.
Hm, not for me. I added some Pkg.activate lines at the top just to make sure. It never finishes running for me, and I am assuming it's stuck on compilation because I've solved these problems with the same initial conditions before.
The linked issue was reported by another user too. I solved the issue by changing all code examples from MVector to Vector.
Sorry this is an odd case. Maybe it's an architecture issue? I'm on an M1 MacBook Air. The output from me running the MRE is below; it just hangs on the solve call with the MVector input.
Activating project at `/var/folders/vc/rjqggbq92mj_strb625fy2g40000gn/T`
Updating registry at `~/.julia/registries/General.toml`
Resolving package versions...
No Changes to `/private/var/folders/vc/rjqggbq92mj_strb625fy2g40000gn/T/Project.toml`
No Changes to `/private/var/folders/vc/rjqggbq92mj_strb625fy2g40000gn/T/Manifest.toml`
Resolving package versions...
No Changes to `/private/var/folders/vc/rjqggbq92mj_strb625fy2g40000gn/T/Project.toml`
No Changes to `/private/var/folders/vc/rjqggbq92mj_strb625fy2g40000gn/T/Manifest.toml`
[ Info: Solving Problem with Vector Input
┌ Warning: This should compile in a couple of seconds.
└ @ Main ~/Projects/Astrodynamics/GeneralAstrodynamics.jl/check.jl:37
2.234717 seconds (21.28 M allocations: 1.192 GiB, 9.82% gc time, 99.99% compilation time)
[ Info: Solving Problem with MVector State
┌ Error: This will take very long to compile!
└ @ Main ~/Projects/Astrodynamics/GeneralAstrodynamics.jl/check.jl:42I think I found the issue for me. Changing the algorithm from Vern9 to Tsit5 solves the issue for me. I have a new MRE below which tries out the two algorithms. For me, the final solve call hangs.
ChrisRackauckas
commented
1 week ago Still only took:
2.199512 seconds (12.69 M allocations: 758.995 MiB, 8.69% gc time, 99.99% compilation time)
How did you install Julia, using juliaup? What version?
cadojo
commented
1 week ago Strange. Yeah, I installed it through juliaup. Version 1.11.1.
topolarity
commented
1 week ago I can reproduce this on my x86_64-linux machine.
It looks like an issue with a subtyping query in the broadcast exploding: https://github.com/JuliaLang/julia/issues/56606
topolarity
commented
5 days ago Good news! Testing with https://github.com/JuliaLang/julia/pull/56640 seems to resolve the problem 👍 (huge thanks to @N5N3):
[ Info: Solving Problem with Vector Input
┌ Warning: This should compile in a couple of seconds.
└ @ Main ~/repos/julia/mwe.jl:36
4.455485 seconds (20.61 M allocations: 1.135 GiB, 16.08% gc time, 100.00% compilation time)
[ Info: Solving Problem with MVector State
┌ Error: This will take very long to compile!
└ @ Main ~/repos/julia/mwe.jl:41
4.371111 seconds (18.77 M allocations: 902.214 MiB, 15.37% gc time, 100.00% compilation time)
Describe the bug 🐞
I think there may be a regression in compilation times
solve(::ODEProblem)withStaticArraystypes. I have a minimum reproducible example below. First aVectortype is used, and that compiles quickly. Next anMVectortype is used, and thesolvecall takes approximately one hour to complete; I haven't confirmed this locally (the call hangs, and I wait a few minutes before killing the process), but in CI the call does finish, but it takes around one hour.I don't have any specific package versions for when this worked, but I was able to run
solvewithMVectortypes in the last year. Here is one example from 5 months ago; the full job completed in 13 minutes.Expected behavior
The
solvecall withMVectorshould compile and evaluate within an order of magnitude ofVector.Minimal Reproducible Example 👇
Environment (please complete the following information):
using Pkg; Pkg.status()using Pkg; Pkg.status(; mode = PKGMODE_MANIFEST)versioninfo()