{"action":"created","issue":{"url":"https://api.github.com/repos/scipy/scipy/issues/6326","repository_url":"https://api.github.com/repos/scipy/scipy","labels_url":"https://api.github.com/repos/scipy/scipy/issues/6326/labels{/name}","comments_url":"https://api.github.com/repos/scipy/scipy/issues/6326/comments","events_url":"https://api.github.com/repos/scipy/scipy/issues/6326/events","html_url":"https://github.com/scipy/scipy/pull/6326","id":162701941,"number":6326,"title":"[WIP] ENH: New ODE solvers","user":{"login":"nmayorov","id":7074023,"avatar_url":"https://avatars.githubusercontent.com/u/7074023?v=3","gravatar_id":"","url":"https://api.github.com/users/nmayorov","html_url":"https://github.com/nmayorov","followers_url":"https://api.github.com/users/nmayorov/followers","following_url":"https://api.github.com/users/nmayorov/following{/other_user}","gists_url":"https://api.github.com/users/nmayorov/gists{/gist_id}","starred_url":"https://api.github.com/users/nmayorov/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/nmayorov/subscriptions","organizations_url":"https://api.github.com/users/nmayorov/orgs","repos_url":"https://api.github.com/users/nmayorov/repos","events_url":"https://api.github.com/users/nmayorov/events{/privacy}","received_events_url":"https://api.github.com/users/nmayorov/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/scipy/scipy/labels/enhancement","name":"enhancement","color":"bfe5bf"},{"url":"https://api.github.com/repos/scipy/scipy/labels/needs-decision","name":"needs-decision","color":"fbca04"},{"url":"https://api.github.com/repos/scipy/scipy/labels/scipy.integrate","name":"scipy.integrate","color":"207de5"}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":28,"created_at":"2016-06-28T14:36:26Z","updated_at":"2016-08-20T22:59:48Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/scipy/scipy/pulls/6326","html_url":"https://github.com/scipy/scipy/pull/6326","diff_url":"https://github.com/scipy/scipy/pull/6326.diff","patch_url":"https://github.com/scipy/scipy/pull/6326.patch"},"body":"Hi!\r\n\r\nFirst some considerations about the current `ode` class.\r\n\r\n1. It allows to use several good quality solvers.\r\n2. It feels like a giant black box, the usability and docs are not the best. It's hard to understand if you get your setup right or not, seeing output from fortran code is awkward, etc.\r\n3. It's not clear how to efficiently compute the solution at many points (\"dense output\"). For Runge-Kutta methods (dopri5 and dop853) just calling `integrate` by small steps would be very wrong, but that's what a user would probably do (a \"proper\" way is discussed [here](http://stackoverflow.com/questions/12926393/using-adaptive-step-sizes-with-scipy-integrate-ode)) . For other solvers the situation should be better, but still it is not efficient to make small steps (but this is limitation of solvers and not on scipy side).\r\n4. No continuous solution output, i.e. which can be evaluated at any point with the same accuracy as the values computed at discrete points.\r\n5. No event detection capabilities.\r\n\r\nSo I want to provide a new monolithic implementation, which is easy to understand and use and also provides missing features 4 and 5. Yes, it will be in Python and not as fast. But the same situation is in MATLAB and people are totally fine with it, as the solvers are well designed and easy to use. In fact I was largely motivated by MATLAB suite. I realize that this is not a super clear situation, and there are pros and cons. But comparing the current state of scipy and MATLAB in ODE integration, I come to conclusion that scipy could do better.\r\n\r\nCurrently I only implemented two explicit Runge-Kutta methods (admittedly the easiest methods, but no doubt useful). And getting right implicit solvers for stiff problems will be a challenge.\r\n\r\nI prepared an example with two main features, continuous output and event detection: http://nbviewer.jupyter.org/gist/nmayorov/ca99381bb20a87762758f7dad4fc2220\r\n\r\nThe code is in preliminary stage. The current TODO list:\r\n\r\n- [x] Implement at least one implicit method for stiff problems.\r\n- [ ] Develop a benchmark suite and assess quality of the algorithms.\r\n- [ ] Refine API: add necessary parameters, rename current parameters, etc.\r\n\r\nAny feedback and suggestions are very welcome. A concrete technical question: which implicit method you believe would be the most useful (if implement only one)? The BDF (and its modifications) seems to be the most widely used, so I want to start looking into it."},"comment":{"url":"https://api.github.com/repos/scipy/scipy/issues/comments/241228926","html_url":"https://github.com/scipy/scipy/pull/6326#issuecomment-241228926","issue_url":"https://api.github.com/repos/scipy/scipy/issues/6326","id":241228926,"user":{"login":"drhagen","id":2952478,"avatar_url":"https://avatars.githubusercontent.com/u/2952478?v=3","gravatar_id":"","url":"https://api.github.com/users/drhagen","html_url":"https://github.com/drhagen","followers_url":"https://api.github.com/users/drhagen/followers","following_url":"https://api.github.com/users/drhagen/following{/other_user}","gists_url":"https://api.github.com/users/drhagen/gists{/gist_id}","starred_url":"https://api.github.com/users/drhagen/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/drhagen/subscriptions","organizations_url":"https://api.github.com/users/drhagen/orgs","repos_url":"https://api.github.com/users/drhagen/repos","events_url":"https://api.github.com/users/drhagen/events{/privacy}","received_events_url":"https://api.github.com/users/drhagen/received_events","type":"User","site_admin":false},"created_at":"2016-08-20T22:59:48Z","updated_at":"2016-08-20T22:59:48Z","body":"> I think it's a great advantage to have and use common set of options, which work the same way for all solvers. Imagine every solver will use their own parameter names, their own different definition, etc (pretty much the current situation). What's good about it?\r\n\r\nThis comes from personal experience with Matlab's ode solvers. The computational cost difference is huge. I have not tested this Python, so it may handle it better. There will be no way to get around the fact that the complete solution requires a lot more memory. I have had problems in Matlab that could not be integrated with the full solution, but I could request a few hundred discrete points.\r\n\r\n> Imagine every solver will use their own parameter names, their own different definition\r\n\r\nWell, we should certainly make the common names consistent across all the solvers that will come prepackaged with scipy. I would even think its a good idea to make the common case easy by documenting the most common options in `solve_ivp`. But without a `**options`, the uncommon case of needing to set `max_order` becomes impossible as there is no way to pass new options to new solvers.\r\n\r\n> Generally between usability and abstract design (generality, extensibility, \"purity\") we should prefer usability with interactive computing in mind (in my opinion).\r\n\r\nI agree strongly that we need a maximally usable interface. I have no doubt that 80% of the time people will use only `solve_ivp`. (Actually, they'd probably use `solve_ivp_discrete` because most people know what points they want, but that's beside the point.) But having a extensible core is how a design goes from working for 80% of users to 100% of users.\r\n\r\n> These are good points. So how about we provide only a class interface\r\n\r\nIn your design, to make the `integrate` method would you just copy `solve_ivp` into each class and then statically point the `step` call?\r\n\r\n> By the way I quickly compared your current version and this PR version in terms of time on my example problems.\r\n\r\nThis was pure Python?\r\n\r\n> I suggest we discuss here some more time. And then perhaps (and hopefully) create a separate repository to continue the coding.\r\n\r\nThat sounds good to me."}}
{"actor":{"display_login":"drhagen"}}