If you suddenly started seeing an error message from an OrdinaryDiffEq.jl (DifferentialEquations.jl) solver like:
Detected non-constant types in an out-of-place ODE solve, i.e. for
`du = f(u,p,t)` we see `typeof(du) !== typeof(u)`. This is not
supported by OrdinaryDiffEq.jl's solvers. Please either make `f`
type-constant (i.e. typeof(du) === typeof(u)) or use the mutating
in-place form `f(du,u,p,t)` (which is type-constant by construction).
Note that one common case for this is when computing with GPUs, using
`Float32` for `u0` and `Float64` for `tspan`. To correct this, ensure
that the element type of `tspan` matches the preferred compute type,
for example `ODEProblem(f,0f0,(0f0,1f0))` for `Float32`-based time.
typeof(u/t) = Vector{ComplexF64}
typeof(du) = Vector{Float64}
The reason is Informative error if the type from the first call is non-constant by ChrisRackauckas · Pull Request #1685 · SciML/OrdinaryDiffEq.jl · GitHub and OrdinaryDiffEq.jl v6.16. For the most part, this new error check finds cases that would otherwise error deeper in the code (and thus this should be a much more clear error message).
However, there were a few cases which previously worked and now throw this error. All of those cases were found to be subtle performance bugs. For example, there were cases where u0 was CuArray{Float32} but tspan was Float64. This would technically work because internally it would upconvert to Float64, and then downconvert to u0’s type when trying to write the output after the Runge-Kutta steps. But, clearly, you don’t want to run Float64 on GPUs and so this found a real performance bug. Another case was found with an ODE function that would always return real even though its initial condition was Complex: something the user probably wants to fix to be a real valued ODE solve.
So because of this behavior, we know that there are some codes now throwing this error but we are considering it a non-breaking change as the codes which break seem to only be bugs and not really supported behavior. If you have any behavior that seems to require this, please share a simplified description of how this arises. We can create a Preferences option to opt-out of this error message, but for now it seems like every case shouldn’t opt-out and instead improve their code.