{"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":91,"created_at":"2016-10-31T11:36:24Z","updated_at":"2016-11-09T18:19:42Z","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/259485436","html_url":"https://github.com/JuliaDiffEq/Roadmap/issues/5#issuecomment-259485436","issue_url":"https://api.github.com/repos/JuliaDiffEq/Roadmap/issues/5","id":259485436,"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-09T18:19:42Z","updated_at":"2016-11-09T18:19:42Z","body":">I keep thinking of an ODEProblem as a representation of a Cauchy problem, and that's why I'm against including technical or algorithm related stuff in ODEProblem. I agree that t1 could be put in there, as it makes sense mathematically (we often consider Cauchy problems on a finite time interval, even the direction of time matters for their solvability) it makes little sense to me to add the intermediate steps there. Still, some problems might call for something like these intermediate steps, especially the discontinuities you mentioned. In that case interpreting tspan as a set of \"special\" point for the equation could be the way to go. But if we know that these are special points from the mathematical point of view, we shouldn't mix them with the ordinary endpoints [t0,t1] and we should give them a separate type field instead (tdiscontinuous or maybe even a separate problem type ODEDiscontinuousProblem?).\r\n\r\nThat is a good point. And a `tsteps` argument makes sense. I find this very reasonable. I'll wait on @mauro3's opinion. Also, should `save_timeseries` be renamed to `save_every_tstep`?\r\n\r\nWhere were we on the DAE problems? I am pretty sure we at least need `DAEProblem` (name pending) for the implicit ODE functions since those require a `du0`, and so at that point we have a whole new problem. However, for mass matrices, there were two threads: separate problem type vs optional mass matrix and a boolean value type as a type parameter. I was for the separate problem type. Where was everyone else?"}}
{"actor":{"display_login":"ChrisRackauckas"}}