Skip to content

WIP: removing bits which should go into packages #5

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 2 commits into from
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
65 changes: 18 additions & 47 deletions src/DiffEqBase.jl
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@ __precompile__()

module DiffEqBase

using RecipesBase, Parameters, RecursiveArrayTools
using RecipesBase, RecursiveArrayTools
using Ranges # For plot recipes with units
import Base: length, size, getindex, endof, show, print,
next, start, done, eltype, eachindex
Expand All @@ -16,84 +16,55 @@ module DiffEqBase
abstract AbstractSDEProblem <: DEProblem
abstract AbstractDAEProblem <: DEProblem
abstract AbstractDDEProblem <: DEProblem
abstract AbstractPoissonProblem <: DEProblem
abstract AbstractHeatProblem <: DEProblem
"`PdeSolution`: Wrapper for the objects obtained from a solver"
abstract AbstractPDEProblem <: DEProblem
"`DSolution`: type to hold the objects obtained from a solver"
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this package we should only define the abstract types of broad categories of equations, I think. A heat-problem seems to specific.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense.

abstract DESolution
abstract AbstractODESolution <: DESolution
abstract AbstractSDESolution <: AbstractODESolution # Needed for plot recipes
abstract AbstractDDESolution <: AbstractODESolution # Needed for plot recipes
abstract AbstractFEMSolution <: DESolution
abstract AbstractSensitivitySolution
"`Mesh`: An abstract type which holds a (node,elem) pair and other information for a mesh"
abstract Mesh
"`Tableau`: Holds the information for a Runge-Kutta Tableau"

"`Tableau`: Holds the information for a Runge-Kutta Tableau"
abstract Tableau
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A mesh seems like an implementation detail which should go elsewhere.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then there should be a FEMMeshes.jl for holding meshing functionality common to PDEs.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, let's leave it here. (At some later stage, a PDE related interface package might make sense.)


"`ODERKTableau`: A Runge-Kutta Tableau for an ODE integrator"
abstract ODERKTableau <: Tableau

"`DEIntegrator`: A DifferentialEquations Integrator type, used to initiate a solver."
abstract DEIntegrator

abstract ParameterizedFunction <: Function
abstract SensitivityFunction <: ParameterizedFunction

include("utils.jl")
include("solutions/ode_solutions.jl")
include("algorithms/ode_algorithms.jl")
include("algorithms/ode_default_alg.jl")
include("solutions/solution_interface.jl")
include("tableaus.jl")
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't know what this does.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nothing anymore. Good find.

include("problems/ode_problems.jl")

function solve end
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we follow PR #2 then this is not needed.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How does that PR handle Sensitivity functions?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nevermind, I see. SensitivityFunction didn't really need to subtype ParameterizedFunction after all.


function solve(prob::DEProblem,args...;default_set=false,kwargs...)
if default_set == true && !isempty(args)
error("The chosen algorithm, "*string(args[1])*", does not exist.
Please verify that the appropriate solver package has been installed.")
elseif default_set == true
error("No algorithm is chosen but default_set=true.")
end
alg,extra_kwargs = default_algorithm(prob;kwargs...)
solve(prob,alg,args...;default_set=true,kwargs...,extra_kwargs...)
end
# function solve(prob::DEProblem,args...;default_set=false,kwargs...)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure how to do a default solver best. I think it has to be done package-wise: the first package providing Algs which gets loaded can set a default solver. But not sure how to implement it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's definitely not package-wise because the default solver for different cases is many times in different packages. For example, if you're trying to solve a stiff equation on Float64's, Sundials's CVODE_BDF and ODEInterface's radau tend to do best, while both of those package don't provide excellent methods for non-stiff equations, and don't work on odd number types.

Also, if it was package-wise it would clash.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this decision belongs into this interface package. I think this pkg should just provide an interface to hook into the JuliaDiffEq universe but not make judgment calls which solver is best for what. That is maybe something for DifferentialEquations.jl to do.

How about a system like so: DiffEqBase provides a dictionary (or some other datastructure) where each package hooking into DiffEqBase puts its solvers. Then there is some rating of the solvers on how suitable they are for one type of equation and say tolerances. Then the default algo will be picked from that list based on best suitability. I'll make an example PR.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The defaults code could just move to DifferentialEquations.jl if you think that's best.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Package-based default-choosing algorithms could still be available by the user passing in the package-wide abstract type?

# if default_set == true && !isempty(args)
# error("The chosen algorithm, "*string(args[1])*", does not exist.
# Please verify that the appropriate solver package has been installed.")
# elseif default_set == true
# error("No algorithm is chosen but default_set=true.")
# end
# alg,extra_kwargs = default_algorithm(prob;kwargs...)
# solve(prob,alg,args...;default_set=true,kwargs...,extra_kwargs...)
# end

export DEProblem, DESolution, DEParameters, AbstractDAEProblem, AbstractDDEProblem,
AbstractODEProblem, AbstractSDEProblem, DAESolution, DEIntegrator, Mesh,
AbstractODEProblem, AbstractSDEProblem, DAESolution,
Tableau, DESensitivity, AbstractODESolution, AbstractPoissonProblem,
AbstractHeatProblem, AbstractFEMSolution, ODERKTableau, ExplicitRKTableau,
ImplicitRKTableau, AbstractSDESolution, ParameterizedFunction,
AbstractSensitivitySolution, SensitivityFunction, DESensitivity
AbstractSensitivitySolution, SensitivityFunction, DESensitivity, solve

export tuples

export @def, numparameters
export numparameters

export jac_exists, invjac_exists, hes_exists, invhes_exists,
paramjac_exists, pfunc_exists, pderiv_exists

export ODEProblem, ODETestProblem, ODESolution, ODETestSolution,
build_ode_solution

# ODE Algorithms

export OrdinaryDiffEqAlgorithm, OrdinaryDiffEqAdaptiveAlgorithm,
Euler, Midpoint, RK4, ExplicitRK, BS3, BS5, DP5, DP5Threaded, Tsit5,
DP8, Vern6, Vern7, Vern8, TanYam7, TsitPap8, Vern9, ImplicitEuler,
Trapezoid, Rosenbrock23, Rosenbrock32, Feagin10, Feagin12, Feagin14

export default_algorithm

export ODEInterfaceAlgorithm, dopri5, dop853, odex, seulex, radau, radau5

export ODEIterAlgorithm, feuler, rk23, feh45, feh78, ModifiedRosenbrockIntegrator,
midpoint, heun, rk4, rk45

export ODEJLAlgorithm, ode1, ode23, ode45, ode78, ode23s, ode2_midpoint, ode2_heun,
ode4, ode45_fe

export SundialsAlgorithm, CVODE_BDF, CVODE_Adams

end # module
158 changes: 0 additions & 158 deletions src/algorithms/ode_algorithms.jl

This file was deleted.

32 changes: 0 additions & 32 deletions src/algorithms/ode_default_alg.jl

This file was deleted.

Empty file removed src/algorithms/sde_algorithms.jl
Empty file.
2 changes: 2 additions & 0 deletions src/tableaus.jl
Original file line number Diff line number Diff line change
@@ -1,3 +1,5 @@
# Maybe remove these?

"""
`ExplicitRKTableau`

Expand Down
8 changes: 0 additions & 8 deletions src/utils.jl
Original file line number Diff line number Diff line change
@@ -1,11 +1,3 @@
macro def(name, definition)
quote
macro $name()
esc($(Expr(:quote, definition)))
end
end
end

"""
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure what this does.

`numparameters(f)`

Expand Down