{"action":"created","issue":{"url":"https://api.github.com/repos/JuliaDiffEq/Roadmap/issues/5","repository_url":"https://api.github.com/repos/JuliaDiffEq/Roadmap","labels_url":"https://api.github.com/repos/JuliaDiffEq/Roadmap/issues/5/labels{/name}","comments_url":"https://api.github.com/repos/JuliaDiffEq/Roadmap/issues/5/comments","events_url":"https://api.github.com/repos/JuliaDiffEq/Roadmap/issues/5/events","html_url":"https://github.com/JuliaDiffEq/Roadmap/issues/5","id":186262672,"number":5,"title":"ODE/DAE solver interface","user":{"login":"mauro3","id":4098145,"avatar_url":"https://avatars.githubusercontent.com/u/4098145?v=3","gravatar_id":"","url":"https://api.github.com/users/mauro3","html_url":"https://github.com/mauro3","followers_url":"https://api.github.com/users/mauro3/followers","following_url":"https://api.github.com/users/mauro3/following{/other_user}","gists_url":"https://api.github.com/users/mauro3/gists{/gist_id}","starred_url":"https://api.github.com/users/mauro3/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mauro3/subscriptions","organizations_url":"https://api.github.com/users/mauro3/orgs","repos_url":"https://api.github.com/users/mauro3/repos","events_url":"https://api.github.com/users/mauro3/events{/privacy}","received_events_url":"https://api.github.com/users/mauro3/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":111,"created_at":"2016-10-31T11:36:24Z","updated_at":"2016-11-11T16:25:08Z","closed_at":null,"body":"I think it would be great if all the ODE/DAE solvers could be called through the same interface.  This would essentially mirror the approach of https://github.com/JuliaOpt/MathProgBase.jl .  Would it be worth trying to hammer out this interface in this road-map issue?\r\n\r\nEdit: By \"same interface\" I don't mean that ODE and DAE solvers have the same interface.  But that all ODE solvers are wrapped to conform to the same interface (similarly all DAE, and maybe all IMEX, etc).  So, Sundials.jl, ODE.jl, etc. would then depend on `ODEProgBase` (or probably `DiffEqBase`) and extend some `solve` function there, taking as input some problem specification type.  Likewise all higher level Diff-Eq stuff (currently DifferentialEquations.jl and IVPTestSuite.jl) would program against this interface.\r\n\r\n### TODO\r\nSpecify:\r\n- [x] `solve` signature: `solve(p::Problem, ::Type{Alg}; kwargs...)`\r\n- [ ] `Problem` types\r\n- [ ] `Solution` types\r\n- [ ] default options\r\n- [ ] callback options"},"comment":{"url":"https://api.github.com/repos/JuliaDiffEq/Roadmap/issues/comments/259994920","html_url":"https://github.com/JuliaDiffEq/Roadmap/issues/5#issuecomment-259994920","issue_url":"https://api.github.com/repos/JuliaDiffEq/Roadmap/issues/5","id":259994920,"user":{"login":"ChrisRackauckas","id":1814174,"avatar_url":"https://avatars.githubusercontent.com/u/1814174?v=3","gravatar_id":"","url":"https://api.github.com/users/ChrisRackauckas","html_url":"https://github.com/ChrisRackauckas","followers_url":"https://api.github.com/users/ChrisRackauckas/followers","following_url":"https://api.github.com/users/ChrisRackauckas/following{/other_user}","gists_url":"https://api.github.com/users/ChrisRackauckas/gists{/gist_id}","starred_url":"https://api.github.com/users/ChrisRackauckas/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ChrisRackauckas/subscriptions","organizations_url":"https://api.github.com/users/ChrisRackauckas/orgs","repos_url":"https://api.github.com/users/ChrisRackauckas/repos","events_url":"https://api.github.com/users/ChrisRackauckas/events{/privacy}","received_events_url":"https://api.github.com/users/ChrisRackauckas/received_events","type":"User","site_admin":false},"created_at":"2016-11-11T16:25:08Z","updated_at":"2016-11-11T16:25:08Z","body":"One last thing, I the comprehensions on the solution will not work well anyways. \r\n\r\n```julia\r\n[(...) for s in sol]\r\n``` \r\n\r\nreturns the solution with `tslocation` mutated to match the state. This is the only way that I know of to make the animations on the iterator interface still use the plot recipe (otherwise we'd have to special case all of the plotting, and that seemed like a huge problem to solve with an easier solution: just use the plot recipe with a `tslocation` in the solution!). We would need a good solution for this in order to drop the \"iterator for animation interface\", because otherwise we get a Plots dependency which doesn't play nice (due to conditional deps, you've probably read about this everywhere already).\r\n\r\nMeanwhile,\r\n\r\n```julia\r\n[@show (t,u) for t in sol.t for u in sol.u]\r\n```\r\nalways works not matter how you want to change it around."}}
{"actor":{"display_login":"ChrisRackauckas"}}