Differential Equations Package

[digxx]

Hey all,

I dont quite get the essence of this package. Looking through the examples I found for a 2d poisson type problem:

Example problem with solution: ``u(x,y)= sin(2π.*x).*cos(2π.*y)/(8π*π)``" function poissonProblemExample_wave() f(x) = sin(2π.*x[:,1]).*cos(2π.*x[:,2]) sol(x) = sin(2π.*x[:,1]).*cos(2π.*x[:,2])/(8π*π) Du(x) = [cos(2*pi.*x[:,1]).*cos(2*pi.*x[:,2])./(4*pi) -sin(2π.*x[:,1]).*sin(2π.*x[:,2])./(4π)] return(PoissonProblem(f,sol,Du)) end prob = poissonProblemExample_wave()

Now: Why do I need to specify the solution to the solver??? Isn't that what I'm looking for. Also to me it seems that I can not specify an arbitrary differential equation. Can I only solve heat/poisson type equations or can I specify my own?

[Stefan Karpinski]

Are you talking about this package https://github.com/ChrisRackauckas/DifferentialEquations.jl ?

[digxx]

Yes. I am. 

[Christoph Ortner]

this package implements just a couple of specific problems, as required by its author. It is a nice package BUT

it is far too specific to be called DifferentialEquations.jl. (in my view anyhow) For me this is a problem with the package eco-system. Such specialised packages should maybe not be in METADATA, or at least the naming should be better controlled.

[Christoph Ortner]

just to emphasize this is purely personal opinion.

[Chris Rackauckas]

Hey,

  This is the author here. Let me address a few things. Giving the solution is optional for any problem type. So you can just declare a PoissonProblem(f). If you give it a solution, then it calculates errors and a bunch of extra things. I'll clear up that part of the tutorial. You can also specify any ODE or SDE as shown in the tutorial. You cannot specify arbitrary PDEs: this is a limitation of mathematics. Each PDE requires a different discretization, but if you discretize the PDE to ODEs/SODEs, then you can use those in any ODE/SDE solver.  It's even worse than that because just because a scheme is "good" for one type of PDE doesn't mean it's "good" for another, and so a solver has to be developed for each type of PDE. I am currently adding support for more types of PDEs. What PDEs are you looking to solve?

[Chris Rackauckas]

It also solves ODEs and SDEs, and I will be adding DDEs (delay equations) and differential algebraic equations ASAP. It implements more solvers for ODEs (with more tests) than ODE.jl, and implements more modern solvers for SDEs than SDE.jl. It also implements solvers for common (S)PDEs, and I am incrementally building more solvers to try and get something at least as general as MATLAB's PDE toolbox. Any package that I know of has to use different solvers for different types of PDEs, and I started with more basic ones first. Lastly, it implements a bunch of helper functionality that is associated with solving differential equations, like plotting solutions and running Monte Carlo experiments in parallel (for stochastic equations). I couldn't think of a better name than "this thing solves differential equations". I really don't see how that makes the package "specialized".

I agree that it still has a documentation issue. Taking in the solution should be a keyword argument there (it is for all the other problem types, that's just an error from an older version). Note that I am still not at v0.1: I want better documentation, a few more problem types / equations, and I want to clean up some areas to make it easier for other contributors to get started adding to the package, 

[Eric Forgy]

Sounds awesome Chris +1

[jonatha...@alumni.epfl.ch]

Your package is about computing numerical solutions of differential equations. Differential equations are something a bit more general, for example a package for bifurcation analysis could also want to call itself "DifferentialEquations". I don't really have a better name... NSolveDiffEqus ? That said I don't think you really need to rename it.

[Gabriel Gellner]

I think the name makes a tonne of sense given the scope, and fits in the line with many standard packages: Calculus, Optim, Distributions, etc.

There is no reason that if a great Bifurcation suite grows it couldn't be part of DifferentialEquations (though that feels weird to me personally).

Also I for one feel we should all be stupid thankful that someone is pushing on this issue. I find diffeq solvers are one of the weakest areas of Julia currently. Graphs, Stats, Optimization all feel at a level that is very comfortable to replace general packages like Matlab for me (at a first approximation) but man solving these kinds of equations in julia feels barely passible. It is a herculean task to get this support in and Chris seems to be doing it with crazy determination. He could call the pacakge the OneTrueSolutionToSolvingEverything and I would support it!

It will kill me that it will be camelCase mind you ... Julia needs a PEP8 linter bad ;)

[Chris Rackauckas]

There is a chance I will be adding some bifurcation analysis soon. One of the projects I'm working on may need to do a bifurcation analysis soon, and when that happens I am going to make some arclength and homotopy continuation bifurcation diagram(mers?). It will take the same ODEProblem type that the ODE solvers use, though I need some good way of specifying the bifurcation parameter(s) that would bloat the function definitions.

I do hope that this is able to replace "most" people's needs like the general MATLAB packages. However, I dumped the idea of just working on ODE.jl for a few reasons. I think they are too close to MATLAB, and it's restricting. I'm not just talking about the naming, but a library for something like solving differential equations should really be using types to have more functionality. ode45 is limited by MATLAB having to use function handles. A problem type is much more general: you can define your SDE problem, do a bifurcation analysis, have it solve trajectories of the SDE, have it solve the Forward Kolmogorov equations for it, etc., just by passing the problem to different functions. ODE.jl also has some other limitations that stem from being basically a MATLAB re-implementation: it only works with vectors instead of arbitrary arrays, it "fixes" types to floats instead of letting you use any number implementation, it always saves every value of the trajectory, and since it doesn't handle the solutions in an arbitrary type, it does not have a way to easily add extra functionality like default plots for solutions, error / convergence calculations, etc. Since I want all of these for the research I'm doing (numerical methods for SDEs/SPDEs/SDDEs), I decided to just start clean and do it.

If you would like to chat about naming problems, find me in the Gitter. If the community wants the names switched around to match some other convention, I'd gladly follow that convention (I just did camelCase since it's what I'm familiar with). The only thing that I am shutting down are requests to make things more like MATLAB that are based on MATLAB's non-capabilities. That doesn't mean I don't want to make it easy for MATLAB-users (maybe I should add in the documentation or tutorial that it by default uses Dormand-Prince == ode45). 

Also, feel free to open up issues with feature requests / naming changes / extra documentation. Remember the package is less than a month old so it does not implement even close to what I am aiming for, and issues will help prioritize the work. I am currently finishing up some parts for higher-order SDEs since I am giving a presentation in Barcelona on them at the end of June, but after that I am going to keep implementing more solvers. When the paper that's associated with it is published, the presentation is done, and Plots.jl tags its new version, I will make sure the documentation is up to date and do a v0.1 release sometime in July.

I was hoping to do a big v0.1 release where I'd announce to julia-users with explanation of scope, some tutorials on my blog (you can see some extra example animations already in /src/examples) and better documentation, but I guess this is how things go.

[Gabriel Gellner]

Don't feel bad about being outed! This package is shaping up to be absolutely amazing! Your work speaks for itself. I will file some issues as requested.

One point, to be fair about ODE.jl, does support pretty general arrays. Maybe you looked at an older version? mauro3 moved heaven and earth to make the solvers stupid general (maybe too general ... I still can not stand the array of arrays output ... but they had lengthy discussion for why ...), I think their rk-solvers are actually really neat pieces of code for generality (casting the Rational tableaus into any given type etc). When I look at your code you seem to be hard coding Float64 at the moment. So maybe down the road we can port some of the ODE.jl code over if required.

I agree that the solver api is way too matlab-y, but using their code it isn't that hard to switch around, I did the same for myself in a non repo package.

Any one last time, your are a hero for getting this going. I am dying to start using it in my own work as I love diff.eqs :) 

[Chris Rackauckas]

On my private branch I already switched all coefficients to rational so any precision can be used (that's where the testing with bigfloats issue comes up, but on the SDE side). Maybe I should push that over to master? I solved an entire ODE using Rational{BigInt} as a test, and got a massive rational number which approximated the output :).  

I must've used an older version of ODE.jl, but if they are using Array of arrays, that is not good for performance. Instead you want to keep it as one contiguous array to not slow things down (it's a few orders of magnitude slower than the fastest way of doing it). This is why I use the .. notation (EllipsisNotation.jl). Because you brought this up I'll make a blog post on the benchmarks/shootouts and how EllipsisNotation.jl, GrowableArrays.jl, and ChunkedArrays.jl can be used to improve performance. [FYI you can just throw the Array of arrays into a StackedArray and call copy(arr) to make it a contiguous array (thanks @Matt B).] 

I think the main thing though about improving the API will be via code re-writing macros. I already gathered some information on how to do it here. I think that for lots of variables it's much nicer to write the math/science names, but internally it should make them into contiguous arrays for the solvers, though there should then be some helper functionality so that way the user doesn't even have to know that.

[digxx]

Hey,

Thx for your answer and sorry for that question, but what is ODE.jl

Probably some other package, which?

And I was looking to solve a similar poisson type equation mainly a conservation equation

div(v*Y - D grad Y) = 0

where Y is scalar, v an arbitrary specifyable vector field and D a scalar function also specifyable.

Also instead of casting it in cartesian form I wanted to use spherical coordinates.

See Ya

[Christoph Ortner]

Hi Chris: I did say I like your package, I think it is really nice work. I just have issues with such generic names, that is all. Maybe `DifferentialEquations` would have been the name for an organisation collecting several ODE and PDE related packages. I thought on the one hand your package is incredibly broad (ODEs, PDEs, SDEs, . . .; FE, FD, ...) it is also specific in that it is restricted in which DEs you have implemented. But maybe I am missing a key point somewhere? 

Actually I'd be interested in a `DifferentialEquations` organisation collecting Julia packages for ODE solvers, SDE solvers, FEM, etc. 

[Eric Forgy]

Hi Chris (et al)

It sounds like you've got a lot on your plate, but we apparently have some common interests.

When the smoke settles for you and you're looking for some night time reading (i.e. cure for insomnia), you might have a look at some of my old papers:

• Noncommutative Geometry and Stochastic Calculus: Applications in Mathematical Finance

I'm pretty sure I am the first person to apply NCG to finance :)

I followed that one up a couple years later with a more concrete application for practitioners:

• Financial Modelling Using Discrete Stochastic Calculus
  

Discrete stochastic calculus provides a kind of meta algorithm. It is an algorithm for generating algorithms.

If that doesn't cure your insomnia, this one surely will:

•  Discrete Differential Geometry on Causal Graphs
  

The above is a follow-up to work started in my dissertation at UIUC:

• Differential Geometry in Computational Electromagnetics
  

It was still a work in progress, but its not easy creating an entirely new framework for scientific computation, so I guess they thought it was enough :)

Anyway, I mention this because discrete stochastic calculus (DSC) would have a completely natural implementation in Julia using concepts similar to automatic differentiation to give you things like Ito formula for free. If I could clone myself, I would develop that, but I'm a "seniorpreneur", i.e. industry veteran (a.k.a. old man) working on my third FinTech startup, so it is on the back burner for now :)

My friend, John Baez, changed his academic passion from quantum gravity to environmental science a few years ago, which motivated me to start applying DSC to problems in fluid dynamics with some very cool result for Burgers  and Navier-Stokes equations (all unpublished). You can find a bunch of info about that here. 

Cheers

PS: Just before hitting "Send", I notice several of the links in my last reference are broken, which tends to happen after more than 5 years :), so here is one that should be good for Burgers stuff:

• Discrete Burgers equation revisited
  

The important quote:

I did not do much more with the discrete Burgers equation for reasons similar to John's. As far as I am concerned the problem is solved. I wrote down and implemented in code an algorithm having the magical property that the accuracy gets BETTER the longer you simulate. You cannot ask for more than that.

Finally:

•  Towards Navier-Stokes from noncommutative geometry
  

Fun stuff! I miss doing research like that :)

[Mauro]

Hi Chris,

DifferentialEquations.jl is an impressive tour de force! Nice work on
writing all the documentation too! Below a few comments in-line from my
ODE.jl perspective.

(As a side note to those interested in ODE/DAEs: we got a GSoC student,
Joseph Obiajulu, working on ODE.jl this summer. Plans are to code more
implicit and explicit solvers and put together a solid benchmarking
package. He will give a brief overview at JuliaCon.)

On Tue, 2016-06-07 at 18:23, Chris Rackauckas <rack...@gmail.com> wrote:
> I do hope that this is able to replace "most" people's needs like the
> general MATLAB packages. However, I dumped the idea of just working on
> ODE.jl for a few reasons. I think they are too close to MATLAB, and it's
> restricting. I'm not just talking about the naming, but a library for
> something like solving differential equations should really be using types
> to have more functionality. ode45 is limited by MATLAB having to use
> function handles. A problem type is much more general: you can define your
> SDE problem, do a bifurcation analysis, have it solve trajectories of the
> SDE, have it solve the Forward Kolmogorov equations for it, etc., just by
> passing the problem to different functions. ODE.jl also has some other
> limitations that stem from being basically a MATLAB re-implementation: it
> only works with vectors instead of arbitrary arrays, it "fixes" types to
> floats instead of letting you use any number implementation, it always
> saves every value of the trajectory, and since it doesn't handle the
> solutions in an arbitrary type, it does not have a way to easily add extra
> functionality like default plots for solutions, error / convergence
> calculations, etc. Since I want all of these for the research I'm doing
> (numerical methods for SDEs/SPDEs/SDDEs), I decided to just start clean and
> do it.

First, I am a bit sad that you decided to not channel your considerable
energy into improving ODE.jl (at least the part of your work which
concerns the ODE solvers). But I can understand that it is at times
better to do ones own thing without being restricted. And for sure, the
development of ODE.jl has been going at a glacial pace. However, I
think the reasons you give above are unfounded.

- The Matlab like interface does not preclude a more Julian interface.
In fact this is what is being worked on in @pwl's PR:
https://github.com/JuliaLang/ODE.jl/pull/49 where the underlying
low-level interface is swapped out to use iterators (using types not
unlike your ODEProblem), in-place functions, etc. One can use the
high-level Matlab-like interface or the low-level one if more control
is needed. But yes, it has been a long time coming and it is not
there yet...

What I do think is that the Matlab-interface is better for casual use
and it a de-facto standard. If I quickly want to solve an ode I don't
want to deal with types, etc, and I for sure don't want to read
documentation about it. But I agree for more advanced use a more
advanced interface should be in place; we're working on it.

- As has been mentioned by someone else in this thread, the critique
that ODE does not handle arbitrary types is wrong. Note that this
ability to use arbitrary types has been in ODE.jl for a long time
(although not all solvers supported it). See:
https://github.com/JuliaLang/ODE.jl/blob/master/test/interface-tests.jl
and the PRs: https://github.com/JuliaLang/ODE.jl/pull/98,
https://github.com/JuliaLang/ODE.jl/pull/96 (where incidentally I ran
into same BigFloat problem you found a few days later:
https://github.com/JuliaLang/julia/issues/16667 )

So, after my rebuttal, question for you: what would it take to make you
a contributor to ODE.jl?

> If you would like to chat about naming problems, find me in the Gitter. If
> the community wants the names switched around to match some other
> convention, I'd gladly follow that convention (I just did camelCase since
> it's what I'm familiar with). The only thing that I am shutting down are
> requests to make things more like MATLAB that are based on MATLAB's
> non-capabilities. That doesn't mean I don't want to make it easy for
> MATLAB-users (maybe I should add in the documentation or tutorial that it
> by default uses Dormand-Prince == ode45).

My complaint here is that your package does too many things. Could it
not be split into several? ODE, PDE, SDE? And then have the master
package DifferentialEquations.jl pull those pieces in? For instance
working with PDEs, I'm happy to have one package to do the spatial
discretisation, say FEM, and another to do the time integration, say
ODE.jl or Sundials.jl.

Lastly a few things which may be of interest to you, if you're not
aware:

- https://github.com/mauro3/IVPTestSuite.jl is a package to benchmark
ODE/DAE solvers for standard test cases. Would be cool to run your
solvers too (Sundials, ODE.jl and DASSL.jl are currently wrapped).
@obiajulu, the GSoC student working on ODE.jl this summer, is
currently updating it and I'll ping you when done. Basically you'd
need to write a wrapper for your solvers and you're good to run.

- You don't seem to be calculating Jacobians yet, but if that it planned
coloring might be of interest:
https://github.com/mauro3/MatrixColorings.jl Again, this has gone a
bit stale (together with my PR
https://github.com/JuliaLang/ODE.jl/pull/72 for which I made it) but I
would be interested to revive it.

Cheers,

Mauro

[Gabriel Gellner]

So much great news in this thread! I am crazy happy that ODE.jl is not dead. As an interested outsider it seemed like the community got gridlocked on the API discussion. It is nice that this is not the case.

A quick question as to why the matlab interface is better for small problems, I don't really get that.

suppose we have some kind of OdeProblem type and then you have specific types for a solver that inherit from this, say a `RK54` (don't worry about the ugly names)

then wouldn't it be just as easy from an end users perspective if you had something like:

sol = dsolve(RK54(func, y0), trange, <solver options>)

as

sol = ode45(func, y0, trange, <solver options>)

but with the above you get the ability to save the OdeProblem separately, have special versions that do inplace updating etc. I don't really see what having the callback version, versus the callback in a type version needs to be drastically different from the user perspective? Furthermore if something like the above is used then if the user switches between the high level and low level interface there is far less of a pattern switch in the calling function. Rather you would just do it on separate lines and save the problem type.

I have read much of the old discussions on the ODE.jl github issues, but it largely seemed that this was being looked at from a small vs large problem and not really from an API usability problem.

Thanks for any insight. I look forward to seeing what is in the works with the GSOC project.

Gabriel

[Mauro]

On Wed, 2016-06-08 at 16:36, Gabriel Gellner <gabriel...@gmail.com> wrote:
> So much great news in this thread! I am crazy happy that ODE.jl is not dead. As
> an interested outsider it seemed like the community got gridlocked on the API
> discussion. It is nice that this is not the case.

I think it was more a case of no-one having enough time on their hands.

> A quick question as to why the matlab interface is better for small problems, I
> don't really get that.
>
> suppose we have some kind of OdeProblem type and then you have specific types
> for a solver that inherit from this, say a `RK54` (don't worry about the ugly
> names)
> then wouldn't it be just as easy from an end users perspective if you had
> something like:
>
> sol = dsolve(RK54(func, y0), trange, <solver options>)

maybe better:

sol = dsolve(func, y0, trange, RK54(<solver options>) )

> as
>
> sol = ode45(func, y0, trange, <solver options>)

Well, either is fine. I think it is important that the high-level
interface is free or mostly free from custom types. A casual user
shouldn't need to learn about special types and be able to just use
arrays and functions. (I find that with Julia's awesome type system it
is easy to overdo it on the types.)

> but with the above you get the ability to save the OdeProblem separately, have
> special versions that do inplace updating etc. I don't really see what having
> the callback version, versus the callback in a type version needs to be
> drastically different from the user perspective? Furthermore if something like
> the above is used then if the user switches between the high level and low
> level interface there is far less of a pattern switch in the calling function.
> Rather you would just do it on separate lines and save the problem type.

I haven't really thought about switching between high and low-level.
You're right that ideally it should be easy, but IMO, not at the cost of
making the high-level interface complicated.

[Gabriel Gellner]

I absolutely agree in general. I am terrified when julia code gets to fancy :) I am largely a bear of little brain... (thos ODE.jl choice to send back array of arrays kind of breaks this feeling for simplicity ... having to learn to do hcat(sol...)' for the common case, versus letting this work for some high dimensional vector field case that was discussed feels like leaning on the side of complex ;)

>
> sol = dsolve(RK54(func, y0), trange, <solver options>)

maybe better:

sol = dsolve(func, y0, trange, RK54(<solver options>) )

This would more follow the way that Optim.jl has gone (sort of they seem to separate some of the general solver options, from the specific options. I haven't followed enough to know why this separation was desired).

The problem I see with this is that it overly relies on separating the func and array from the model/problem type. So again you suffer from not being able to do the

easy to understand (and for larger problems likely more efficient as you don't have to reallocate the temp arrays, but the naive user need not understand this).

prob = RK45(func, y0)

sol = dsolve(prob, tspan, <solver options>)

sol2 = dsolve(prob, tspan2, <solver options>)

as likely you will need to know the dimension of y0 to allocate all the underlying solver work space arrays, so RK45(<solver options>) can not be entirely decoupled from the "model" definition.

 

Well, either is fine.  I think it is important that the high-level
interface is free or mostly free from custom types.  A casual user
shouldn't need to learn about special types and be able to just use
arrays and functions.  (I find that with Julia's awesome type system it
is easy to overdo it on the types.)

I guess the key I see is that the matlab way of doing things encodes the "type" of the solver into the name of the function "ode45, ode23" etc

whereas if you have a wrapper type (or some function that returns such a type) then you just do

desolve(solver_type, ...)

which doesn't feel in any way more complex. The end user need not know anything about the type if they don't want to, they just need to know if you want the ode45 like behavior your do

desolve(RK45(func, y0), tspan)

vs

ode45(func, y0, tspan)

hell if the length is an issue you could have

ode(RK45(func, y0), tspan)

for only an extra 3 characters ;) with the super nice behavior of not having an entirely different api for when you need finer control (you just need extra knowledge of the special types).

That is why I feel that following the matlab way of doing things so closely (ie requiring a pure array + callback version) limits the api without making it simpler for the end, naive, user.

I guess I see the above way as being no different that using something like Distributions.jl, which I see as one of the nicest uses of types from an api perspective.

Getting to do

rand(disttype, options)

is super easy to understand versus having a billion specialty functions that take the raw options and dist parameters.

Just my thoughts as an end user. Those that are working on this will decide, but I feel the distaste for types in this simple case feels overly pessimistic.

[digxx]

Since Im not really up to date can anyone in 2 sentences explain to me what the issue with the package ODE.jl is?

Is it the interface ppl dont like or what makes it so "redundant"?

[Mauro]

On Wed, 2016-06-08 at 18:50, Gabriel Gellner <gabriel...@gmail.com> wrote:
> I absolutely agree in general. I am terrified when julia code gets to fancy :)
> I am largely a bear of little brain... (thos ODE.jl choice to send back array
> of arrays kind of breaks this feeling for simplicity ... having to learn to do
> hcat(sol...)' for the common case, versus letting this work for some high
> dimensional vector field case that was discussed feels like leaning on the side
> of complex ;)

I'm pretty sure this will change pretty soon. I think it's in @pwl's
big PR. The rational for the current way is that in the call

tout, yout = ode(f, y0, tspan)

y0 needn't be an array but any object which supports the needed math.
So yout couldn't be an Array{N,2} in the general case. But of course,
most of the time y0 will be a Vector and then typeof(yout)==Array{N,2}
would make the most sense. The current behavior of returning a
Vector{Vector} is far too annoying, so it has to change, I think.

>
> >
> > sol = dsolve(RK54(func, y0), trange, <solver options>)
>
> maybe better:
>
> sol = dsolve(func, y0, trange, RK54(<solver options>) )
>
>
>
> This would more follow the way that Optim.jl has gone (sort of they seem to
> separate some of the general solver options, from the specific options. I
> haven't followed enough to know why this separation was desired).
>
> The problem I see with this is that it overly relies on separating the func and
> array from the model/problem type. So again you suffer from not being able to
> do the
> easy to understand (and for larger problems likely more efficient as you don't
> have to reallocate the temp arrays, but the naive user need not understand
> this).
>
> prob = RK45(func, y0)
>
> sol = dsolve(prob, tspan, <solver options>)
>
> sol2 = dsolve(prob, tspan2, <solver options>)
>
> as likely you will need to know the dimension of y0 to allocate all the
> underlying solver work space arrays, so RK45(<solver options>) can not be
> entirely decoupled from the "model" definition.

I think once you get this far, then you should just use the lower level
API, which will not be very complicated either.

Yes, the high-level API may well evolve to use something like solver
objects. Maybe:

ode(rk45, f, y0, tspan)

Yes, Distributions.jl is nice indeed. I'll look at their API a bit more
closely. Thanks for your feedback!

[Gabriel Gellner]

Thank you so much for the feedback.

I just want to end with how much I love this community. I know this kind of "bike shedding" discussion can be annoying. Especially with all the work volunteers put in.

Also I love your work especially mauro :)

Anyway back to lurking.

Gabriel

[Mauro]

The issue is that ODE.jl has not moved quite at the pace many other
"core" packages have. (But it sees more love now with Joseph (GSoC)
working on it) However, ODE.jl it is very usable at the moment, if weak
on the implicit solver side (only ode23s; it's one of the goals of the
GSoC to remedy this). If you need an implicit pure-Julia solver
(ODE/DAE) you should give DASSL.jl a spin. If you don't care about
pure-Julia, try Sundials.jl. I don't think the ODE/(DAE?) solvers of
DifferentialEquations.jl have caught up to those above, but if Chris
keeps moving at this pace they may well do.

[Mauro]

Thanks :-)

[Chris Rackauckas]

Thanks for chiming in! There's a lot to say about this topic, and I think it's great! I felt like Julia's differential equation solvers were behind where they should be, which was crazy to me since there is so many state-of-the-art mathematical packages in other areas (optimization, stats, etc.)

 There are a few reasons why I didn't go about helping ODE.jl. I think the API is the biggest one. My muse here was JuMP. I used JuMP for a few really difficult optimization problems, and just swapped around the solvers by switching a keyword argument, and it handled the rest. I thought it was beautiful and the idea was simple: put the information for a problem into a type, and then just wrap solvers. Once I had that idea and gave it a try on the FEM "scratch work" I had been playing with, I just thought that this is why Julia will be the future. So my idea was to structure problem specifying and solving as follows: defining a problem is defining a type, from there you dispatch to a solver which is preamble, solver algorithm, put solution to object, and then have helpers make the solver object easy to use. The key here is that the solver algorithm is just the middle: you can just swap out the middle part in seconds, not just as a user, but as a coder. If you look at sdeSolvers.jl, you can see what my final plan is going towards: define all of the solvers as drop in code, and choose one in a conditional (though with the loop as part of the "def" code, right now that's not the case, and there should be easy loop pre-ambles post-ambles for saving outputs etc). Once you have that structure, adding new solvers is easy! So I added all of the solvers in odeSolvers (i.e. all of the standard solvers which I think ODE.jl has as well, plus a few) in one morning, just adding a new "way to handle the middle". Having the special output type also made convergence testing and plotting free (plotting is then super nice because the solution types have recipes to Tom's Plots.jl!), and from there things were just in motion. 

Once I had that structure, I wanted it all to be similar so that way they could interact well. Even though they do currently use it, there will be (S)PDE solvers which allow for using method of lines discretizations which then just plug into (S)ODE solvers. And what about all of those C/Fortran solvers? They can also just be added as part of the routine, and to switch over to it the user just swaps a keyword argument. This freedom of solvers has both practical, academic, and educational advantages. The practical advantage is that with users able to change 10 characters to switch the solvers, inevitably adding new solvers becomes "free new features". Also, these features can be existing solvers. For example, if you guys are doing well, and option may be to use ODE.jl solvers (if not just to benchmark between them, our solvers will most likely converge over time to about the same speed). But academically, this structure let me (and anyone else) just experiment with different solvers. Everything else is handled for you (plotting, convergence tests, setting up the internals, saving everything), so you literally just write the loop. That's why I am using it to develop SDE algorithms. And lastly, education. For example, it will only take about 10 lines to implement a Simpson's Rule solver for ODEs. This is a quiz problem I have to my undergrads: what order is it, and what's the region of stability? It's always unstable, so you'd never want to use it on a real problem. I plan to just add that as an option in the solver because it won't slow anything else down: it'll just be a bad option. The documentation will say it's a bad method, but this lets the curious students see what happens.

So once I had this JuMP-inspired idea, I was scared of ODE.jl's pace of development. I didn't want to wait to talk about API decisions and all that: So I made a prototype. Note that at first I wasn't going to step on ODE.jl's toes so I put in the README that it doesn't handle ODEs, but then I needed one to generate some silly figure, and so for fun I used to SDE solver template to then make the ODEProblem, coded RK solvers from memory, opened up Hairer's book and implemented Rosenbrock solvers, and tada I had an ODE solver suite some hours later. 

I don't think then that DifferentialEquations.jl and ODE,jl are diametrically opposed in any way. DifferentialEquations.jl is more this high-level interface to how to specify differential equation problems, interface with solvers, and then give a structured solution which is "easy to play with" (I think making an animation of a solution using animate(sol) is just too cool). It has a bunch of solvers because I was testing it all out and because that's what my PhD research is (stochastic solvers specifically, so of course I implement deterministic solvers all the time though!). ODE.jl is a set of ODE solvers, and can actually be used by DifferentialEquations.jl (though it hasn't yet).

How this should all be organized? I don't really know. I mentioned it on the newly formed JuliaMath organization. But I don't think anyone really cared, but that's also because I didn't "have" anything. Now that I have all of this implemented, the question is coming back (as it should). My take on it is that in this form, "differential equation problems" are all pretty much the same: they are a problem specification via some functions, some kind of mesh (either just time, or space and time), an associated solvers, and some helper functions for doing standard analyses of the solution. These pieces will then play with each other: solving an SDE can be solving a PDE if you want to do it via the Fokker-Plank / Forward Kolmogorov / Feynman-Kac way, solving a PDE might just discretize to an ODE problem. or you can solve some PDEs probabilistically by solving a Monte Carlo simulation of SDEs. That's why I kept them together. But to be honest,I don't care about organization as much as long as it's easy to just implement every possible way of solving things,

There's a lot left to do. I've only had this package for less than a month, and was taking 6 courses + 2 seminars per quarter this year, so I didn't get as much done as I hoped. However, I am turning in that last final in a few days, so I will be freed up to start working more on this. Also, I have a lot of private codes which are being submitted soon and once those are published we will really have some state-of-the-art functionality. Next year I have courses and plan to take this head on. So I am just going to keep doing as much as possible, and we as a community can discuss what we want to do with it.

[Mauro]

Hi Chris,

thanks for elaborating (maybe you should copy your message into some
vision.md file in your repo). Your plan sounds cool, good luck with it!
I would definitely use a plug and play ODE/PDE solver infrastructure.

I agree that at the fast pace you're moving at the moment it is best to
just have your own package(s). However, if you code up more ODE/DAE
solvers, it would be great if those are usable without all the machinery
of DifferentialEquations.jl and if they eventually make into ODE.jl (or
some other "standard" ODE package).

A few more comments in-line below. Cheers! Mauro

On Wed, 2016-06-08 at 20:40, Chris Rackauckas <rack...@gmail.com> wrote:
> Thanks for chiming in! There's a lot to say about this topic, and I think it's
> great! I felt like Julia's differential equation solvers were behind where they
> should be, which was crazy to me since there is so many state-of-the-art
> mathematical packages in other areas (optimization, stats, etc.)

I think we are missing someone who actually does research in this area.
As far as I can tell, all of us ODE.jl-ers are just "users", but not
researching new methods.

> There are a few reasons why I didn't go about helping ODE.jl. I think the API
> is the biggest one. My muse here was JuMP. I used JuMP for a few really
> difficult optimization problems, and just swapped around the solvers by
> switching a keyword argument, and it handled the rest. I thought it was
> beautiful and the idea was simple: put the information for a problem into a
> type, and then just wrap solvers. Once I had that idea and gave it a try on the
> FEM "scratch work" I had been playing with, I just thought that this is why
> Julia will be the future. So my idea was to structure problem specifying and
> solving as follows: defining a problem is defining a type, from there you
> dispatch to a solver which is preamble, solver algorithm, put solution to
> object, and then have helpers make the solver object easy to use. The key here
> is that the solver algorithm is just the middle: you can just swap out the
> middle part in seconds, not just as a user, but as a coder. If you look at
> sdeSolvers.jl, you can see what my final plan is going towards: define all of
> the solvers as drop in code, and choose one in a conditional (though with the
> loop as part of the "def" code, right now that's not the case, and there should
> be easy loop pre-ambles post-ambles for saving outputs etc). Once you have that
> structure, adding new solvers is easy! So I added all of the solvers in
> odeSolvers (i.e. all of the standard solvers which I think ODE.jl has as well,
> plus a few) in one morning, just adding a new "way to handle the middle".
> Having the special output type also made convergence testing and plotting free
> (plotting is then super nice because the solution types have recipes to Tom's
> Plots.jl!), and from there things were just in motion.

I think one of the key features here is that whilst JuMP is all fancy,
its components are pretty down to earth. If you just want to optimize a
function without using JuMP's DSL then just use, e.g., NLopt.jl.
Maybe something to keep in mind when designing DifferentialEquations.

> Once I had that structure, I wanted it all to be similar so that way they could
> interact well. Even though they do currently use it, there will be (S)PDE
> solvers which allow for using method of lines discretizations which then just
> plug into (S)ODE solvers. And what about all of those C/Fortran
> solvers?

(Do you know https://github.com/luchr/ODEInterface.jl and TS of
https://github.com/JuliaParallel/PETSc.jl ?)

> They can also just be added as part of the routine, and to switch over
> to it the user just swaps a keyword argument. This freedom of solvers
> has both practical, academic, and educational advantages. The
> practical advantage is that with users able to change 10 characters to
> switch the solvers, inevitably adding new solvers becomes "free new
> features". Also, these features can be existing solvers. For example,
> if you guys are doing well, and option may be to use ODE.jl solvers
> (if not just to benchmark between them, our solvers will most likely
> converge over time to about the same speed). But academically, this
> structure let me (and anyone else) just experiment with different
> solvers. Everything else is handled for you (plotting, convergence
> tests, setting up the internals, saving everything), so you literally
> just write the loop. That's why I am using it to develop SDE
> algorithms. And lastly, education. For example, it will only take
> about 10 lines to implement a Simpson's Rule solver for ODEs. This is
> a quiz problem I have to my undergrads: what order is it, and what's
> the region of stability? It's always unstable, so you'd never want to
> use it on a real problem. I plan to just add that as an option in the
> solver because it won't slow anything else down: it'll just be a bad
> option. The documentation will say it's a bad method, but this lets
> the curious students see what happens.
>
> So once I had this JuMP-inspired idea, I was scared of ODE.jl's pace
> of development. I didn't want to wait to talk about API decisions and
> all that: So I made a prototype.

If you have special API requirements, then it would still be good to
hear them.

> Note that at first I wasn't going to step on ODE.jl's toes so I put in
> the README that it doesn't handle ODEs, but then I needed one to
> generate some silly figure, and so for fun I used to SDE solver
> template to then make the ODEProblem, coded RK solvers from memory,
> opened up Hairer's book and implemented Rosenbrock solvers, and tada I
> had an ODE solver suite some hours later.

Will the whole infrastructure for SDE solvers be usable for ODE/DAE
solvers too? With infrastructure I mean: adaptive step size and order
selection, dense output, root finding/events, etc.

[Chris Rackauckas]

Hey,

thanks for elaborating (maybe you should copy your message into some
vision.md file in your repo).  Your plan sounds cool, good luck with it!
I would definitely use a plug and play ODE/PDE solver infrastructure.

  I will write a cleaner version as a blog post with some examples to walk through the whole idea once I have some more "polish" done.

 

 

I agree that at the fast pace you're moving at the moment it is best to
just have your own package(s).  However, if you code up more ODE/DAE
solvers, it would be great if those are usable without all the machinery
of DifferentialEquations.jl and if they eventually make into ODE.jl (or
some other "standard" ODE package).

They definitely could. In fact, you can port some of the RK methods just by implementing some of the tableaus from here: https://github.com/ChrisRackauckas/DifferentialEquations.jl/blob/master/src/ode/ODECoefficientTypes.jl. I just checked and am surprised you guys don't have a DP78 method, but it shouldn't take more than minutes to plop that tableau over there.

 

A few more comments in-line below.  Cheers! Mauro

On Wed, 2016-06-08 at 20:40, Chris Rackauckas <rack...@gmail.com> wrote:
> Thanks for chiming in! There's a lot to say about this topic, and I think it's
> great! I felt like Julia's differential equation solvers were behind where they
> should be, which was crazy to me since there is so many state-of-the-art
> mathematical packages in other areas (optimization, stats, etc.)

I think we are missing someone who actually does research in this area.
As far as I can tell, all of us ODE.jl-ers are just "users", but not
researching new methods.

I think one of the key features here is that whilst JuMP is all fancy,
its components are pretty down to earth.  If you just want to optimize a
function without using JuMP's DSL then just use, e.g., NLopt.jl.
Maybe something to keep in mind when designing DifferentialEquations.

I have thought about keeping the solvers as functions which could just be called "naturally" without making a type, but the main issue is that plugging into some function by passing all of the parts is nice for only for the simplest types of problems (ODEs, Poisson equation, etc., but even this falls apart if you start talking about Taylor methods etc.). I actually started out with the FEM solvers having a solver with a huge definition, and then having the type be a dispatch which then plugs a bunch of things in. However, it started to become hard to maintain like that. For one, I didn't know you could splat kwargs (ahh! That was horrifying to pass every kwarg!), but then I didn't have a good way to make the kwargs of the typed dispatch match the kwargs of the solver (since the kwargs were defined for two different functions), and any time there was a change I'd have to "propagate that change through all the solvers". I finally had enough of that and found your Parameters.jl package. Now you see that the solvers just use a type and unpack at the top. Very simple and easy to maintain. But if there's a better way of handling that issue with the dispatches, then I can put them back to how they were and pull them out to be separate solvers which could be called directly.Then if you want to pull out some of the new solving algorithms (I need better words for differentiating here: the solver is the method which acts on a type, while the solving algorithm is RK or Euler-Maruyama), that's pretty much what I'm doing with @def except not making them directly callable due to kwarg/default settings problems. It's just easier to have all of the pre/post processing in one way, but that could change by some smarter engineering.

 

> Once I had that structure, I wanted it all to be similar so that way they could
> interact well. Even though they do currently use it, there will be (S)PDE
> solvers which allow for using method of lines discretizations which then just
> plug into (S)ODE solvers. And what about all of those C/Fortran
> solvers?

(Do you know https://github.com/luchr/ODEInterface.jl and TS of
https://github.com/JuliaParallel/PETSc.jl ?)

Yes, those and Sundials are what I have in mind as methods the user can choose. I don't really know how to handle the dependency issue though: do you require these packages? Right now I require Plots and PyPlot. Is that necessary? Is requiring NLSolve necessary when it's only used for the implicit methods? ForwardDiff is only used in the Rosenbrock methods (currently), should it be a dependency? Or should I detail a list of what methods need what dependencies? I haven't settled on this, and may open an issue.

 

If you have special API requirements, then it would still be good to
hear them.

I don't think I'll have requirements, but I'll have to do a matrix like Plots.jl does where it's like "these solvers do ...". I think using in-place updating (I haven't made a version for this yet though), being able to choose how often results are saved, and being able to switch on and off adaptivity will be on the list.

Will the whole infrastructure for SDE solvers be usable for ODE/DAE
solvers too?  With infrastructure I mean: adaptive step size and order
selection, dense output, root finding/events, etc.

Yes and no. Yes in that you could make an SDE with no noise and then use the SDE solvers (for science reasons). No in that they are completely different methods and you would never want to do that in any practical case. I am still on the fence about whether there should just be an "OdeProblem" type that does this based on whether there is noise, but the issue here is that the default algorithms, tolerances, etc. are all different between them. Adaptivity (without requiring a priori estimates) is what I worked out in the last paper, and even though the final algorithm has pretty low overhead over ODEs, it's still non-zero and measurably there (and 100x more complex to get there, mucking up the algorithm). Order selection is very different too: for SDEs there are two relevant concepts of order and generally the strong order goes in increments of 0.5, with the extra number of calculations for an order change and the stability issues being completely different (with different orders for differing amounts of noise dominance as well). Dense output is a mystery waiting to be solved: I have some ideas (with issues) but whatever the answer is, it's likely to be complicated. I think that makes it clear that at some fundamental level they end up being very different, making it hard to apply any of the same methods.

The weird thing is that this is not true for SPDEs. This is because the Davie-Gaines bound basically means you should use a Strong Order 0.25 method (Euler-Maruyama), and then your best approximation tends to the the simplest/easiest/naturalist one, and so putting PDE/SPDEs together is easy. I am deep into an idea for changing that, but to try out the idea will require a bit more infrastructure (it's quite an involved algorithm). This will be back to my main focus likely next fall for a month or so, and so if this idea finally works I may put more separation between PDE and SPDE methods for the same reason as ODEs/SDEs.

[Mauro]

On Thu, 2016-06-09 at 18:30, Chris Rackauckas <rack...@gmail.com> wrote:
> Hey,
>
> thanks for elaborating (maybe you should copy your message into some
>> vision.md file in your repo). Your plan sounds cool, good luck with it!
>> I would definitely use a plug and play ODE/PDE solver infrastructure.
>
>
> I will write a cleaner version as a blog post with some examples to walk
> through the whole idea once I have some more "polish" done.

(PS: thanks for your great blog!)

>>
>>
> I agree that at the fast pace you're moving at the moment it is best to
>> just have your own package(s). However, if you code up more ODE/DAE
>> solvers, it would be great if those are usable without all the machinery
>> of DifferentialEquations.jl and if they eventually make into ODE.jl (or
>> some other "standard" ODE package).
>>
>>
> They definitely could. In fact, you can port some of the RK methods just by
> implementing some of the tableaus from
> here: https://github.com/ChrisRackauckas/DifferentialEquations.jl/blob/master/src/ode/ODECoefficientTypes.jl.
> I just checked and am surprised you guys don't have a DP78 method, but it
> shouldn't take more than minutes to plop that tableau over there.

Yes, we only had the Fehlberg 78. Not anymore though
https://github.com/JuliaLang/ODE.jl/pull/101, thanks!

>> A few more comments in-line below. Cheers! Mauro
>>
>> On Wed, 2016-06-08 at 20:40, Chris Rackauckas <rack...@gmail.com

I agree, keyword-args are a maintenance headache (and also potentially
bad for performance). That was indeed one of the reason to make
Parameters.jl to generate the keyword constructors for the types
automatically. Then use the types instead of keyword functions.

Concerning the implementation I was not very clear: I don't mean to
argue that you should not use any fancy type, etc., in your solvers
(maybe call them integrators?) but that you should also provide a dumb
interface for them (eventually) so they can be used outside of
DifferentialEquations. (And yes, the @def does feel like unnecessary
metaprogramming).

>> > Once I had that structure, I wanted it all to be similar so that way
>> they could
>> > interact well. Even though they do currently use it, there will be
>> (S)PDE
>> > solvers which allow for using method of lines discretizations which then
>> just
>> > plug into (S)ODE solvers. And what about all of those C/Fortran
>> > solvers?
>>
>> (Do you know https://github.com/luchr/ODEInterface.jl and TS of
>> https://github.com/JuliaParallel/PETSc.jl ?)
>>
>
>
> Yes, those and Sundials are what I have in mind as methods the user can
> choose. I don't really know how to handle the dependency issue though: do
> you require these packages? Right now I require Plots and PyPlot. Is that
> necessary? Is requiring NLSolve necessary when it's only used for the
> implicit methods? ForwardDiff is only used in the Rosenbrock methods
> (currently), should it be a dependency? Or should I detail a list of what
> methods need what dependencies? I haven't settled on this, and may open an
> issue.

The issue is https://github.com/JuliaLang/julia/issues/6195

There is https://github.com/MikeInnes/Requires.jl (but it does not work 100%).

And here is how Plots.jl does it:
https://github.com/tbreloff/Plots.jl/blob/cf4d78c87c773453945f181cce2f1fe495c94798/src/backends/pyplot.jl#L59

>> If you have special API requirements, then it would still be good to
>> hear them.
>>
>
> I don't think I'll have requirements, but I'll have to do a matrix like
> Plots.jl does where it's like "these solvers do ...". I think using
> in-place updating (I haven't made a version for this yet though), being
> able to choose how often results are saved, and being able to switch on and
> off adaptivity will be on the list.

Sounds reasonable. In-place is coming along with dense output:
https://github.com/JuliaLang/ODE.jl/pull/49#issuecomment-208895160.
Switching adaptivity has not been considered yet but should be fine.

Thanks for the explanation.

[Chris Rackauckas]

I agree, keyword-args are a maintenance headache (and also potentially
bad for performance).  That was indeed one of the reason to make
Parameters.jl to generate the keyword constructors for the types
automatically.  Then use the types instead of keyword functions.

Concerning the implementation I was not very clear: I don't mean to
argue that you should not use any fancy type, etc., in your solvers
(maybe call them integrators?) but that you should also provide a dumb
interface for them (eventually) so they can be used outside of
DifferentialEquations.  (And yes, the @def does feel like unnecessary
metaprogramming).

Yeah, in its current use it's unnecessary. I am doing a bit of a turn around on it now that I am implementing external integrators (nice word choice. That's what I've been doing in research papers, I'll carry that over to the package). Indeed, for adding external integrators to be the same as adding new solvers internally, calling internal integrators should be calling a function. That is pretty much in line with how I am using integrators which just make a few matrices and call IterativeSolvers.jl or NLSolve.jl (which are some of the FEM methods), and so it will also generalize to using ODE.jl, ODEInterface.jl, PETSc.jl, etc. Also, all of my GPU / Xeon Phi integrators for SDEs simply call C/Cuda functions (currently not released), and so those will be easier to make into function calls. So while @def was really quick and easy for building geometric multigrid solvers (for an example, see /src/fdm/stokesSolvers.jl), in the end I took the idea too far. It's looking like most of it should be all switched to function calls.

One thing that will be nice though is to use @def for loop header and footers. For example, there are many different rejection sampling adaptive algorithms which do the same routine for determining rejections and adjusting step size, and at the top of every loop I update the iteration (and hit the RNG for SDE methods), so I think the most maintainable way to write the integrators will be to make them their own function which is just a loop, which does:

while t<T
  @odeloopheader
  ...
  #Write out the method here
  ...
  if adaptive
    @odeadaptivefooter
  else
    @odefooter
  end
end

That way adding maximum iterations or any of those other goodies is just one change to the header or footer macro, and it will then propagate through to every method. Also part of my footers is the progressbar logic:

atomLoaded ? Main.Atom.progress((t-tspan[1])/(tspan[2]-tspan[1])) : nothing #Use Atom's progressbar if loaded

Since Juno/Atom is set to become the default IDE, I think it would be good to support its special functions (when available), which for now is the progressbar (which works really well!). 

 

> Yes, those and Sundials are what I have in mind as methods the user can
> choose. I don't really know how to handle the dependency issue though: do
> you require these packages? Right now I require Plots and PyPlot. Is that
> necessary? Is requiring NLSolve necessary when it's only used for the
> implicit methods? ForwardDiff is only used in the Rosenbrock methods
> (currently), should it be a dependency? Or should I detail a list of what
> methods need what dependencies? I haven't settled on this, and may open an
> issue.

The issue is https://github.com/JuliaLang/julia/issues/6195

There is https://github.com/MikeInnes/Requires.jl (but it does not work 100%).

And here is how Plots.jl does it:
https://github.com/tbreloff/Plots.jl/blob/cf4d78c87c773453945f181cce2f1fe495c94798/src/backends/pyplot.jl#L59

Tom Breloff's recent change to plots will make it so that way I only require RecipesBase.jl, and then have it in documentation that to use the plotting functionality, you have to install Plots.jl and a backend (preferably PyPlot). So I think the first thing in the documentation will be a dependency chart/explanation, i.e. to use ___________ methods, you need __________. A nice little graphic will solve it.

I think I will tag the a new minor version to make the latest tagged version compatible with the new Plots and have all the latest integrators. I will cram to make the internal change to functions, add in calls to the other libraries (at least for ODEs), and change the dependency setup before the major release. With that I will have a blog post on the vision, and make it easier for others to start contributing. That will happen when my paper on the SDE methods is published (resubmitting by the end of the week, so at least by the end of summer, and I hope by midsummer) which will allow me to pull in a private branch where a lot of my development has been. When I get there, we should talk about whether some of the parts should be broken out to their own packages and stitched together via DifferentialEquations.jl (that would definitely make the tests quicker!)

Thanks for helping me get more focus! Do you plan on moving to ODE.jl to JuliaMath? When I hit the major release, I think we should be considering bringing us together under some organization. 

[Mauro]

On Fri, 2016-06-10 at 17:13, Chris Rackauckas <rack...@gmail.com> wrote:
...

> Thanks for helping me get more focus! Do you plan on moving to ODE.jl to
> JuliaMath? When I hit the major release, I think we should be considering
> bringing us together under some organization.

Thanks for the good discussion! I don't know where ODE.jl goes, but it
may well join JuliaMath. I think there was/is a push to lighten the
JuliaLang org because of CI time constraints.

[Viral Shah]

That's right. Perhaps we need a JuliaDiffEq organization to collect various ODE, PDE, FEM related packages.

-viral

[Viral Shah]

Perhaps JuliaMath is a good place for now. That is what I am going to suggest.

[Christoph Ortner]

A separate organisation would be really welcome especially if it means coordination of efforts on the development of DE-related work.

[Chris Rackauckas]

This has already been done. As of last night we have JuliaDiffEq where we have moved Sundials and ODE. DifferentialEquations will follow soon, and I am talking with the owner of ODEInterface to see if that should go there as well (and if it should be expanded). 

If you have any ideas, open an issue on the Roadmap repo. We should find out what the other SDE/PDE packages are and coordinate efforts/APIs. The other SDE packages are pretty basic, and I don't think it would be useful to deal with simple things like StochasticEuler. Bridge.jl may be interesting: I know that it may need to be needed by DifferentialEquations for more easily implementing stochastic integral equations and a few high weak order methods, so it would be nice to pull it into the group. The idea would that others could do similar tasks easier if this is all coordinated together.

My goal is to have DifferentialEquations.jl wrap all of the solvers here. You can already use Sundials, ODEInterface, and ODE from DifferentialEquations. More coordination is likely required to make the PDE packages compatible (and I don't know of very many, JuliaFEM and HP-FEM?). Probably the toolings for making FEM meshes and things like that should spawn out to their own package and become more complete.  Of course, others will have their own reason for having compatible APIs.

I just setup a  unified Gitter. I think we should have the current ODE and DifferentialEquations Gitters merge to this JuliaDiffEq one so that way it will be easier to find help.

[Viral Shah]

Chris, Thanks for consolidating efforts and setting things up to set up a community for all kinds of differential equations.

I wonder if we should have a DiffEq channel/room on the julia gitter rather than a new gitter? Just a thought. For now, many projects do have their own gitter - like Bio.jl.

-viral

-viral

[Chris Rackauckas]

The Bio.jl Gitter is part of the BioJulia org. It's setup nicely in that none of the other channels within the BioJulia sphere have Gitters so you know which channel to go to. I modeled it after that. It would be interesting if channels like this were setup under the JuliaLang repo, but I am not sure what that means with the ability to share mod powers (usually not that bad from Gitter folk, though it's nice to be able to change the integrations around). 

[Viral Shah]

I personally feel that Gitter is great for helping out people who are starting out, but hope it doesn’t become a substitute for developer discussions and the development process.

On github, with issues, there is a documented and organized trail for posterity that helps onboard new developers and such.

-viral

[Chris Rackauckas]

I agree. That's why I'm trying to pool the Gitters together as a chatroom for helping people use the package, but whenever we find that something is a bug / feature request, give a nudge "please open an issue". Or whenever a developer discussion does happen in chat, a summary is posted as an issue to continue the discussion there.This is what's done with Plots.jl and you can see that there's a lot of activity helping people install Plots.jl in the Gitter, and a good number of issues on the repo for logging development issues / feature requests. So instead of being a substitute, they compliment each other.