Re: [julia-users] Differential Equations Package

[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.

On Friday, August 26, 2016 at 9:12:37 AM UTC-7, Viral Shah wrote:
>
> 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 
>
>
>
> > On Aug 26, 2016, at 7:45 PM, Chris Rackauckas  > wrote: 
> > 
> > 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). 
> > 
> > On Friday, August 26, 2016 at 3:24:25 AM UTC-7, Viral Shah wrote: 
> > 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 
> > 
> > 
> > > On Aug 26, 2016, at 4:41 AM, Chris Rackauckas  
> wrote: 
> > > 
> > > 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. 
> > > 
> > > On Thursday, August 25, 2016 at 3:09:49 PM UTC-7, Christoph Ortner 
> wrote: 
> > > A separate organisation would be really welcome especially if it means 
> coordination of efforts on the development of DE-related work. 
> > 
> > 
> > -viral 
> > 
> > 
> > 
>
>

Re: [julia-users] Differential Equations Package

[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



> On Aug 26, 2016, at 7:45 PM, Chris Rackauckas  wrote:
> 
> 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). 
> 
> On Friday, August 26, 2016 at 3:24:25 AM UTC-7, Viral Shah wrote:
> 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 
> 
> 
> > On Aug 26, 2016, at 4:41 AM, Chris Rackauckas  wrote: 
> > 
> > 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. 
> > 
> > On Thursday, August 25, 2016 at 3:09:49 PM UTC-7, Christoph Ortner wrote: 
> > A separate organisation would be really welcome especially if it means 
> > coordination of efforts on the development of DE-related work. 
> 
> 
> -viral 
> 
> 
> 

Re: [julia-users] Differential Equations Package

[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). 

On Friday, August 26, 2016 at 3:24:25 AM UTC-7, Viral Shah wrote:
>
> 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 
>
>
> > On Aug 26, 2016, at 4:41 AM, Chris Rackauckas  > wrote: 
> > 
> > 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. 
> > 
> > On Thursday, August 25, 2016 at 3:09:49 PM UTC-7, Christoph Ortner 
> wrote: 
> > A separate organisation would be really welcome especially if it means 
> coordination of efforts on the development of DE-related work. 
>
>
> -viral 
>
>
>
>

Re: [julia-users] Differential Equations Package

[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


> On Aug 26, 2016, at 4:41 AM, Chris Rackauckas  wrote:
> 
> 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.
> 
> On Thursday, August 25, 2016 at 3:09:49 PM UTC-7, Christoph Ortner wrote:
> A separate organisation would be really welcome especially if it means 
> coordination of efforts on the development of DE-related work.


-viral

Re: [julia-users] Differential Equations Package

[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.

On Thursday, August 25, 2016 at 3:09:49 PM UTC-7, Christoph Ortner wrote:
>
> A separate organisation would be really welcome especially if it means 
> coordination of efforts on the development of DE-related work.
>

Re: [julia-users] Differential Equations Package

[Christoph Ortner]

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

Re: [julia-users] Differential Equations Package

[Viral Shah]

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

On Thursday, August 25, 2016 at 12:45:54 PM UTC+5:30, Viral Shah wrote:
>
> That's right. Perhaps we need a JuliaDiffEq organization to collect 
> various ODE, PDE, FEM related packages.
>
> -viral
>
> On Friday, June 10, 2016 at 11:31:04 PM UTC+5:30, Mauro wrote:
>>
>> On Fri, 2016-06-10 at 17:13, Chris Rackauckas  
>> 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. 
>>
>

Re: [julia-users] Differential Equations Package

[Viral Shah]

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

-viral

On Friday, June 10, 2016 at 11:31:04 PM UTC+5:30, Mauro wrote:
>
> On Fri, 2016-06-10 at 17:13, Chris Rackauckas  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. 
>

Re: [julia-users] Differential Equations Package

[Mauro]

On Fri, 2016-06-10 at 17:13, Chris Rackauckas  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.

Re: [julia-users] Differential Equations Package

[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 > 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. 

Re: [julia-users] Differential Equations Package

[Mauro]

On Thu, 2016-06-09 at 18:30, Chris Rackauckas  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 > > 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.

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

Re: [julia-users] Differential Equations Package

[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  > 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 

Re: [julia-users] Differential Equations Package

[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  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 

Re: [julia-users] Differential Equations Package

[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 

Re: [julia-users] Differential Equations Package

[Mauro]

Thanks :-)

On Wed, 2016-06-08 at 20:14, Gabriel Gellner  wrote:
> 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

Re: [julia-users] Differential Equations Package

[Mauro]

On Wed, 2016-06-08 at 19:11, digxx  wrote:
> 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"?

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.

Re: [julia-users] Differential Equations Package

[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

Re: [julia-users] Differential Equations Package

[Mauro]

On Wed, 2016-06-08 at 18:50, Gabriel Gellner  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, )
>
> maybe better:
>
> sol = dsolve(func, y0, trange, RK54() )
>
>
>
> 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, )
>
> sol2 = dsolve(prob, tspan2, )
>
> as likely you will need to know the dimension of y0 to allocate all the
> underlying solver work space arrays, so RK45() 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.


> 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.

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!

Re: [julia-users] Differential Equations Package

[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"?

Re: [julia-users] Differential Equations Package

[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, ) 
>
> maybe better: 
>
> sol = dsolve(func, y0, trange, RK54() ) 
>
>
> 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, )

sol2 = dsolve(prob, tspan2, )

as likely you will need to know the dimension of y0 to allocate all the 
underlying solver work space arrays, so RK45() 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.

Re: [julia-users] Differential Equations Package

[Mauro]

On Wed, 2016-06-08 at 16:36, Gabriel Gellner  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, )

maybe better:

sol = dsolve(func, y0, trange, RK54() )

> as
>
> sol = ode45(func, y0, trange, )

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.

> 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

Re: [julia-users] Differential Equations Package

[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, )

as

sol = ode45(func, y0, trange, )

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

Re: [julia-users] Differential Equations Package

[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  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 

Re: [julia-users] Differential Equations Package

[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 :)

Re: [julia-users] Differential Equations Package

[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. 

Re: [julia-users] Differential Equations Package

[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.

On Tuesday, June 7, 2016 at 10:28:15 AM UTC-7, Gabriel Gellner wrote:
>
> 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 :) 
>
> On Tuesday, June 7, 2016 at 9:23:55 AM UTC-7, Chris Rackauckas wrote:
>>
>> 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 

Re: [julia-users] Differential Equations Package

[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.

On Tuesday, June 7, 2016 at 6:43:23 AM UTC-7, Gabriel Gellner wrote:
>
> 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 ;)
>
> On Tuesday, June 7, 2016 at 1:48:51 AM UTC-7, jonatha...@alumni.epfl.ch 
> wrote:
>>
>> 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.
>>
>

Re: [julia-users] Differential Equations Package

[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 ;)

On Tuesday, June 7, 2016 at 1:48:51 AM UTC-7, jonatha...@alumni.epfl.ch 
wrote:
>
> 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.
>

Re: [julia-users] Differential Equations Package

[jonathan . bieler]

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.

Re: [julia-users] Differential Equations Package

[Eric Forgy]

Sounds awesome Chris +1

Re: [julia-users] Differential Equations Package

[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, 

On Monday, June 6, 2016 at 5:31:24 PM UTC-7, Christoph Ortner wrote:
>
> 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.
>

Re: [julia-users] Differential Equations Package

[Christoph Ortner]

just to emphasize this is purely personal opinion.

On Tuesday, 7 June 2016 01:31:24 UTC+1, Christoph Ortner wrote:
>
> 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.
>

Re: [julia-users] Differential Equations Package

[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.

Re: [julia-users] Differential Equations Package

[digxx]

Yes. I am. 

Am Dienstag, 7. Juni 2016 00:22:57 UTC+2 schrieb Stefan Karpinski:
>
> Are you talking about this package 
> https://github.com/ChrisRackauckas/DifferentialEquations.jl ?
>
> On Mon, Jun 6, 2016 at 6:04 PM, digxx  
> wrote:
>
>> 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?
>>
>
>

Re: [julia-users] Differential Equations Package

[Stefan Karpinski]

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

On Mon, Jun 6, 2016 at 6:04 PM, digxx  wrote:

> 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?
>