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

ODEProblem doesn't accept symbolic maps for parameters #922

Closed
Lucalino opened this issue Jan 4, 2023 · 8 comments
Closed

ODEProblem doesn't accept symbolic maps for parameters #922

Lucalino opened this issue Jan 4, 2023 · 8 comments

Comments

@Lucalino
Copy link

Lucalino commented Jan 4, 2023

Solving an ODEProblem with parameters provided in the form of a dictionary Dict{Symbol, Any} results in the following error message:
ArgumentError: This problem does not support symbolic maps with 'remake', i.e. it does not have a symbolic origin. Please use 'remake' with the 'p' keyword argument as a vector of values, paying attention to parameter order.

Here's a simple example of what I'd like to do:

function lorenz!(du,u,p,t)
    @unpack a, b, c = p
    du[1] = a*(u[2]-u[1])
    du[2] = u[1]*(b-u[3]) - u[2]
    du[3] = u[1]*u[2] - c*u[3]
end


u0 = [1.0;0.0;0.0]
p = Dict{Symbol, Any}(
    :a => 10.0,
    :b => 28.0,
    :c => 8/3,
)
tspan = (0.0,100.0)
prob = ODEProblem(lorenz!,u0,tspan,p)
sol = solve(prob,Tsit5())

If I am not mistaken, the above code worked in an earlier DifferentialEquations.jl version. Is there a way to get it work again?
Thank you for your time and effort developing/improving this package!

@vboussange
Copy link

Before the fix, using NamedTuples provides a workaround:

# original dict
p = Dict{Symbol, Any}(
    :a => 10.0,
    :b => 28.0,
    :c => 8/3,
)
# conversion into a named tuple
p = NamedTuple([pair for pair in p])

# solve
prob = ODEProblem(lorenz!,u0,tspan,p)
sol = solve(prob,Tsit5())

@ChrisRackauckas
Copy link
Member

Yeah the NamedTuple is good. We just need to add a keyword argument to disable the interpretation as a function map, or only do so when a f.sys is defined.

@jqbond
Copy link

jqbond commented Mar 14, 2023

I ran into this after updating DifferentialEquations.jl; the version below using ODEFunction also seems to retain the "old" behavior where p can be a dictionary. I only noticed this because I had an old script that was using ODEFunction to pass a Jacobian, and it was not throwing this error with p formatted as a dictionary, but a new script using just ODEProblem(function_name, u0, tspan, p) was throwing the argument. I haven't really kicked the tires on this, but it seems to work. I'm sure @ChrisRackauckas could say why. Please let me know if there is a keyword argument that would allow you to pass parameters as a dictionary since I've set up quite a few scripts this way in the past.

function lorenz!(du,u,p,t)
    @unpack a, b, c = p
    du[1] = a*(u[2]-u[1])
    du[2] = u[1]*(b-u[3]) - u[2]
    du[3] = u[1]*u[2] - c*u[3]
end

u0 = [1.0;0.0;0.0]
p = Dict{Symbol, Any}(
    :a => 10.0,
    :b => 28.0,
    :c => 8/3,
)
tspan = (0.0,100.0)
f    = ODEFunction(lorenz!)
prob = ODEProblem(f,u0,tspan,p)
#prob = ODEProblem(lorenz!, u0, tspan, p)
sol = solve(prob,Tsit5())

@freddie090
Copy link

freddie090 commented May 18, 2023

Related to this, I have a model where I adaptively turn parameters on and off when conditions are reached during solving. Because named tuples are immutable, this won't work with the named tuples approach. Also, simply using the order of parameters with p[i] can be frustrating if you're constantly changing the model/have many parameters to keep track of etc.
Is there any way the parameters in p could be named and mutable?

@vboussange
Copy link

@freddie090 you should use ComponentArrays

@ChrisRackauckas
Copy link
Member

There is now a keyword argument to disable or bypass the symbolic form.

@goerz
Copy link

goerz commented Feb 4, 2025

What is that keyword argument, and how/where should it be used? The current error message mentions interpret_symbolicmap = false, but I've tried to use that both in the instantiation of the ODEProblem, and in OrdinaryDiffEq.init, and it doesn't seem to have any effect

@ChrisRackauckas
Copy link
Member

That should be it,, can you share an MWE?

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

No branches or pull requests

6 participants