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

import AbstractController from OrdinaryDiffEq.jl #522

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

frankschae
Copy link
Member

If Controllers should subtype StochasticDiffEq.AbstractController this will allow us to implement custom adaptive schemes easily.

struct CustomController <: StochasticDiffEq.AbstractController
end

function StochasticDiffEq.stepsize_controller!(integrator::StochasticDiffEq.SDEIntegrator, controller::CustomController, alg)
    u = integrator.u
    integrator.q = max(...)
    nothing
end

function StochasticDiffEq.step_accept_controller!(integrator::StochasticDiffEq.SDEIntegrator, controller::CustomController, alg)
    integrator.dtnew = 1 / integrator.q * oneunit(integrator.dt)
    nothing
end

sol = solve(prob, EM(), dt=dt, adaptive=true, controller=CustomController())

@ChrisRackauckas
Copy link
Member

Maybe this should be implemented in OrdinaryDiffEq and then just used with any solver?

@frankschae
Copy link
Member Author

Maybe this should be implemented in OrdinaryDiffEq and then just used with any solver?

Can you elaborate? I thought that it's fine to let a user define their own controller type as a subtype of AbstractController and then dispatch on it to change the adaptive scheme. AbstractController is defined in OrdinaryDiffEq and only imported here. I don't know how to implement a generically valid integrator.q = max(...).

@ChrisRackauckas
Copy link
Member

I mean, why not implement CustomController in OrdinaryDiffEq and then document it as a feature for ODEs, SDEs, DDEs, DAEs, and SDDEs?

@frankschae
Copy link
Member Author

frankschae commented Mar 5, 2023

What would that look like? Would we only add

struct CustomController <: StochasticDiffEq.AbstractController
end

to OrdinaryDiffEq? Wouldn't that be worse than leaving the type "free"? I have in mind that users might want to do something sophisticated and it would be good, e.g., if CustomController could hold additional fields (but adding it to the docs would be great of course).

@ChrisRackauckas
Copy link
Member

Yeah, I think some documented type where a user gives some functions like that.

@frankschae
Copy link
Member Author

Isn't AbstractController basically already that type (so you can subtype it with a concrete type with its own fields and do all the fancy things you want to do)?

@ChrisRackauckas
Copy link
Member

Documenting it might be all that's necessary.

@frankschae
Copy link
Member Author

@ChrisRackauckas
Copy link
Member

That seems right.

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

Successfully merging this pull request may close these issues.

2 participants