search

SciML / Roadmap

A place for discussing the future of differential equations in Julia
0 stars 1 forks source link

Add IVPTestSuite.jl? #4

Closed mauro3 closed 7 years ago

mauro3 commented 7 years ago

Should IVPTestSuite.jl be added to JuliaDiffEq? Or is it only a subset of the testing included in DifferentialEquations.jl?

mauro3 commented 7 years ago

The subset in question would probably be https://github.com/JuliaDiffEq/DiffEqDevTools.jl

ChrisRackauckas commented 7 years ago

From the README, it looks like the tools are a strict subset of DiffEqDevTools except for the :chemakzo and :hires test cases. I am not going to look at the code though because I see that it's GPL licensed and don't want to "get infected": having the GPL license is something I see as a big issue. The methods which are tested are also a strict subset except for DASSL.jl, (but this will change shortly by wrapping it into AlgebraicDiffEq).

There is a major difference though:

  1. DiffEqDevTools work directly on the DEProblem objects of DifferentialEquations.jl and thus it only works on algorithms wrapped into a component solver. Since DifferentialEquations.jl wraps any algorithm in Julia that is worth using (or at least, has on the list to wrap it like DASSL.jl and PetsC TS), this strategy works, but it's very different than calling them directly.
  2. DiffEqDevTools has many many more dependencies. This is rather unfortunate and stems from the fact that it uses the solve method on each problem type, so it requires each solver component. This is rather unfortunate and I don't know a way around this. Since this package is mostly for testing and not really user-facing that's not a huge issue, though it's still not good.
  3. DiffEqDevTools already covers other domains like SDEs and PDEs. The tools also will also directly work for DDEs when I (or whoever else) get around to that (before the end of next month?). I'm not quite sure how you'd be doing that in IVPTestSuite without special casing things (but then again, I have forbid myself from looking at the code due to the GPL license so it's hard for me to really know about the design).

Together, I think you could make a case for including it, but not necessarily the strongest case. I think it's much easier to just add more devdocs for DiffEqDevTools so I'm not going to put effort into it (and there's tons of examples for how to use it, see any of the tests in any DiffEq component solver since every algorithm I include has at least a convergence test), but if you see a place for IVPTestSuite.jl then there's no reason to not include it (other than the GPL-ness of the code). I prefer the route of "make every solver available in one package, and so testing/benchmarking multiple packages is trivial", but in some sense that is a heavy-handed approach.

mauro3 commented 7 years ago

Fair enough. (To note about the license, it's only GPL because it copied some code from Octave. I should have noted that all the code is MIT except one file GPL and the combo is thus GPL).