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