diff --git a/dev/alg_dev/benchmarks/index.html b/dev/alg_dev/benchmarks/index.html index 8e44869..748989d 100644 --- a/dev/alg_dev/benchmarks/index.html +++ b/dev/alg_dev/benchmarks/index.html @@ -17,4 +17,4 @@ wp = WorkPrecision(prob, DP5(), abstols, reltols; name = "Dormand-Prince 4/5")

If we want to plot many WorkPrecisions together in order to compare between algorithms, you can make a WorkPrecisionSet. To do so, you pass the setups into the function as well:

wp_set = WorkPrecisionSet(prob, tspan, abstols, reltols, setups; numruns = 2)
 setups = [Dict(:alg => RK4()); Dict(:alg => Euler()); Dict(:alg => BS3());
           Dict(:alg => Midpoint()); Dict(:alg => BS5()); Dict(:alg => DP5())]
-wp_set = WorkPrecisionSet(prob, abstols, reltols, setups; dt = 1 / 2^4, numruns = 2)

Both of these types have a plot recipe to produce a work-precision diagram, and a print which will show some relevant information.

+wp_set = WorkPrecisionSet(prob, abstols, reltols, setups; dt = 1 / 2^4, numruns = 2)

Both of these types have a plot recipe to produce a work-precision diagram, and a print which will show some relevant information.

diff --git a/dev/alg_dev/convergence/index.html b/dev/alg_dev/convergence/index.html index 5f37c8d..3a95e20 100644 --- a/dev/alg_dev/convergence/index.html +++ b/dev/alg_dev/convergence/index.html @@ -3,4 +3,4 @@ function gtag(){dataLayer.push(arguments);} gtag('js', new Date()); gtag('config', 'UA-90474609-3', {'page_path': location.pathname + location.search + location.hash}); -
Edit on GitHub

Convergence Simulations

The convergence simulation type is useful for deriving order of convergence estimates from a group of simulations. This object will automatically assemble error vectors into a more useful manner and provide plotting functionality. Convergence estimates are also given by pair-wise estimates.

One can automatically have DifferentialEquations.jl perform the error analysis by passing a ConvergenceSimulation a vector of solutions, or using one of the provided test_convergence functions. These will give order of convergence estimates and provide plotting functionality. This requires that the true solution was provided in the problem definition.

ConvergenceSimulations can either be created by passing the constructor the appropriate solution array or by using one of the provided test_convergence functions.

The ConvergenceSimulation Type

A type which holds the data from a convergence simulation.

Fields

  • solutions::Array{<:DESolution}: Holds all the PdeSolutions.

  • errors: Dictionary of the error calculations. Can contain:

    • h1Errors: Vector of the H1 errors.
    • l2Errors: Vector of the L2 errors.
    • maxErrors: Vector of the nodal maximum errors.
    • node2Errors: Vector of the nodal l2 errors.

  • N: The number of simulations.

  • auxdata: Auxiliary data of the convergence simulation. Entries can include:

    • dts: The dt's in the simulations.
    • dxs: The dx's in the simulations.
    • μs: The CFL μ's in the simulations.
    • νs: The CFL ν's in the simulations.

  • 𝒪est: Dictionary of order estimates. Can contain:

    • ConvEst_h1: The H1 error order of convergence estimate for the convergence simulation. Generated via log2(error[i+1]/error[i]). Thus only valid if generated by halving/doubling the dt/dx. If alternate scaling, modify by dividing of log(base,ConvEst_h1)
    • ConvEst_l2: The L2 error order of convergence estimate for the convergence simulation. Generated via log2(error[i+1]/error[i]). Thus only valid if generated by halving/doubling the dt/dx. If alternate scaling, modify by dividing of log(base,ConvEst_l2)
    • ConvEst_max: The nodal maximum error order of convergence estimate for the convergence simulation. Generated via log2(error[i+1]/error[i]). Thus only valid if generated by halving/doubling the dt/dx. If alternate scaling, modify by dividing of log(base,ConvEst_max)
    • ConvEst_node2: The nodal l2 error order of convergence estimate for the convergence simulation. Generated via log2(error[i+1]/error[i]). Thus only valid if generated by halving/doubling the dt/dx. If alternate scaling, modify by dividing of log(base,ConvEst_node2)

  • convergence_axis: The axis along which convergence is calculated. For example, if we calculate the dt convergence, convergence_axis is the dts used in the calculation.

Plot Functions

The plot functionality is provided by a Plots.jl recipe. What is plotted is a line series for each calculated error along the convergence axis. To plot a convergence simulation, simply use:

plot(sim::ConvergenceSimulation)

All of the functionality (keyword arguments) provided by Plots.jl are able to be used in this command. Please see the Plots.jl documentation for more information.

ODE

test_convergence(dts::AbstractArray,prob::AbstractODEProblem)

Tests the order of the time convergence of the given algorithm on the given problem solved over the given dts. Keyword arguments are passed to the ODE solver.

SDE

test_convergence(dts::AbstractArray,prob::AbstractSDEProblem)

Tests the strong order time convergence of the given algorithm on the given problem solved over the given dts. Keyword arguments are passed to the ODE solver. Except:

  • numMonte: The number of simulations for each dt. Default is 10000.

Order Estimation

calc𝒪estimates(error::Vector{Number})`

Computes the pairwise convergence estimate for a convergence test done by halving/doubling stepsizes via

log2(error[i+1]/error[i])

Returns the mean of the convergence estimates.

+
Edit on GitHub

Convergence Simulations

The convergence simulation type is useful for deriving order of convergence estimates from a group of simulations. This object will automatically assemble error vectors into a more useful manner and provide plotting functionality. Convergence estimates are also given by pair-wise estimates.

One can automatically have DifferentialEquations.jl perform the error analysis by passing a ConvergenceSimulation a vector of solutions, or using one of the provided test_convergence functions. These will give order of convergence estimates and provide plotting functionality. This requires that the true solution was provided in the problem definition.

ConvergenceSimulations can either be created by passing the constructor the appropriate solution array or by using one of the provided test_convergence functions.

The ConvergenceSimulation Type

A type which holds the data from a convergence simulation.

Fields

  • solutions::Array{<:DESolution}: Holds all the PdeSolutions.

  • errors: Dictionary of the error calculations. Can contain:

    • h1Errors: Vector of the H1 errors.
    • l2Errors: Vector of the L2 errors.
    • maxErrors: Vector of the nodal maximum errors.
    • node2Errors: Vector of the nodal l2 errors.

  • N: The number of simulations.

  • auxdata: Auxiliary data of the convergence simulation. Entries can include:

    • dts: The dt's in the simulations.
    • dxs: The dx's in the simulations.
    • μs: The CFL μ's in the simulations.
    • νs: The CFL ν's in the simulations.

  • 𝒪est: Dictionary of order estimates. Can contain:

    • ConvEst_h1: The H1 error order of convergence estimate for the convergence simulation. Generated via log2(error[i+1]/error[i]). Thus only valid if generated by halving/doubling the dt/dx. If alternate scaling, modify by dividing of log(base,ConvEst_h1)
    • ConvEst_l2: The L2 error order of convergence estimate for the convergence simulation. Generated via log2(error[i+1]/error[i]). Thus only valid if generated by halving/doubling the dt/dx. If alternate scaling, modify by dividing of log(base,ConvEst_l2)
    • ConvEst_max: The nodal maximum error order of convergence estimate for the convergence simulation. Generated via log2(error[i+1]/error[i]). Thus only valid if generated by halving/doubling the dt/dx. If alternate scaling, modify by dividing of log(base,ConvEst_max)
    • ConvEst_node2: The nodal l2 error order of convergence estimate for the convergence simulation. Generated via log2(error[i+1]/error[i]). Thus only valid if generated by halving/doubling the dt/dx. If alternate scaling, modify by dividing of log(base,ConvEst_node2)

  • convergence_axis: The axis along which convergence is calculated. For example, if we calculate the dt convergence, convergence_axis is the dts used in the calculation.

Plot Functions

The plot functionality is provided by a Plots.jl recipe. What is plotted is a line series for each calculated error along the convergence axis. To plot a convergence simulation, simply use:

plot(sim::ConvergenceSimulation)

All of the functionality (keyword arguments) provided by Plots.jl are able to be used in this command. Please see the Plots.jl documentation for more information.

ODE

test_convergence(dts::AbstractArray,prob::AbstractODEProblem)

Tests the order of the time convergence of the given algorithm on the given problem solved over the given dts. Keyword arguments are passed to the ODE solver.

SDE

test_convergence(dts::AbstractArray,prob::AbstractSDEProblem)

Tests the strong order time convergence of the given algorithm on the given problem solved over the given dts. Keyword arguments are passed to the ODE solver. Except:

  • numMonte: The number of simulations for each dt. Default is 10000.

Order Estimation

calc𝒪estimates(error::Vector{Number})`

Computes the pairwise convergence estimate for a convergence test done by halving/doubling stepsizes via

log2(error[i+1]/error[i])

Returns the mean of the convergence estimates.

diff --git a/dev/alg_dev/test_problems/index.html b/dev/alg_dev/test_problems/index.html index 293aa3c..37209b8 100644 --- a/dev/alg_dev/test_problems/index.html +++ b/dev/alg_dev/test_problems/index.html @@ -12,4 +12,4 @@ (T::TestSolution)(t) = T.interp(t) TestSolution(t, u) = TestSolution(t, u, nothing, false) TestSolution(t, u, interp) = TestSolution(t, u, interp, true) -TestSolution(interp::DESolution) = TestSolution(nothing, nothing, interp, true)

This acts like a solution. When used in conjunction with apprxtrue:

appxtrue(sol::AbstractODESolution, sol2::TestSolution)

you can use it to build a TestSolution from a problem (like ODETestSolution) which holds the errors If you only give it t and u, then it can only calculate the final error. If the TestSolution has an interpolation, it will define timeseries and dense errors.

(Note: I would like it so that way the timeseries error will be calculated on the times of sol.t in sol2.t which would act nicely with tstops and when interpolations don't exist, but haven't gotten to it!)

These can then be passed to other functionality. For example, the benchmarking functions allow one to set appxsol which is a TestSolution for the benchmark solution to calculate errors against, and error_estimate allows one to choose which error estimate to use in the benchmarking (defaults to :final).

DiffEqDevTools.appxtrue — Function

appxtrue(sol::AbstractODESolution,sol2::TestSolution)

Uses the interpolant from the higher order solution sol2 to approximate errors for sol. If sol2 has no interpolant, only the final error is calculated.

appxtrue(sol::AbstractODESolution,sol2::AbstractODESolution)

Uses the interpolant from the higher order solution sol2 to approximate errors for sol. If sol2 has no interpolant, only the final error is calculated.

+TestSolution(interp::DESolution) = TestSolution(nothing, nothing, interp, true)

This acts like a solution. When used in conjunction with apprxtrue:

appxtrue(sol::AbstractODESolution, sol2::TestSolution)

you can use it to build a TestSolution from a problem (like ODETestSolution) which holds the errors If you only give it t and u, then it can only calculate the final error. If the TestSolution has an interpolation, it will define timeseries and dense errors.

(Note: I would like it so that way the timeseries error will be calculated on the times of sol.t in sol2.t which would act nicely with tstops and when interpolations don't exist, but haven't gotten to it!)

These can then be passed to other functionality. For example, the benchmarking functions allow one to set appxsol which is a TestSolution for the benchmark solution to calculate errors against, and error_estimate allows one to choose which error estimate to use in the benchmarking (defaults to :final).

DiffEqDevTools.appxtrue — Function

appxtrue(sol::AbstractODESolution,sol2::TestSolution)

Uses the interpolant from the higher order solution sol2 to approximate errors for sol. If sol2 has no interpolant, only the final error is calculated.

appxtrue(sol::AbstractODESolution,sol2::AbstractODESolution)

Uses the interpolant from the higher order solution sol2 to approximate errors for sol. If sol2 has no interpolant, only the final error is calculated.

diff --git a/dev/assets/Manifest.toml b/dev/assets/Manifest.toml index fb24710..312ba7e 100644 --- a/dev/assets/Manifest.toml +++ b/dev/assets/Manifest.toml @@ -5,20 +5,41 @@ manifest_format = "2.0" project_hash = "ee62ad5c0972406c2fc92daacb89f4d453339bcf" [[deps.ADTypes]] -git-tree-sha1 = "41c37aa88889c171f1300ceac1313c06e891d245" +git-tree-sha1 = "016833eb52ba2d6bea9fcb50ca295980e728ee24" uuid = "47edcb42-4c32-4615-8424-f2b9edc5f35b" -version = "0.2.6" +version = "0.2.7" [[deps.ANSIColoredPrinters]] git-tree-sha1 = "574baf8110975760d391c710b6341da1afa48d8c" uuid = "a4c015fc-c6ff-483c-b24f-f7ea428134e9" version = "0.0.1" +[[deps.Accessors]] +deps = ["CompositionsBase", "ConstructionBase", "Dates", "InverseFunctions", "LinearAlgebra", "MacroTools", "Markdown", "Test"] +git-tree-sha1 = "c0d491ef0b135fd7d63cbc6404286bc633329425" +uuid = "7d9f7c33-5ae7-4f3b-8dc6-eff91059b697" +version = "0.1.36" + + [deps.Accessors.extensions] + AccessorsAxisKeysExt = "AxisKeys" + AccessorsIntervalSetsExt = "IntervalSets" + AccessorsStaticArraysExt = "StaticArrays" + AccessorsStructArraysExt = "StructArrays" + AccessorsUnitfulExt = "Unitful" + + [deps.Accessors.weakdeps] + AxisKeys = "94b1ba4f-4ee9-5380-92f1-94cde586c3c5" + IntervalSets = "8197267c-284f-5f27-9208-e0e47529a953" + Requires = "ae029012-a4dd-5104-9daa-d747884805df" + StaticArrays = "90137ffa-7385-5640-81b9-e52037218182" + StructArrays = "09ab397b-f2b6-538f-b94a-2f83cf4a842a" + Unitful = "1986cc42-f94f-5a68-af5c-568840ba703d" + [[deps.Adapt]] deps = ["LinearAlgebra", "Requires"] -git-tree-sha1 = "0fb305e0253fd4e833d486914367a2ee2c2e78d0" +git-tree-sha1 = "6a55b747d1812e699320963ffde36f1ebdda4099" uuid = "79e6a3ab-5dfb-504d-930d-738a2a938a0e" -version = "4.0.1" +version = "4.0.4" weakdeps = ["StaticArrays"] [deps.Adapt.extensions] @@ -35,15 +56,16 @@ uuid = "ec485272-7323-5ecc-a04f-4719b315124d" version = "0.2.0" [[deps.ArrayInterface]] -deps = ["Adapt", "LinearAlgebra", "Requires", "SparseArrays", "SuiteSparse"] -git-tree-sha1 = "881e43f1aa014a6f75c8fc0847860e00a1500846" +deps = ["Adapt", "LinearAlgebra", "SparseArrays", "SuiteSparse"] +git-tree-sha1 = "44691067188f6bd1b2289552a23e4b7572f4528d" uuid = "4fba245c-0d91-5ea0-9b3e-6abc04ee57a9" -version = "7.8.0" +version = "7.9.0" [deps.ArrayInterface.extensions] ArrayInterfaceBandedMatricesExt = "BandedMatrices" ArrayInterfaceBlockBandedMatricesExt = "BlockBandedMatrices" ArrayInterfaceCUDAExt = "CUDA" + ArrayInterfaceChainRulesExt = "ChainRules" ArrayInterfaceGPUArraysCoreExt = "GPUArraysCore" ArrayInterfaceReverseDiffExt = "ReverseDiff" ArrayInterfaceStaticArraysCoreExt = "StaticArraysCore" @@ -53,6 +75,7 @@ version = "7.8.0" BandedMatrices = "aae01518-5342-5314-be14-df237901396f" BlockBandedMatrices = "ffab5731-97b5-5995-9138-79e8c1846df0" CUDA = "052768ef-5323-5732-b1bb-66c8b64840ba" + ChainRules = "082447d4-558c-5d27-93f4-14fc19e9eca2" GPUArraysCore = "46192b85-c4d5-4398-a991-12ede77f4527" ReverseDiff = "37e2e3b7-166d-5795-8a7a-e32c996b4267" StaticArraysCore = "1e83bf80-4336-4d27-bf5d-d5a4f845583c" @@ -60,9 +83,9 @@ version = "7.8.0" [[deps.ArrayLayouts]] deps = ["FillArrays", "LinearAlgebra"] -git-tree-sha1 = "64d582bcb9c93ac741234789eeb4f16812413efb" +git-tree-sha1 = "6404a564c24a994814106c374bec893195e19bac" uuid = "4c555306-a7a7-4459-81d9-ec55ddd5c99a" -version = "1.6.0" +version = "1.8.0" weakdeps = ["SparseArrays"] [deps.ArrayLayouts.extensions] @@ -74,24 +97,12 @@ uuid = "56f22d72-fd6d-98f1-02f0-08ddc0907c33" [[deps.Base64]] uuid = "2a0f44e3-6c83-55bd-87e4-b1978d98bd5f" -[[deps.BenchmarkTools]] -deps = ["JSON", "Logging", "Printf", "Profile", "Statistics", "UUIDs"] -git-tree-sha1 = "f1dff6729bc61f4d49e140da1af55dcd1ac97b2f" -uuid = "6e4b80f9-dd63-53aa-95a3-0cdb28fa8baf" -version = "1.5.0" - [[deps.BitTwiddlingConvenienceFunctions]] deps = ["Static"] git-tree-sha1 = "0c5f81f47bbbcf4aea7b2959135713459170798b" uuid = "62783981-4cbd-42fc-bca8-16325de8dc4b" version = "0.1.5" -[[deps.Bzip2_jll]] -deps = ["Artifacts", "JLLWrappers", "Libdl", "Pkg"] -git-tree-sha1 = "9e2a6b69137e6969bab0152632dcb3bc108c8bdd" -uuid = "6e34b625-4abd-537c-b88f-471c36dfa7a0" -version = "1.0.8+1" - [[deps.CPUSummary]] deps = ["CpuId", "IfElse", "PrecompileTools", "Static"] git-tree-sha1 = "601f7e7b3d36f18790e2caf83a882d88e9b71ff1" @@ -120,18 +131,6 @@ git-tree-sha1 = "70232f82ffaab9dc52585e0dd043b5e0c6b714f1" uuid = "fb6a15b2-703c-40df-9091-08a04967cfa9" version = "0.1.12" -[[deps.CodecBzip2]] -deps = ["Bzip2_jll", "Libdl", "TranscodingStreams"] -git-tree-sha1 = "9b1ca1aa6ce3f71b3d1840c538a8210a043625eb" -uuid = "523fee87-0ab8-5b00-afb7-3ecf72e48cfd" -version = "0.8.2" - -[[deps.CodecZlib]] -deps = ["TranscodingStreams", "Zlib_jll"] -git-tree-sha1 = "59939d8a997469ee05c4b4944560a820f9ba0d73" -uuid = "944b1d66-785c-5afd-91f1-9de20f533193" -version = "0.7.4" - [[deps.CommonSolve]] git-tree-sha1 = "0eee5eb66b1cf62cd6ad1b460238e60e4b09400c" uuid = "38540f10-b2f7-11e9-35d8-d573e4eb0ff2" @@ -158,6 +157,15 @@ deps = ["Artifacts", "Libdl"] uuid = "e66e0078-7015-5450-92f7-15fbd957f2ae" version = "1.1.0+0" +[[deps.CompositionsBase]] +git-tree-sha1 = "802bb88cd69dfd1509f6670416bd4434015693ad" +uuid = "a33af91c-f02d-484b-be07-31d278c5ca2b" +version = "0.1.2" +weakdeps = ["InverseFunctions"] + + [deps.CompositionsBase.extensions] + CompositionsBaseInverseFunctionsExt = "InverseFunctions" + [[deps.ConcreteStructs]] git-tree-sha1 = "f749037478283d372048690eb3b5f92a79432b34" uuid = "2569d6c7-a4a2-43d3-a901-331e8e4be471" @@ -165,9 +173,9 @@ version = "0.2.3" [[deps.ConstructionBase]] deps = ["LinearAlgebra"] -git-tree-sha1 = "c53fc348ca4d40d7b371e71fd52251839080cbc9" +git-tree-sha1 = "260fd2400ed2dab602a7c15cf10c1933c59930a2" uuid = "187b0558-2788-49d3-abe0-74a17ed4e7c9" -version = "1.5.4" +version = "1.5.5" [deps.ConstructionBase.extensions] ConstructionBaseIntervalSetsExt = "IntervalSets" @@ -190,9 +198,9 @@ version = "1.16.0" [[deps.DataStructures]] deps = ["Compat", "InteractiveUtils", "OrderedCollections"] -git-tree-sha1 = "1fb174f0d48fe7d142e1109a10636bc1d14f5ac2" +git-tree-sha1 = "0f4b5d62a88d8f59003e43c25a8a90de9eb76317" uuid = "864edb3b-99cc-5e75-8d2d-829cb0a9cfe8" -version = "0.18.17" +version = "0.18.18" [[deps.DataValueInterfaces]] git-tree-sha1 = "bfc1187b79289637fa0ef6d4436ebdfe6905cbd6" @@ -204,10 +212,10 @@ deps = ["Printf"] uuid = "ade2ca70-3891-5945-98fb-dc099432e06a" [[deps.DiffEqBase]] -deps = ["ArrayInterface", "DataStructures", "DocStringExtensions", "EnumX", "EnzymeCore", "FastBroadcast", "ForwardDiff", "FunctionWrappers", "FunctionWrappersWrappers", "LinearAlgebra", "Logging", "Markdown", "MuladdMacro", "Parameters", "PreallocationTools", "PrecompileTools", "Printf", "RecursiveArrayTools", "Reexport", "SciMLBase", "SciMLOperators", "Setfield", "SparseArrays", "Static", "StaticArraysCore", "Statistics", "Tricks", "TruncatedStacktraces"] -git-tree-sha1 = "b19b2bb1ecd1271334e4b25d605e50f75e68fcae" +deps = ["ArrayInterface", "ConcreteStructs", "DataStructures", "DocStringExtensions", "EnumX", "EnzymeCore", "FastBroadcast", "FastClosures", "ForwardDiff", "FunctionWrappers", "FunctionWrappersWrappers", "LinearAlgebra", "Logging", "Markdown", "MuladdMacro", "Parameters", "PreallocationTools", "PrecompileTools", "Printf", "RecursiveArrayTools", "Reexport", "SciMLBase", "SciMLOperators", "Setfield", "SparseArrays", "Static", "StaticArraysCore", "Statistics", "Tricks", "TruncatedStacktraces"] +git-tree-sha1 = "4fa023dbb15b3485426bbc6c43e030c14250d664" uuid = "2b5f629d-d688-5b77-993f-72d75c75574e" -version = "6.148.0" +version = "6.149.0" [deps.DiffEqBase.extensions] DiffEqBaseChainRulesCoreExt = "ChainRulesCore" @@ -328,9 +336,9 @@ uuid = "4e289a0a-7415-4d19-859d-a7e5c4648b56" version = "1.0.4" [[deps.EnzymeCore]] -git-tree-sha1 = "59c44d8fbc651c0395d8a6eda64b05ce316f58b4" +git-tree-sha1 = "1bc328eec34ffd80357f84a84bb30e4374e9bd60" uuid = "f151be2c-9106-41f4-ab19-57ee4f262869" -version = "0.6.5" +version = "0.6.6" weakdeps = ["Adapt"] [deps.EnzymeCore.extensions] @@ -381,9 +389,9 @@ weakdeps = ["PDMats", "SparseArrays", "Statistics"] [[deps.FiniteDiff]] deps = ["ArrayInterface", "LinearAlgebra", "Requires", "Setfield", "SparseArrays"] -git-tree-sha1 = "73d1214fec245096717847c62d389a5d2ac86504" +git-tree-sha1 = "bc0c5092d6caaea112d3c8e3b238d61563c58d5f" uuid = "6a86dc24-6348-571c-b903-95158fe2bd41" -version = "2.22.0" +version = "2.23.0" [deps.FiniteDiff.extensions] FiniteDiffBandedMatricesExt = "BandedMatrices" @@ -396,9 +404,9 @@ version = "2.22.0" StaticArrays = "90137ffa-7385-5640-81b9-e52037218182" [[deps.Format]] -git-tree-sha1 = "f3cf88025f6d03c194d73f5d13fee9004a108329" +git-tree-sha1 = "9c68794ef81b08086aeb32eeaf33531668d5f5fc" uuid = "1fa38f19-a742-5d3f-a2b9-30dd87b9d5f8" -version = "1.3.6" +version = "1.3.7" [[deps.ForwardDiff]] deps = ["CommonSubexpressions", "DiffResults", "DiffRules", "LinearAlgebra", "LogExpFunctions", "NaNMath", "Preferences", "Printf", "Random", "SpecialFunctions"] @@ -433,9 +441,9 @@ version = "0.1.6" [[deps.GenericSchur]] deps = ["LinearAlgebra", "Printf"] -git-tree-sha1 = "fb69b2a645fa69ba5f474af09221b9308b160ce6" +git-tree-sha1 = "af49a0851f8113fcfae2ef5027c6d49d0acec39b" uuid = "c145ed77-6b09-5dd9-b285-bf645a82121e" -version = "0.5.3" +version = "0.5.4" [[deps.Graphs]] deps = ["ArnoldiMethod", "Compat", "DataStructures", "Distributed", "Inflate", "LinearAlgebra", "Random", "SharedArrays", "SimpleTraits", "SparseArrays", "Statistics"] @@ -481,6 +489,16 @@ version = "2024.0.2+0" deps = ["Markdown"] uuid = "b77e0a4c-d291-57a0-90e8-8db25a27a240" +[[deps.InverseFunctions]] +deps = ["Test"] +git-tree-sha1 = "896385798a8d49a255c398bd49162062e4a4c435" +uuid = "3587e190-3f89-42d0-90ee-14403ec27112" +version = "0.1.13" +weakdeps = ["Dates"] + + [deps.InverseFunctions.extensions] + DatesExt = "Dates" + [[deps.IrrationalConstants]] git-tree-sha1 = "630b497eafcc20001bba38a4651b327dcfc491d2" uuid = "92d709cd-6900-40b7-9082-c6be49f344b6" @@ -592,10 +610,10 @@ deps = ["Libdl", "OpenBLAS_jll", "libblastrampoline_jll"] uuid = "37e2e46d-f89d-539d-b4ee-838fcccc9c8e" [[deps.LinearSolve]] -deps = ["ArrayInterface", "ChainRulesCore", "ConcreteStructs", "DocStringExtensions", "EnumX", "FastLapackInterface", "GPUArraysCore", "InteractiveUtils", "KLU", "Krylov", "Libdl", "LinearAlgebra", "MKL_jll", "Markdown", "PrecompileTools", "Preferences", "RecursiveFactorization", "Reexport", "SciMLBase", "SciMLOperators", "Setfield", "SparseArrays", "Sparspak", "StaticArraysCore", "UnPack"] -git-tree-sha1 = "b2cc25978eb8efda63ee5786f2ed72c35a711b61" +deps = ["ArrayInterface", "ChainRulesCore", "ConcreteStructs", "DocStringExtensions", "EnumX", "FastLapackInterface", "GPUArraysCore", "InteractiveUtils", "KLU", "Krylov", "LazyArrays", "Libdl", "LinearAlgebra", "MKL_jll", "Markdown", "PrecompileTools", "Preferences", "RecursiveFactorization", "Reexport", "SciMLBase", "SciMLOperators", "Setfield", "SparseArrays", "Sparspak", "StaticArraysCore", "UnPack"] +git-tree-sha1 = "775e5e5d9ace42ef8deeb236587abc69e70dc455" uuid = "7ed4a6bd-45f5-4d41-b270-4a48e9bafcae" -version = "2.26.0" +version = "2.28.0" [deps.LinearSolve.extensions] LinearSolveBandedMatricesExt = "BandedMatrices" @@ -647,9 +665,9 @@ uuid = "56ddb016-857b-54e1-b83d-db4d58db5568" [[deps.LoopVectorization]] deps = ["ArrayInterface", "CPUSummary", "CloseOpenIntervals", "DocStringExtensions", "HostCPUFeatures", "IfElse", "LayoutPointers", "LinearAlgebra", "OffsetArrays", "PolyesterWeave", "PrecompileTools", "SIMDTypes", "SLEEFPirates", "Static", "StaticArrayInterface", "ThreadingUtilities", "UnPack", "VectorizationBase"] -git-tree-sha1 = "0f5648fbae0d015e3abe5867bca2b362f67a5894" +git-tree-sha1 = "a13f3be5d84b9c95465d743c82af0b094ef9c2e2" uuid = "bdcacae8-1622-11e9-2a5c-532679323890" -version = "0.12.166" +version = "0.12.169" weakdeps = ["ChainRulesCore", "ForwardDiff", "SpecialFunctions"] [deps.LoopVectorization.extensions] @@ -677,12 +695,6 @@ version = "0.1.8" deps = ["Base64"] uuid = "d6f4376e-aef5-505a-96c1-9c027394607a" -[[deps.MathOptInterface]] -deps = ["BenchmarkTools", "CodecBzip2", "CodecZlib", "DataStructures", "ForwardDiff", "JSON", "LinearAlgebra", "MutableArithmetics", "NaNMath", "OrderedCollections", "PrecompileTools", "Printf", "SparseArrays", "SpecialFunctions", "Test", "Unicode"] -git-tree-sha1 = "679c1aec6934d322783bd15db4d18f898653be4f" -uuid = "b8f27783-ece8-5eb3-8dc8-9495eed66fee" -version = "1.27.0" - [[deps.MatrixFactorizations]] deps = ["ArrayLayouts", "LinearAlgebra", "Printf", "Random"] git-tree-sha1 = "78f6e33434939b0ac9ba1df81e6d005ee85a7396" @@ -691,9 +703,9 @@ version = "2.1.0" [[deps.MaybeInplace]] deps = ["ArrayInterface", "LinearAlgebra", "MacroTools", "SparseArrays"] -git-tree-sha1 = "a85c6a98c9e5a2a7046bc1bb89f28a3241e1de4d" +git-tree-sha1 = "b1f2f92feb0bc201e91c155ef575bcc7d9cc3526" uuid = "bb5d69b7-63fc-4a16-80bd-7e42200c7bdb" -version = "0.1.1" +version = "0.1.2" [[deps.MbedTLS_jll]] deps = ["Artifacts", "Libdl"] @@ -718,12 +730,6 @@ git-tree-sha1 = "cac9cc5499c25554cba55cd3c30543cff5ca4fab" uuid = "46d2c3a1-f734-5fdb-9937-b9b9aeba4221" version = "0.2.4" -[[deps.MutableArithmetics]] -deps = ["LinearAlgebra", "SparseArrays", "Test"] -git-tree-sha1 = "302fd161eb1c439e4115b51ae456da4e9984f130" -uuid = "d8a4904e-b15c-11e9-3269-09a3773c0cb0" -version = "1.4.1" - [[deps.NLSolversBase]] deps = ["DiffResults", "Distributed", "FiniteDiff", "ForwardDiff"] git-tree-sha1 = "a0b464d183da839699f4c79e7606d9d186ec172c" @@ -748,9 +754,9 @@ version = "1.2.0" [[deps.NonlinearSolve]] deps = ["ADTypes", "ArrayInterface", "ConcreteStructs", "DiffEqBase", "FastBroadcast", "FastClosures", "FiniteDiff", "ForwardDiff", "LazyArrays", "LineSearches", "LinearAlgebra", "LinearSolve", "MaybeInplace", "PrecompileTools", "Preferences", "Printf", "RecursiveArrayTools", "Reexport", "SciMLBase", "SimpleNonlinearSolve", "SparseArrays", "SparseDiffTools", "StaticArraysCore", "TimerOutputs"] -git-tree-sha1 = "f409959245f04c8004bd3711915d71c93b2043f7" +git-tree-sha1 = "c32743c2321e99adf8bbe03145ce8e2bf2fcfbf9" uuid = "8913a72c-1f9b-4ce2-8d82-65094dcecaec" -version = "3.7.3" +version = "3.9.0" [deps.NonlinearSolve.extensions] NonlinearSolveBandedMatricesExt = "BandedMatrices" @@ -804,10 +810,16 @@ uuid = "efe28fd5-8261-553b-a9e1-b2916fc3738e" version = "0.5.5+0" [[deps.Optim]] -deps = ["Compat", "FillArrays", "ForwardDiff", "LineSearches", "LinearAlgebra", "MathOptInterface", "NLSolversBase", "NaNMath", "Parameters", "PositiveFactorizations", "Printf", "SparseArrays", "StatsBase"] -git-tree-sha1 = "d024bfb56144d947d4fafcd9cb5cafbe3410b133" +deps = ["Compat", "FillArrays", "ForwardDiff", "LineSearches", "LinearAlgebra", "NLSolversBase", "NaNMath", "PackageExtensionCompat", "Parameters", "PositiveFactorizations", "Printf", "SparseArrays", "StatsBase"] +git-tree-sha1 = "d1223e69af90b6d26cea5b6f3b289b3148ba702c" uuid = "429524aa-4258-5aef-a3af-852621145aeb" -version = "1.9.2" +version = "1.9.3" + + [deps.Optim.extensions] + OptimMOIExt = "MathOptInterface" + + [deps.Optim.weakdeps] + MathOptInterface = "b8f27783-ece8-5eb3-8dc8-9495eed66fee" [[deps.OrderedCollections]] git-tree-sha1 = "dfdf5519f235516220579f949664f1bf44e741c5" @@ -816,9 +828,9 @@ version = "1.6.3" [[deps.OrdinaryDiffEq]] deps = ["ADTypes", "Adapt", "ArrayInterface", "DataStructures", "DiffEqBase", "DocStringExtensions", "ExponentialUtilities", "FastBroadcast", "FastClosures", "FillArrays", "FiniteDiff", "ForwardDiff", "FunctionWrappersWrappers", "IfElse", "InteractiveUtils", "LineSearches", "LinearAlgebra", "LinearSolve", "Logging", "MacroTools", "MuladdMacro", "NonlinearSolve", "Polyester", "PreallocationTools", "PrecompileTools", "Preferences", "RecursiveArrayTools", "Reexport", "SciMLBase", "SciMLOperators", "SimpleNonlinearSolve", "SimpleUnPack", "SparseArrays", "SparseDiffTools", "StaticArrayInterface", "StaticArrays", "TruncatedStacktraces"] -git-tree-sha1 = "287159684e32db56c82dbf545004a7884c6e5198" +git-tree-sha1 = "91079af18db922354197eeae2a17b177079e24c1" uuid = "1dea7af3-3e70-54e6-95c3-0bf5283fa5ed" -version = "6.74.0" +version = "6.74.1" [[deps.PDMats]] deps = ["LinearAlgebra", "SparseArrays", "SuiteSparse"] @@ -857,9 +869,9 @@ version = "0.4.4" [[deps.Polyester]] deps = ["ArrayInterface", "BitTwiddlingConvenienceFunctions", "CPUSummary", "IfElse", "ManualMemory", "PolyesterWeave", "Requires", "Static", "StaticArrayInterface", "StrideArraysCore", "ThreadingUtilities"] -git-tree-sha1 = "fca25670784a1ae44546bcb17288218310af2778" +git-tree-sha1 = "09f59c6dda37c7f73efddc5bdf6f92bc940eb484" uuid = "f517fe37-dbe3-4b94-8317-1923a5111588" -version = "0.7.9" +version = "0.7.12" [[deps.PolyesterWeave]] deps = ["BitTwiddlingConvenienceFunctions", "CPUSummary", "IfElse", "Static", "ThreadingUtilities"] @@ -887,9 +899,9 @@ version = "0.4.20" [[deps.PrecompileTools]] deps = ["Preferences"] -git-tree-sha1 = "03b4c25b43cb84cee5c90aa9b5ea0a78fd848d2f" +git-tree-sha1 = "5aa36f7049a63a1528fe8f7c3f2113413ffd4e1f" uuid = "aea7be01-6a6a-4083-8856-8a6e6704d82a" -version = "1.2.0" +version = "1.2.1" [[deps.Preferences]] deps = ["TOML"] @@ -901,10 +913,6 @@ version = "1.4.3" deps = ["Unicode"] uuid = "de0858da-6303-5e67-8744-51eddeeeb8d7" -[[deps.Profile]] -deps = ["Printf"] -uuid = "9abbd945-dff8-562f-b5e8-e1ebf5ef1b79" - [[deps.QuadGK]] deps = ["DataStructures", "LinearAlgebra"] git-tree-sha1 = "9b23c31e76e333e6fb4c1595ae6afa74966a729e" @@ -939,9 +947,9 @@ version = "1.3.4" [[deps.RecursiveArrayTools]] deps = ["Adapt", "ArrayInterface", "DocStringExtensions", "GPUArraysCore", "IteratorInterfaceExtensions", "LinearAlgebra", "RecipesBase", "SparseArrays", "StaticArraysCore", "Statistics", "SymbolicIndexingInterface", "Tables"] -git-tree-sha1 = "dc428bb59c20dafd1ec500c3432b9e3d7e78e7f3" +git-tree-sha1 = "d8f131090f2e44b145084928856a561c83f43b27" uuid = "731186ca-8d62-57ce-b412-fbd966d074cd" -version = "3.10.1" +version = "3.13.0" [deps.RecursiveArrayTools.extensions] RecursiveArrayToolsFastBroadcastExt = "FastBroadcast" @@ -1030,10 +1038,10 @@ uuid = "476501e8-09a2-5ece-8869-fb82de89a1fa" version = "0.6.42" [[deps.SciMLBase]] -deps = ["ADTypes", "ArrayInterface", "CommonSolve", "ConstructionBase", "Distributed", "DocStringExtensions", "EnumX", "FunctionWrappersWrappers", "IteratorInterfaceExtensions", "LinearAlgebra", "Logging", "Markdown", "PrecompileTools", "Preferences", "Printf", "RecipesBase", "RecursiveArrayTools", "Reexport", "RuntimeGeneratedFunctions", "SciMLOperators", "StaticArraysCore", "Statistics", "SymbolicIndexingInterface", "Tables"] -git-tree-sha1 = "3a281a9fce9cd62b849d7f16e412933a5fe755cb" +deps = ["ADTypes", "ArrayInterface", "CommonSolve", "ConstructionBase", "Distributed", "DocStringExtensions", "EnumX", "FunctionWrappersWrappers", "IteratorInterfaceExtensions", "LinearAlgebra", "Logging", "Markdown", "PrecompileTools", "Preferences", "Printf", "RecipesBase", "RecursiveArrayTools", "Reexport", "RuntimeGeneratedFunctions", "SciMLOperators", "SciMLStructures", "StaticArraysCore", "Statistics", "SymbolicIndexingInterface", "Tables"] +git-tree-sha1 = "d15c65e25615272e1b1c5edb1d307484c7942824" uuid = "0bca4576-84f4-4d90-8ffe-ffa030f20462" -version = "2.29.0" +version = "2.31.0" [deps.SciMLBase.extensions] SciMLBaseChainRulesCoreExt = "ChainRulesCore" @@ -1060,6 +1068,11 @@ git-tree-sha1 = "10499f619ef6e890f3f4a38914481cc868689cd5" uuid = "c0aeaf25-5076-4817-a8d5-81caf7dfa961" version = "0.3.8" +[[deps.SciMLStructures]] +git-tree-sha1 = "5833c10ce83d690c124beedfe5f621b50b02ba4d" +uuid = "53ae85a6-f571-4167-b2af-e1d143709226" +version = "1.1.0" + [[deps.Serialization]] uuid = "9e88b42a-f829-5b0c-bbe9-9e923198166b" @@ -1074,20 +1087,26 @@ deps = ["Distributed", "Mmap", "Random", "Serialization"] uuid = "1a1011a3-84de-559e-8e89-a11a2f7dc383" [[deps.SimpleNonlinearSolve]] -deps = ["ADTypes", "ArrayInterface", "ConcreteStructs", "DiffEqBase", "FastClosures", "FiniteDiff", "ForwardDiff", "LinearAlgebra", "MaybeInplace", "PrecompileTools", "Reexport", "SciMLBase", "StaticArraysCore"] -git-tree-sha1 = "873a1bf90744acfa615e45cd5dddfd0ee89a094f" +deps = ["ADTypes", "ArrayInterface", "ConcreteStructs", "DiffEqBase", "DiffResults", "FastClosures", "FiniteDiff", "ForwardDiff", "LinearAlgebra", "MaybeInplace", "PrecompileTools", "Reexport", "SciMLBase", "StaticArraysCore"] +git-tree-sha1 = "d4c17fc60bf5f8f2be02777c4836878f27ac7b9b" uuid = "727e6d20-b764-4bd8-a329-72de5adea6c7" -version = "1.5.0" +version = "1.7.0" [deps.SimpleNonlinearSolve.extensions] SimpleNonlinearSolveChainRulesCoreExt = "ChainRulesCore" SimpleNonlinearSolvePolyesterForwardDiffExt = "PolyesterForwardDiff" + SimpleNonlinearSolveReverseDiffExt = "ReverseDiff" SimpleNonlinearSolveStaticArraysExt = "StaticArrays" + SimpleNonlinearSolveTrackerExt = "Tracker" + SimpleNonlinearSolveZygoteExt = "Zygote" [deps.SimpleNonlinearSolve.weakdeps] ChainRulesCore = "d360d2e6-b24c-11e9-a2a3-2a2ae2dbcce4" PolyesterForwardDiff = "98d1487c-24ca-40b6-b7ab-df2af84e126b" + ReverseDiff = "37e2e3b7-166d-5795-8a7a-e32c996b4267" StaticArrays = "90137ffa-7385-5640-81b9-e52037218182" + Tracker = "9f7883ad-71c0-57eb-9f7f-b5c9e6d3789c" + Zygote = "e88e6eb3-aa80-5325-afca-941959d7151f" [[deps.SimpleTraits]] deps = ["InteractiveUtils", "MacroTools"] @@ -1205,15 +1224,12 @@ deps = ["HypergeometricFunctions", "IrrationalConstants", "LogExpFunctions", "Re git-tree-sha1 = "cef0472124fab0695b58ca35a77c6fb942fdab8a" uuid = "4c63d2b9-4356-54db-8cca-17b64c39e42c" version = "1.3.1" +weakdeps = ["ChainRulesCore", "InverseFunctions"] [deps.StatsFuns.extensions] StatsFunsChainRulesCoreExt = "ChainRulesCore" StatsFunsInverseFunctionsExt = "InverseFunctions" - [deps.StatsFuns.weakdeps] - ChainRulesCore = "d360d2e6-b24c-11e9-a2a3-2a2ae2dbcce4" - InverseFunctions = "3587e190-3f89-42d0-90ee-14403ec27112" - [[deps.StrideArraysCore]] deps = ["ArrayInterface", "CloseOpenIntervals", "IfElse", "LayoutPointers", "ManualMemory", "SIMDTypes", "Static", "StaticArrayInterface", "ThreadingUtilities"] git-tree-sha1 = "d6415f66f3d89c615929af907fdc6a3e17af0d8c" @@ -1243,9 +1259,10 @@ uuid = "bea87d4a-7f5b-5778-9afe-8cc45184846c" version = "7.2.1+1" [[deps.SymbolicIndexingInterface]] -git-tree-sha1 = "251bb311585143931a306175c3b7ced220300578" +deps = ["Accessors", "ArrayInterface", "MacroTools", "RuntimeGeneratedFunctions", "StaticArraysCore"] +git-tree-sha1 = "4b7f4c80449d8baae8857d55535033981862619c" uuid = "2efcf032-c050-4f8e-a9bb-153293bab1f5" -version = "0.3.8" +version = "0.3.15" [[deps.TOML]] deps = ["Dates"] @@ -1285,20 +1302,11 @@ git-tree-sha1 = "f548a9e9c490030e545f72074a41edfd0e5bcdd7" uuid = "a759f4b9-e2f1-59dc-863e-4aeb61b1ea8f" version = "0.5.23" -[[deps.TranscodingStreams]] -git-tree-sha1 = "3caa21522e7efac1ba21834a03734c57b4611c7e" -uuid = "3bb67fe8-82b1-5028-8e26-92a6c54297fa" -version = "0.10.4" -weakdeps = ["Random", "Test"] - - [deps.TranscodingStreams.extensions] - TestExt = ["Test", "Random"] - [[deps.TriangularSolve]] deps = ["CloseOpenIntervals", "IfElse", "LayoutPointers", "LinearAlgebra", "LoopVectorization", "Polyester", "Static", "VectorizationBase"] -git-tree-sha1 = "fadebab77bf3ae041f77346dd1c290173da5a443" +git-tree-sha1 = "7ee8ed8904e7dd5d31bb46294ef5644d9e2e44e4" uuid = "d5829a12-d9aa-46ab-831f-fb7c9ab06edf" -version = "0.1.20" +version = "0.1.21" [[deps.Tricks]] git-tree-sha1 = "eae1bb484cd63b36999ee58be2de6c178105112f" diff --git a/dev/contributing/adding_algorithms/index.html b/dev/contributing/adding_algorithms/index.html index 6f70595..893d1cf 100644 --- a/dev/contributing/adding_algorithms/index.html +++ b/dev/contributing/adding_algorithms/index.html @@ -209,4 +209,4 @@ # Example of a good one! sim = test_convergence(dts, prob, BS3()) sim.𝒪est[:final] -plot(sim)

Adding new exponential algorithms

The exponential algorithms follow the same recipe as the general algorithms, but there are automation utilities that make this easier. It is recommended that you refer to one of the model algorithms for reference:

The first two classes support two modes of operation: operator caching and Krylov approximation. The perform_step! method in perform_step/exponential_rk_perform_step.jl, as a result, is split into two branches depending on whether alg.krylov is true. The caching branch utilizes precomputed operators, which are calculated by the expRK_operators method in caches/linear_nonlinear_caches.jl. Both expRK_operators and the arnoldi/phiv methods in perform_step! comes from the ExponentialUtilities package.

The EPIRK methods can only use Krylov approximation, and unlike the previous two they use the timestepping variant phiv_timestep. The timestepping method follows the convention of Neisen & Wright, and can be toggled to use adaptation by alg.adaptive_krylov.

Although the exponential integrators (especially the in-place version) can seem complex, they share similar structures. The infrastructure for the existing exponential methods utilize the fact to reduce boilerplate code. In particular, the cache construction code in caches/linear_nonlinear_caches.jl and the initialize! method in perform_step/exponential_rk_perform_step.jl can be mostly automated and only perform_step! needs implementing.

Finally, to construct tests for the new exponential algorithm, append the new algorithm to the corresponding algorithm class in test/linear_nonlinear_convergence_tests.jl and test/linear_nonlinear_krylov_tests.jl.

+plot(sim)

Adding new exponential algorithms

The exponential algorithms follow the same recipe as the general algorithms, but there are automation utilities that make this easier. It is recommended that you refer to one of the model algorithms for reference:

The first two classes support two modes of operation: operator caching and Krylov approximation. The perform_step! method in perform_step/exponential_rk_perform_step.jl, as a result, is split into two branches depending on whether alg.krylov is true. The caching branch utilizes precomputed operators, which are calculated by the expRK_operators method in caches/linear_nonlinear_caches.jl. Both expRK_operators and the arnoldi/phiv methods in perform_step! comes from the ExponentialUtilities package.

The EPIRK methods can only use Krylov approximation, and unlike the previous two they use the timestepping variant phiv_timestep. The timestepping method follows the convention of Neisen & Wright, and can be toggled to use adaptation by alg.adaptive_krylov.

Although the exponential integrators (especially the in-place version) can seem complex, they share similar structures. The infrastructure for the existing exponential methods utilize the fact to reduce boilerplate code. In particular, the cache construction code in caches/linear_nonlinear_caches.jl and the initialize! method in perform_step/exponential_rk_perform_step.jl can be mostly automated and only perform_step! needs implementing.

Finally, to construct tests for the new exponential algorithm, append the new algorithm to the corresponding algorithm class in test/linear_nonlinear_convergence_tests.jl and test/linear_nonlinear_krylov_tests.jl.

diff --git a/dev/contributing/adding_packages/index.html b/dev/contributing/adding_packages/index.html index 024bb87..0ccc6b2 100644 --- a/dev/contributing/adding_packages/index.html +++ b/dev/contributing/adding_packages/index.html @@ -20,4 +20,4 @@ du = dures, dense = dense, timeseries_errors = timeseries_errors, - retcode = :Success)

Giving du is only currently allowed for DAEs and is optional. The errors flags (timeseries_errors and dense_errors) are flags for allowing the solution to calculate errors which should be passed through the solve function if applicable. A proper retcode should be placed or it will default to :Default.

+ retcode = :Success)

Giving du is only currently allowed for DAEs and is optional. The errors flags (timeseries_errors and dense_errors) are flags for allowing the solution to calculate errors which should be passed through the solve function if applicable. A proper retcode should be placed or it will default to :Default.

diff --git a/dev/contributing/defining_problems/index.html b/dev/contributing/defining_problems/index.html index 380c8b6..494465b 100644 --- a/dev/contributing/defining_problems/index.html +++ b/dev/contributing/defining_problems/index.html @@ -3,4 +3,4 @@ function gtag(){dataLayer.push(arguments);} gtag('js', new Date()); gtag('config', 'UA-90474609-3', {'page_path': location.pathname + location.search + location.hash}); -
Edit on GitHub

Developing A New Problem

New problems should be defined for new types of differential equations, new partial differential equations, and special subclasses of differential equations for which solvers can dispatch on for better performance.

To develop a new problem, you need to make a new DEProblem and a new DESolution. These types belong in DiffEqBase and should be exported. The DEProblem type should hold all of the mathematical information about the problem (including all of the meshing information in both space and time), and the DESolution should hold all of the information for the solution. Then all that is required is to define a __solve(::DEProblem,alg;kwargs) which takes in the problem and returns a solution.

Then to check that the algorithm works, add a dispatch for test_convergence which makes a ConvergenceSimulation type. This type already has a plot recipe, so plotting functionality will already be embedded. This requires that your problem can take in a true solution, and has a field errors which is a dictionary of symbols for the different error estimates (L2,L infinity, etc.)

After these steps, update the documentation to include the new problem types and the new associated solvers.

+
Edit on GitHub

Developing A New Problem

New problems should be defined for new types of differential equations, new partial differential equations, and special subclasses of differential equations for which solvers can dispatch on for better performance.

To develop a new problem, you need to make a new DEProblem and a new DESolution. These types belong in DiffEqBase and should be exported. The DEProblem type should hold all of the mathematical information about the problem (including all of the meshing information in both space and time), and the DESolution should hold all of the information for the solution. Then all that is required is to define a __solve(::DEProblem,alg;kwargs) which takes in the problem and returns a solution.

Then to check that the algorithm works, add a dispatch for test_convergence which makes a ConvergenceSimulation type. This type already has a plot recipe, so plotting functionality will already be embedded. This requires that your problem can take in a true solution, and has a field errors which is a dictionary of symbols for the different error estimates (L2,L infinity, etc.)

After these steps, update the documentation to include the new problem types and the new associated solvers.

diff --git a/dev/contributing/diffeq_internals/index.html b/dev/contributing/diffeq_internals/index.html index 3f85d29..765e222 100644 --- a/dev/contributing/diffeq_internals/index.html +++ b/dev/contributing/diffeq_internals/index.html @@ -25,4 +25,4 @@ end handle_tstop!(integrator) end -postamble!(integrator)

The algorithm runs until tstop is empty. It hits the loopheader! in order to accept/reject the previous step and choose a new dt. This is done at the top so that way the iterator interface happens "mid-step" instead of "post-step". In here the algorithm is also chosen for the switching algorithms.

Then the perform_step! is called. (The exit conditions throw an error if necessary.) Afterwards, the loopfooter! is used to calculate new timesteps, save, and apply the callbacks. If a value of tstops is hit, the algorithm breaks out of the inner-most loop to save the value.

Adding algorithms to the other problems is very similar, just in a different package.

Extras

If the method is a FSAL method then it needs to be set via isfsal and fsalfirst should be defined before the loop, with fsallast what's pushed up to fsalfirst upon a successful step. See :DP5 for an example.

If tests fail due to units (i.e. Unitful), don't worry. I would be willing to fix that up. To do so, you have to make sure you keep separate your rateTypes and your uTypes since the rates from f will have units of u but divided by a unit of time. If you simply try to write these into u, the units part will fail (normally you have to multiply by a $dt$).

If you want to access the value of u at the second-last time point, you can use uprev2 value. But in order to copy uprev value to uprev2 after each timestep, you need to make alg_extrapolates(alg::Your_Alg) = true in the alg_utils.jl file.

+postamble!(integrator)

The algorithm runs until tstop is empty. It hits the loopheader! in order to accept/reject the previous step and choose a new dt. This is done at the top so that way the iterator interface happens "mid-step" instead of "post-step". In here the algorithm is also chosen for the switching algorithms.

Then the perform_step! is called. (The exit conditions throw an error if necessary.) Afterwards, the loopfooter! is used to calculate new timesteps, save, and apply the callbacks. If a value of tstops is hit, the algorithm breaks out of the inner-most loop to save the value.

Adding algorithms to the other problems is very similar, just in a different package.

Extras

If the method is a FSAL method then it needs to be set via isfsal and fsalfirst should be defined before the loop, with fsallast what's pushed up to fsalfirst upon a successful step. See :DP5 for an example.

If tests fail due to units (i.e. Unitful), don't worry. I would be willing to fix that up. To do so, you have to make sure you keep separate your rateTypes and your uTypes since the rates from f will have units of u but divided by a unit of time. If you simply try to write these into u, the units part will fail (normally you have to multiply by a $dt$).

If you want to access the value of u at the second-last time point, you can use uprev2 value. But in order to copy uprev value to uprev2 after each timestep, you need to make alg_extrapolates(alg::Your_Alg) = true in the alg_utils.jl file.

diff --git a/dev/contributing/ecosystem_overview/index.html b/dev/contributing/ecosystem_overview/index.html index 9cd0249..d6d9ae6 100644 --- a/dev/contributing/ecosystem_overview/index.html +++ b/dev/contributing/ecosystem_overview/index.html @@ -4,4 +4,4 @@ gtag('js', new Date()); gtag('config', 'UA-90474609-3', {'page_path': location.pathname + location.search + location.hash});
Edit on GitHub

Ecosystem Overview

So you're looking to help out DifferentialEquations.jl? We'd be happy to have your help. It is recommended you first discuss with some of the developers on the Gitter channel to make sure that you're up-to-date with current developments.

The Common Interface

The DiffEq ecosystem is built around the common interface. This is the interface for the solvers:

__solve(prob, alg; kwargs...)
-__init(prob, alg; kwargs...)

and the standard methods for dealing with solutions. A higher level solve and init is given by DiffEqBase.jl for functional and distributional inputs. Users build problem types for solvers to act on, and add-on components which use the solution types for higher-level analysis like parameter estimation and sensitivity analysis.

One can add components at any of these levels to improve the functionality of the system as a whole.

Organizational Setup

JuliaDiffEq is setup in a distributed manner to allow developers to retain authoritative control and licensing for their own packages/algorithms, yet contribute to the greater ecosystem. This gives a way for researchers to target a wide audience of users, but not have to fully contribute to public packages or be restricted in licensing. At the center of the ecosystem is DiffEqBase which holds the Problem, Solution, and Algorithm types (the algorithms are defined in DiffEqBase to be accessible by the default_algorithm function. One can opt out of this). Then there's the component solvers, which includes the *DiffEq packages (OrdinaryDiffEq, StochasticDiffEq, etc.) which implement different methods for solve. Then there are the add-on packages, such as the DiffEq* packages (DiffEqParamEstim, DiffEqDevTools) which add functionality to the Problem+solve setup. Lastly, there's DifferentialEquations.jl which is a metapackage which holds all of these pieces together as one cohesive unit.

If one wants their package to officially join the ecosystem, it will need to be moved to the JuliaDiffEq organization so that maintenance can occur (but the core algorithms will only be managed by the package owners themselves). The Algorithm types can then be moved to DiffEqBase, and after testing the package will be added to the list packages exported by DifferentialEquations.jl and the corresponding documentation.

+__init(prob, alg; kwargs...)

and the standard methods for dealing with solutions. A higher level solve and init is given by DiffEqBase.jl for functional and distributional inputs. Users build problem types for solvers to act on, and add-on components which use the solution types for higher-level analysis like parameter estimation and sensitivity analysis.

One can add components at any of these levels to improve the functionality of the system as a whole.

Organizational Setup

JuliaDiffEq is setup in a distributed manner to allow developers to retain authoritative control and licensing for their own packages/algorithms, yet contribute to the greater ecosystem. This gives a way for researchers to target a wide audience of users, but not have to fully contribute to public packages or be restricted in licensing. At the center of the ecosystem is DiffEqBase which holds the Problem, Solution, and Algorithm types (the algorithms are defined in DiffEqBase to be accessible by the default_algorithm function. One can opt out of this). Then there's the component solvers, which includes the *DiffEq packages (OrdinaryDiffEq, StochasticDiffEq, etc.) which implement different methods for solve. Then there are the add-on packages, such as the DiffEq* packages (DiffEqParamEstim, DiffEqDevTools) which add functionality to the Problem+solve setup. Lastly, there's DifferentialEquations.jl which is a metapackage which holds all of these pieces together as one cohesive unit.

If one wants their package to officially join the ecosystem, it will need to be moved to the JuliaDiffEq organization so that maintenance can occur (but the core algorithms will only be managed by the package owners themselves). The Algorithm types can then be moved to DiffEqBase, and after testing the package will be added to the list packages exported by DifferentialEquations.jl and the corresponding documentation.

diff --git a/dev/contributing/type_traits/index.html b/dev/contributing/type_traits/index.html index be0c872..e696bac 100644 --- a/dev/contributing/type_traits/index.html +++ b/dev/contributing/type_traits/index.html @@ -3,4 +3,4 @@ function gtag(){dataLayer.push(arguments);} gtag('js', new Date()); gtag('config', 'UA-90474609-3', {'page_path': location.pathname + location.search + location.hash}); -
Edit on GitHub

Type Traits

Many of the DiffEqBase abstract types have associated traits. These can be used to check compatibility and apply separate code paths. For example, a parameter estimation algorithm can set the default for using autodifferentiation by checking if the algorithm is compatible with autodifferentiation.

Below are the abstract types along with the associated trait functions. These are listed as:

f(x)

where f is the trait function and x is the any type which subtypes the abstract type.

AbstractODEProblem

  • isinplace : Returns true if the problem uses in-place functions

AbstractRODEProblem

  • is_diagonal_noise : Returns true if the noise is diagonal.

DEAlgorithm

  • isautodifferentiable : Returns true if the algorithm is autodifferentiable.
+
Edit on GitHub

Type Traits

Many of the DiffEqBase abstract types have associated traits. These can be used to check compatibility and apply separate code paths. For example, a parameter estimation algorithm can set the default for using autodifferentiation by checking if the algorithm is compatible with autodifferentiation.

Below are the abstract types along with the associated trait functions. These are listed as:

f(x)

where f is the trait function and x is the any type which subtypes the abstract type.

AbstractODEProblem

  • isinplace : Returns true if the problem uses in-place functions

AbstractRODEProblem

  • is_diagonal_noise : Returns true if the noise is diagonal.

DEAlgorithm

  • isautodifferentiable : Returns true if the algorithm is autodifferentiable.
diff --git a/dev/index.html b/dev/index.html index 94e00bc..1c66dae 100644 --- a/dev/index.html +++ b/dev/index.html @@ -8,7 +8,7 @@ [fa972c1a] DiffEqDevDocs v1.0.0 `~/work/DiffEqDevDocs.jl/DiffEqDevDocs.jl` [f3b72e0c] DiffEqDevTools v2.44.2 ⌅ [e30172f5] Documenter v0.27.25 - [1dea7af3] OrdinaryDiffEq v6.74.0 + [1dea7af3] OrdinaryDiffEq v6.74.1 Info Packages marked with ⌅ have new versions available but compatibility constraints restrict them from upgrading. To see why use `status --outdated`
and using this machine and Julia version.
Julia Version 1.10.2
 Commit bd47eca2c8a (2024-03-01 10:14 UTC)
 Build Info:
@@ -20,30 +20,29 @@
   LIBM: libopenlibm
   LLVM: libLLVM-15.0.7 (ORCJIT, znver3)
 Threads: 1 default, 0 interactive, 1 GC (on 4 virtual cores)
A more complete overview of all dependencies and their versions is also provided.
Status `~/work/DiffEqDevDocs.jl/DiffEqDevDocs.jl/docs/Manifest.toml`
-  [47edcb42] ADTypes v0.2.6
+  [47edcb42] ADTypes v0.2.7
   [a4c015fc] ANSIColoredPrinters v0.0.1
-  [79e6a3ab] Adapt v4.0.1
+  [7d9f7c33] Accessors v0.1.36
+  [79e6a3ab] Adapt v4.0.4
 ⌅ [ec485272] ArnoldiMethod v0.2.0
-  [4fba245c] ArrayInterface v7.8.0
-  [4c555306] ArrayLayouts v1.6.0
-  [6e4b80f9] BenchmarkTools v1.5.0
+  [4fba245c] ArrayInterface v7.9.0
+  [4c555306] ArrayLayouts v1.8.0
   [62783981] BitTwiddlingConvenienceFunctions v0.1.5
   [2a0fbf3d] CPUSummary v0.2.4
   [49dc2e85] Calculus v0.5.1
   [d360d2e6] ChainRulesCore v1.23.0
   [fb6a15b2] CloseOpenIntervals v0.1.12
-  [523fee87] CodecBzip2 v0.8.2
-  [944b1d66] CodecZlib v0.7.4
   [38540f10] CommonSolve v0.2.4
   [bbf7d656] CommonSubexpressions v0.3.0
   [34da2185] Compat v4.14.0
+  [a33af91c] CompositionsBase v0.1.2
   [2569d6c7] ConcreteStructs v0.2.3
-  [187b0558] ConstructionBase v1.5.4
+  [187b0558] ConstructionBase v1.5.5
   [adafc99b] CpuId v0.3.1
   [9a962f9c] DataAPI v1.16.0
-  [864edb3b] DataStructures v0.18.17
+  [864edb3b] DataStructures v0.18.18
   [e2d170a0] DataValueInterfaces v1.0.0
-  [2b5f629d] DiffEqBase v6.148.0
+  [2b5f629d] DiffEqBase v6.149.0
   [fa972c1a] DiffEqDevDocs v1.0.0 `~/work/DiffEqDevDocs.jl/DiffEqDevDocs.jl`
   [f3b72e0c] DiffEqDevTools v2.44.2
   [77a26b50] DiffEqNoiseProcess v5.21.0
@@ -55,26 +54,27 @@
 ⌅ [e30172f5] Documenter v0.27.25
   [fa6b7ba4] DualNumbers v0.6.8
   [4e289a0a] EnumX v1.0.4
-⌃ [f151be2c] EnzymeCore v0.6.5
+⌃ [f151be2c] EnzymeCore v0.6.6
   [d4d017d3] ExponentialUtilities v1.26.1
   [e2ba6199] ExprTools v0.1.10
   [7034ab61] FastBroadcast v0.2.8
   [9aa1b823] FastClosures v0.3.2
   [29a986be] FastLapackInterface v2.0.2
   [1a297f60] FillArrays v1.9.3
-  [6a86dc24] FiniteDiff v2.22.0
-  [1fa38f19] Format v1.3.6
+  [6a86dc24] FiniteDiff v2.23.0
+  [1fa38f19] Format v1.3.7
   [f6369f11] ForwardDiff v0.10.36
   [069b7b12] FunctionWrappers v1.1.3
   [77dc65aa] FunctionWrappersWrappers v0.1.3
   [46192b85] GPUArraysCore v0.1.6
-  [c145ed77] GenericSchur v0.5.3
+  [c145ed77] GenericSchur v0.5.4
   [86223c79] Graphs v1.9.0
   [3e5b6fbb] HostCPUFeatures v0.1.16
   [34004b35] HypergeometricFunctions v0.3.23
   [b5f81e59] IOCapture v0.2.4
   [615f187c] IfElse v0.1.1
   [d25df0c9] Inflate v0.1.4
+  [3587e190] InverseFunctions v0.1.13
   [92d709cd] IrrationalConstants v0.2.2
   [82899510] IteratorInterfaceExtensions v1.0.0
   [692b3bcd] JLLWrappers v1.5.0
@@ -86,41 +86,39 @@
   [10f19ff3] LayoutPointers v0.1.15
   [5078a376] LazyArrays v1.8.3
   [d3d80556] LineSearches v7.2.0
-  [7ed4a6bd] LinearSolve v2.26.0
+  [7ed4a6bd] LinearSolve v2.28.0
   [2ab3a3ac] LogExpFunctions v0.3.27
-  [bdcacae8] LoopVectorization v0.12.166
+  [bdcacae8] LoopVectorization v0.12.169
   [1914dd2f] MacroTools v0.5.13
   [d125e4d3] ManualMemory v0.1.8
-  [b8f27783] MathOptInterface v1.27.0
   [a3b82374] MatrixFactorizations v2.1.0
-  [bb5d69b7] MaybeInplace v0.1.1
+  [bb5d69b7] MaybeInplace v0.1.2
   [e1d29d7a] Missings v1.1.0
   [46d2c3a1] MuladdMacro v0.2.4
-  [d8a4904e] MutableArithmetics v1.4.1
   [d41bc354] NLSolversBase v7.8.3
   [2774e3e8] NLsolve v4.5.1
   [77ba4419] NaNMath v1.0.2
-  [8913a72c] NonlinearSolve v3.7.3
+  [8913a72c] NonlinearSolve v3.9.0
   [6fe1bfb0] OffsetArrays v1.13.0
-  [429524aa] Optim v1.9.2
+  [429524aa] Optim v1.9.3
   [bac558e1] OrderedCollections v1.6.3
-  [1dea7af3] OrdinaryDiffEq v6.74.0
+  [1dea7af3] OrdinaryDiffEq v6.74.1
   [90014a1f] PDMats v0.11.31
   [65ce6f38] PackageExtensionCompat v1.0.2
   [d96e819e] Parameters v0.12.3
   [69de0a69] Parsers v2.8.1
   [e409e4f3] PoissonRandom v0.4.4
-  [f517fe37] Polyester v0.7.9
+  [f517fe37] Polyester v0.7.12
   [1d0040c9] PolyesterWeave v0.2.1
   [85a6dd25] PositiveFactorizations v0.2.4
   [d236fae5] PreallocationTools v0.4.20
-  [aea7be01] PrecompileTools v1.2.0
+  [aea7be01] PrecompileTools v1.2.1
   [21216c6a] Preferences v1.4.3
   [1fd47b50] QuadGK v2.9.4
   [74087812] Random123 v1.7.0
   [e6cf234a] RandomNumbers v1.5.3
   [3cdcf5f2] RecipesBase v1.3.4
-  [731186ca] RecursiveArrayTools v3.10.1
+  [731186ca] RecursiveArrayTools v3.13.0
   [f2c3362d] RecursiveFactorization v0.2.21
   [189a3867] Reexport v1.2.2
   [ae029012] Requires v1.3.0
@@ -130,10 +128,11 @@
   [7e49a35a] RuntimeGeneratedFunctions v0.5.12
   [94e857df] SIMDTypes v0.1.0
   [476501e8] SLEEFPirates v0.6.42
-  [0bca4576] SciMLBase v2.29.0
+  [0bca4576] SciMLBase v2.31.0
   [c0aeaf25] SciMLOperators v0.3.8
+  [53ae85a6] SciMLStructures v1.1.0
   [efcf1570] Setfield v1.1.1
-  [727e6d20] SimpleNonlinearSolve v1.5.0
+  [727e6d20] SimpleNonlinearSolve v1.7.0
   [699a6c99] SimpleTraits v0.9.4
   [ce78b400] SimpleUnPack v1.1.0
   [a2af1166] SortingAlgorithms v1.2.1
@@ -149,19 +148,17 @@
   [4c63d2b9] StatsFuns v1.3.1
   [7792a7ef] StrideArraysCore v0.5.2
   [09ab397b] StructArrays v0.6.18
-  [2efcf032] SymbolicIndexingInterface v0.3.8
+  [2efcf032] SymbolicIndexingInterface v0.3.15
   [3783bdb8] TableTraits v1.0.1
   [bd369af6] Tables v1.11.1
   [8290d209] ThreadingUtilities v0.5.2
   [a759f4b9] TimerOutputs v0.5.23
-  [3bb67fe8] TranscodingStreams v0.10.4
-  [d5829a12] TriangularSolve v0.1.20
+  [d5829a12] TriangularSolve v0.1.21
   [410a4b4d] Tricks v0.1.8
   [781d530d] TruncatedStacktraces v1.4.0
   [3a884ed6] UnPack v1.0.2
   [3d5dd08c] VectorizationBase v0.21.65
   [19fa3120] VertexSafeGraphs v0.2.0
-  [6e34b625] Bzip2_jll v1.0.8+1
   [1d5cc7b8] IntelOpenMP_jll v2024.0.2+0
   [856f044c] MKL_jll v2024.0.0+0
   [efe28fd5] OpenSpecFun_jll v0.5.5+0
@@ -186,7 +183,6 @@
   [ca575930] NetworkOptions v1.2.0
   [44cfe95a] Pkg v1.10.0
   [de0858da] Printf
-  [9abbd945] Profile
   [3fa0cd96] REPL
   [9a3f8284] Random
   [ea8e919c] SHA v0.7.0
@@ -216,4 +212,4 @@
   [3f19e933] p7zip_jll v17.4.0+2
 Info Packages marked with ⌃ and ⌅ have new versions available. Those with ⌃ may be upgradable, but those with ⌅ are restricted by compatibility constraints from upgrading. To see why use `status --outdated -m`
You can also download the manifest file and the -project file. +project file. diff --git a/dev/internals/notes_on_algorithms/index.html b/dev/internals/notes_on_algorithms/index.html index e3b4255..4402aec 100644 --- a/dev/internals/notes_on_algorithms/index.html +++ b/dev/internals/notes_on_algorithms/index.html @@ -3,4 +3,4 @@ function gtag(){dataLayer.push(arguments);} gtag('js', new Date()); gtag('config', 'UA-90474609-3', {'page_path': location.pathname + location.search + location.hash}); -
Edit on GitHub

Notes on Algorithms

This page is a supplemental page which details some facts about the chosen algorithms, why some I took the time to make optimized versions for, and for others why they were ignored.

Explicit Runge-Kutta ODE Algorithms

From what I can tell, this is by far the most comprehensive comparison of Explicit Runge-Kutta ODE algorithms that you'll find.

Implementations

The different implementations have been benchmarked against each other. The efficiency was calculated by weighing both the time and error on classic test problems. To make clear distinctions, solver options were tweaked to many different settings, including:

  • Matching errors
  • Matching runtimes
  • Matching settings
  • Low/High tolerance

The DifferentialEquations.jl implementations of the explicit Runge-Kutta solvers are by a good margin the most efficient implementations of the given algorithms. They utilize many extra tricks, nice caching, and threading if available, to vastly outperform the other methods in terms of efficiency (even with threading disabled). :DP5 performs much better than :dopri5, which vastly outperform ode45 (whose stepsize algorithm tends to have issues on some quasi-stiff problems). :DP8 performs better than dop853 in some cases, worse in others. Both vastly outperform ode78.

For this reason, the DifferentialEquations.jl non-stiff algorithms are the recommended implementations. ODEInterface non-stiff algorithms are only recommended for historical purposes (i.e. to match previous results) or to try dop853 on a problem (work is being to find out what the difference is and squash the competition here!). The ODE.jl algorithms are not recommended for any serious use (the package is essentially deprecated: it's slow, gets high error, the timestepping algorithm is not robust, and doesn't implement many methods).

Order 4-

At this stage, coefficient of the truncation error seems to win out, or you are willing to live with low tolerance anyways. Thus Bogacki-Shampine is the clear winner in this category because at order 2/3 with FASL it has minimal numbers of function evaluations but also is stable enough to step as needed. All other methods don't compare because of the FASL property boosting the order and thus the stability (for low orders, it pretty much holds that higher order = higher stability (for optimal number of steps), which is not true as we go higher), making it more stable and have less error for lower numbers of function evaluations than the others in this category.

Order 5

[Note that for all of these Peter Stone's modifications do not seem to be helpful since, although they lower the truncation error, they also modify the stability region in ways that can be worrisome (mostly they shrink the stability in the complex axis near the origin, making the problems not as suitable for a "general purpose default" like one would hope with a 4/5 solver)]

The "clear choice" is the Dormand-Prince 4/5 pair. This is the pair which is used by default as ode45 in MATLAB, and serves similar functions in scipy, ODE.jl, etc. The golden standard implementation is Hairer's DOPRI5 (offered by ODEInterface.jl). After optimizations, DifferentialEquations.jl's native DP5 solver is much more efficient (between 4x-400x) than DOPRI5's, with various design choices factoring into this (which are documented in the benchmarks). This is pre-threading, and within method threading will likely be at least doubled or tripled when threading is enabled. Thus it's clear that the reference implementation to try other methods against is the DifferentialEquations.jl DP5 method.

It's obvious that anything before Dormand-Prince 4/5's pair is simply not as good because of the optimizations on the local truncation error coefficient and the fact that FASL schemes essentially have one less function evaluation. So the previous algorithms were implemented as tableaus for the historical reasons but dealt with no further. These methods include the Runge, Cassity, Butcher, Fehlburg, Lawson, Luther and Konen, and Kutta schemes.

The next set of schemes are the Papakostas-Papageorgiou schemes. The problem is that they don't really get the much lower on the error than DP5, but also have wacky stability near the origin.

Tsitouras's looks to be a good match against DP5 as a 6-stage scheme to take on DP5. Its stability is similar to DP5 but its first error term is an order of magnitude smaller. More tests will likely determine that this is much better than DP5 in accordance with his paper.

Lastly, there are the 7-stage schemes. The more recent one is due to Sharp and Smart, but I am ignoring this because its error term is almost an order of magnitude larger than the BS pair, and its stability region is wonky near the origin. Its only plus over the BS pair is that it has a slightly larger stability in the real axis, which is not important when paired with adaptive stepping and for use on non-stiff problems.

That leaves us with the Bogacki-Shampine pair. This pair gets more than an order of magnitude lower truncation error, enhanced complex stability, and two error estimators to make it more robust. In fact, this is the default which is chosen in Mathematica. Its downside is that since it is an 8-stage scheme, it requires an additional function evaluation.

Further tests will likely narrow this down to Tsitouras vs Bogacki-Shampine. Who will come out on top? Who knows.

Order 6

Sharp-Verner has bad complex stability near the origin. I don't like any of the Peter Stone modifications here. Butcher and Chummund methods have stability issues near the origin as well. Huta's method has too high of an error coefficient. Verner's 1991 has bad complex stability. Same as the most robust. The Verner "most efficient" has really good stability and error coefficient. In fact, nothing is even close except for Tsitouras' method. The DP method is two orders of magnitude higher in error coefficient than Verner. The Luther methods have too much error. Same as Tsitouras-Papakostas and M. Tanaka, K. Kasuga, S. Yamashita and H. Yazaki.

Without a doubt the winner is the Verner "most efficient".

Order 7

The Enright-Verner and other Verner methods all have stability issues near the origin in the complex plane and higher error coefficients. Sharp and Smart have higher error coefficients. Peter Stone's methods all have higher error. It's very clear that the best here is the Tanaka-Yamashita (efficient, not the stable) method by far.

Order 8

The Cooper-Verner methods do not have an error estimate and so no adaptive timestepping can be done. This is a deal-breaker. Going into this one would think that the clear winner would be Dormand-Prince 8. But that's not the case. However, that's comparing the classical 1981 DP87. Notice that the code for Dop853 is based off of the 1989 paper which has different coefficients (and currently I have no analysis for this).

The other methods include Verner's Maple dverk78 which is bested in both stability and error coefficient by Enright-Verner which is bested by Tsitouras-Papakostas.

Thus the final showdown is between DP853 vs the Tsitouras-Papakostas pair.

Order 9

The Tsitouras scheme and the Sharp scheme have funky stability near the origin. Verner's schemes are much safer, and with similar error. They clearly dominate this category.

Order 10

Curtis' scheme has more function evaluations than needed, and Peter Stone's modification reduces the truncation error by a lot but adds three more function evaluations. Thus Hairer's 17 stage scheme (whose error and stability is similar to Curtis') is clearly better. Once again Peter Stone's modification adds three steps but does not reduce the truncation error here, so the unmodified version does better.

Tom Baker's method increases the stability region to something which is more than necessary but adds 4 function evaluations to do so (without lowering the error very much). Ono's scheme minimizes the error more than Hairer's here, with all else being basically the same. The Peter Stone methods add a lot of function evaluations (5+) and so they would only be useful in the case where the function evaluations are quick yet you still want really small error. Even then I'm not convinced they are better than the other methods, or better than the higher order methods which use less steps. The stability is only okay.

The Feagin scheme is fine, but with more error and less stability than the Hairer scheme. Thus it seems clear that Hairer's method dominates this category. However, that's only because it does not include an error estimate. Feagin's scheme is close in error and stability, but includes an error estimate which can be used for adaptivity, making it the choice in this category.

Order 11

The order 11 schemes are due to Tom Baker at the University of Teeside. They have a nice sparsity pattern and receive slightly lower truncation error coefficients than the Feagin, but Feagin's dominates by being "almost order 13" anyways so while a nice try the order 11 scheme is likely overwhelmed in any case where it would be useful.

Order 12

Here there are the Feagin schemes and Ono's scheme. Ono's scheme gets horrible stability with more error and so it's not in the running. Peter Stone's modifications do not make a substantive change, and where they do they get rid of the nice property that the Feagin 12 method satisfies many of the higher order conditions as well, making it look even higher order on some problems. Thus the standard Feagin 12 seems to win out in this category.

Order 14

In this category there is just the Feagin. Peter Stone's modification barely changes anything in the analysis so I did not even attempt it.

+
Edit on GitHub

Notes on Algorithms

This page is a supplemental page which details some facts about the chosen algorithms, why some I took the time to make optimized versions for, and for others why they were ignored.

Explicit Runge-Kutta ODE Algorithms

From what I can tell, this is by far the most comprehensive comparison of Explicit Runge-Kutta ODE algorithms that you'll find.

Implementations

The different implementations have been benchmarked against each other. The efficiency was calculated by weighing both the time and error on classic test problems. To make clear distinctions, solver options were tweaked to many different settings, including:

  • Matching errors
  • Matching runtimes
  • Matching settings
  • Low/High tolerance

The DifferentialEquations.jl implementations of the explicit Runge-Kutta solvers are by a good margin the most efficient implementations of the given algorithms. They utilize many extra tricks, nice caching, and threading if available, to vastly outperform the other methods in terms of efficiency (even with threading disabled). :DP5 performs much better than :dopri5, which vastly outperform ode45 (whose stepsize algorithm tends to have issues on some quasi-stiff problems). :DP8 performs better than dop853 in some cases, worse in others. Both vastly outperform ode78.

For this reason, the DifferentialEquations.jl non-stiff algorithms are the recommended implementations. ODEInterface non-stiff algorithms are only recommended for historical purposes (i.e. to match previous results) or to try dop853 on a problem (work is being to find out what the difference is and squash the competition here!). The ODE.jl algorithms are not recommended for any serious use (the package is essentially deprecated: it's slow, gets high error, the timestepping algorithm is not robust, and doesn't implement many methods).

Order 4-

At this stage, coefficient of the truncation error seems to win out, or you are willing to live with low tolerance anyways. Thus Bogacki-Shampine is the clear winner in this category because at order 2/3 with FASL it has minimal numbers of function evaluations but also is stable enough to step as needed. All other methods don't compare because of the FASL property boosting the order and thus the stability (for low orders, it pretty much holds that higher order = higher stability (for optimal number of steps), which is not true as we go higher), making it more stable and have less error for lower numbers of function evaluations than the others in this category.

Order 5

[Note that for all of these Peter Stone's modifications do not seem to be helpful since, although they lower the truncation error, they also modify the stability region in ways that can be worrisome (mostly they shrink the stability in the complex axis near the origin, making the problems not as suitable for a "general purpose default" like one would hope with a 4/5 solver)]

The "clear choice" is the Dormand-Prince 4/5 pair. This is the pair which is used by default as ode45 in MATLAB, and serves similar functions in scipy, ODE.jl, etc. The golden standard implementation is Hairer's DOPRI5 (offered by ODEInterface.jl). After optimizations, DifferentialEquations.jl's native DP5 solver is much more efficient (between 4x-400x) than DOPRI5's, with various design choices factoring into this (which are documented in the benchmarks). This is pre-threading, and within method threading will likely be at least doubled or tripled when threading is enabled. Thus it's clear that the reference implementation to try other methods against is the DifferentialEquations.jl DP5 method.

It's obvious that anything before Dormand-Prince 4/5's pair is simply not as good because of the optimizations on the local truncation error coefficient and the fact that FASL schemes essentially have one less function evaluation. So the previous algorithms were implemented as tableaus for the historical reasons but dealt with no further. These methods include the Runge, Cassity, Butcher, Fehlburg, Lawson, Luther and Konen, and Kutta schemes.

The next set of schemes are the Papakostas-Papageorgiou schemes. The problem is that they don't really get the much lower on the error than DP5, but also have wacky stability near the origin.

Tsitouras's looks to be a good match against DP5 as a 6-stage scheme to take on DP5. Its stability is similar to DP5 but its first error term is an order of magnitude smaller. More tests will likely determine that this is much better than DP5 in accordance with his paper.

Lastly, there are the 7-stage schemes. The more recent one is due to Sharp and Smart, but I am ignoring this because its error term is almost an order of magnitude larger than the BS pair, and its stability region is wonky near the origin. Its only plus over the BS pair is that it has a slightly larger stability in the real axis, which is not important when paired with adaptive stepping and for use on non-stiff problems.

That leaves us with the Bogacki-Shampine pair. This pair gets more than an order of magnitude lower truncation error, enhanced complex stability, and two error estimators to make it more robust. In fact, this is the default which is chosen in Mathematica. Its downside is that since it is an 8-stage scheme, it requires an additional function evaluation.

Further tests will likely narrow this down to Tsitouras vs Bogacki-Shampine. Who will come out on top? Who knows.

Order 6

Sharp-Verner has bad complex stability near the origin. I don't like any of the Peter Stone modifications here. Butcher and Chummund methods have stability issues near the origin as well. Huta's method has too high of an error coefficient. Verner's 1991 has bad complex stability. Same as the most robust. The Verner "most efficient" has really good stability and error coefficient. In fact, nothing is even close except for Tsitouras' method. The DP method is two orders of magnitude higher in error coefficient than Verner. The Luther methods have too much error. Same as Tsitouras-Papakostas and M. Tanaka, K. Kasuga, S. Yamashita and H. Yazaki.

Without a doubt the winner is the Verner "most efficient".

Order 7

The Enright-Verner and other Verner methods all have stability issues near the origin in the complex plane and higher error coefficients. Sharp and Smart have higher error coefficients. Peter Stone's methods all have higher error. It's very clear that the best here is the Tanaka-Yamashita (efficient, not the stable) method by far.

Order 8

The Cooper-Verner methods do not have an error estimate and so no adaptive timestepping can be done. This is a deal-breaker. Going into this one would think that the clear winner would be Dormand-Prince 8. But that's not the case. However, that's comparing the classical 1981 DP87. Notice that the code for Dop853 is based off of the 1989 paper which has different coefficients (and currently I have no analysis for this).

The other methods include Verner's Maple dverk78 which is bested in both stability and error coefficient by Enright-Verner which is bested by Tsitouras-Papakostas.

Thus the final showdown is between DP853 vs the Tsitouras-Papakostas pair.

Order 9

The Tsitouras scheme and the Sharp scheme have funky stability near the origin. Verner's schemes are much safer, and with similar error. They clearly dominate this category.

Order 10

Curtis' scheme has more function evaluations than needed, and Peter Stone's modification reduces the truncation error by a lot but adds three more function evaluations. Thus Hairer's 17 stage scheme (whose error and stability is similar to Curtis') is clearly better. Once again Peter Stone's modification adds three steps but does not reduce the truncation error here, so the unmodified version does better.

Tom Baker's method increases the stability region to something which is more than necessary but adds 4 function evaluations to do so (without lowering the error very much). Ono's scheme minimizes the error more than Hairer's here, with all else being basically the same. The Peter Stone methods add a lot of function evaluations (5+) and so they would only be useful in the case where the function evaluations are quick yet you still want really small error. Even then I'm not convinced they are better than the other methods, or better than the higher order methods which use less steps. The stability is only okay.

The Feagin scheme is fine, but with more error and less stability than the Hairer scheme. Thus it seems clear that Hairer's method dominates this category. However, that's only because it does not include an error estimate. Feagin's scheme is close in error and stability, but includes an error estimate which can be used for adaptivity, making it the choice in this category.

Order 11

The order 11 schemes are due to Tom Baker at the University of Teeside. They have a nice sparsity pattern and receive slightly lower truncation error coefficients than the Feagin, but Feagin's dominates by being "almost order 13" anyways so while a nice try the order 11 scheme is likely overwhelmed in any case where it would be useful.

Order 12

Here there are the Feagin schemes and Ono's scheme. Ono's scheme gets horrible stability with more error and so it's not in the running. Peter Stone's modifications do not make a substantive change, and where they do they get rid of the nice property that the Feagin 12 method satisfies many of the higher order conditions as well, making it look even higher order on some problems. Thus the standard Feagin 12 seems to win out in this category.

Order 14

In this category there is just the Feagin. Peter Stone's modification barely changes anything in the analysis so I did not even attempt it.

diff --git a/dev/internals/tableaus/index.html b/dev/internals/tableaus/index.html index 93495b8..484a690 100644 --- a/dev/internals/tableaus/index.html +++ b/dev/internals/tableaus/index.html @@ -3,4 +3,4 @@ function gtag(){dataLayer.push(arguments);} gtag('js', new Date()); gtag('config', 'UA-90474609-3', {'page_path': location.pathname + location.search + location.hash}); -
Edit on GitHub

ODE Tableaus

Explicit Runge-Kutta Methods

  • constructEuler - Euler's 1st order method.
  • constructHeun() Heun's order 2 method.
  • constructRalston() - Ralston's order 2 method.
  • constructSSPRK22() - Explicit SSP method of order 2 using 2 stages.
  • constructKutta3 - Kutta's classic 3rd order method.
  • constructSSPRK33() - Explicit SSP method of order 3 using 3 stages.
  • constructSSPRK43() - Explicit SSP method of order 3 using 4 stages.
  • constructRK4 - The classic 4th order "Runge-Kutta" method.
  • constructRK438Rule - The classic 4th order "3/8th's Rule" method.
  • constructSSPRK104() - Explicit SSP method of order 4 using 10 stages.
  • constructBogakiShampine3() - Bogakai-Shampine's 2/3 method.
  • constructRKF4() - Runge-Kutta-Fehlberg 3/4.
  • constructRKF5() - Runge-Kutta-Fehlberg 4/5.
  • constructRungeFirst5() - Runge's first 5th order method.
  • constructCassity5() - Cassity's 5th order method.
  • constructLawson5() - Lawson's 5th order method.
  • constructLutherKonen5 - Luther-Konen's first 5th order method.
  • constructLutherKonen52() - Luther-Konen's second 5th order method.
  • constructLutherKonen53() - Luther-Konen's third 5th order method.
  • constructPapakostasPapaGeorgiou5() - Papakostas and PapaGeorgiou more stable order 5 method.
  • constructPapakostasPapaGeorgiou52() - Papakostas and PapaGeorgiou more efficient order 5 method.
  • constructTsitouras5() - Tsitouras's order 5 method.
  • constructBogakiShampine5() - Bogaki and Shampine's Order 5 method.
  • constructSharpSmart5() - Sharp and Smart's Order 5 method.
  • constructCashKarp() - Cash-Karp method 4/5.
  • constructDormandPrince() - Dormand-Prince 4/5.
  • constructButcher6() - Butcher's first order 6 method.
  • constructButcher62() - Butcher's second order 6 method.
  • constructButcher63() - Butcher's third order 6 method.
  • constructDormandPrince6() - Dormand-Prince's 5/6 method.
  • constructSharpVerner6() Sharp-Verner's 5/6 method.
  • constructVerner916() - Verner's more efficient order 6 method (1991).
  • constructVerner9162() - Verner's second more efficient order 6 method (1991).
  • constructVernerRobust6() - Verner's "most robust" order 6 method.
  • constructVernerEfficient6() - Verner's "most efficient" order 6 method.
  • constructPapakostas6() - Papakostas's order 6 method.
  • constructLawson6() - Lawson's order 6 method.
  • constructTsitourasPapakostas6() - Tsitouras and Papakostas's order 6 method.
  • constructDormandLockyerMcCorriganPrince6() - the Dormand-Lockyer-McCorrigan-Prince order 6 method.
  • constructTanakaKasugaYamashitaYazaki6A() - Tanaka-Kasuga-Yamashita-Yazaki order 6 method A.
  • constructTanakaKasugaYamashitaYazaki6B() - Tanaka-Kasuga-Yamashita-Yazaki order 6 method B.
  • constructTanakaKasugaYamashitaYazaki6C() - Tanaka-Kasuga-Yamashita-Yazaki order 6 method C.
  • constructTanakaKasugaYamashitaYazaki6D() - Tanaka-Kasuga-Yamashita-Yazaki order 6 method D.
  • constructMikkawyEisa() - Mikkawy and Eisa's order 6 method.
  • constructChummund6() - Chummund's first order 6 method.
  • constructChummund62() - Chummund's second order 6 method.
  • constructHuta6() - Huta's first order 6 method.
  • constructHuta62() - Huta's second order 6 method.
  • constructVerner6() - An old order 6 method attributed to Verner.
  • constructDverk() - The classic DVERK algorithm attributed to Verner.
  • constructClassicVerner6() - A classic Verner order 6 algorithm (1978).
  • constructButcher7() - Butcher's order 7 algorithm.
  • constructClassicVerner7()- A classic Verner order 7 algorithm (1978).
  • constructVernerRobust7() - Verner's "most robust" order 7 algorithm.
  • constructTanakaYamashitaStable7() - Tanaka-Yamashita more stable order 7 algorithm.
  • constructTanakaYamashitaEfficient7() - Tanaka-Yamashita more efficient order 7 algorithm.
  • constructSharpSmart7() - Sharp-Smart's order 7 algorithm.
  • constructSharpVerner7() - Sharp-Verner's order 7 algorithm.
  • constructVerner7() - Verner's "most efficient" order 7 algorithm.
  • constructVernerEfficient7() - Verner's "most efficient" order 7 algorithm.
  • constructClassicVerner8() - A classic Verner order 8 algorithm (1978).
  • constructCooperVerner8() - Cooper-Verner's first order 8 algorithm.
  • constructCooperVerner82() - Cooper-Verner's second order 8 algorithm.
  • constructTsitourasPapakostas8() - Tsitouras-Papakostas order 8 algorithm.
  • constructdverk78() - The classic order 8 DVERK algorithm.
  • constructEnrightVerner8() - Enright-Verner order 8 algorithm.
  • constructCurtis8() - Curtis' order 8 algorithm.
  • constructVerner8() - Verner's "most efficient" order 8 algorithm.
  • constructRKF8() - Runge-Kutta-Fehlberg Order 7/8 method.
  • constructDormandPrice8() - Dormand-Prince Order 7/8 method.
  • constructDormandPrince8_64bit() - Dormand-Prince Order 7/8 method. Coefficients are rational approximations good for 64 bits.
  • constructVernerRobust9() - Verner's "most robust" order 9 method.
  • constructVernerEfficient9() - Verner's "most efficient" order 9 method.
  • constructSharp9() - Sharp's order 9 method.
  • constructTsitouras9() - Tsitouras's first order 9 method.
  • constructTsitouras92() - Tsitouras's second order 9 method.
  • constructCurtis10() - Curtis' order 10 method.
  • constructOno10() - Ono's order 10 method.
  • constructFeagin10Tableau() - Feagin's order 10 method.
  • constructCurtis10() - Curtis' order 10 method.
  • constructBaker10() - Baker's order 10 method.
  • constructHairer10() Hairer's order 10 method.
  • constructFeagin12Tableau() - Feagin's order 12 method.
  • constructOno12() - Ono's order 12 method.
  • constructFeagin14Tableau() Feagin's order 14 method.

Implicit Runge-Kutta Methods

  • constructImplicitEuler - The 1st order Implicit Euler method.
  • constructMidpointRule - The 2nd order Midpoint method.
  • constructTrapezoidalRule - The 2nd order Trapezoidal rule (2nd order LobattoIIIA)
  • constructLobattoIIIA4 - The 4th order LobattoIIIA
  • constructLobattoIIIB2 - The 2nd order LobattoIIIB
  • constructLobattoIIIB4 - The 4th order LobattoIIIB
  • constructLobattoIIIC2 - The 2nd order LobattoIIIC
  • constructLobattoIIIC4 - The 4th order LobattoIIIC
  • constructLobattoIIICStar2 - The 2nd order LobattoIIIC*
  • constructLobattoIIICStar4 - The 4th order LobattoIIIC*
  • constructLobattoIIID2 - The 2nd order LobattoIIID
  • constructLobattoIIID4 - The 4th order LobattoIIID
  • constructRadauIA3 - The 3rd order RadauIA
  • constructRadauIA5 - The 5th order RadauIA
  • constructRadauIIA3 - The 3rd order RadauIIA
  • constructRadauIIA5 - The 5th order RadauIIA

Tableau Methods

DiffEqDevTools.stability_region — Function

stability_region(z,tab::ODERKTableau)

Calculates the stability function from the tableau at z. Stable if <1.

\[r(z) = 1 + z bᵀ(I - zA)⁻¹ e\]

where e denotes a vector of ones.

stability_region(tab::ODERKTableau; initial_guess=-3.0)

Calculates the length of the stability region in the real axis.

Explicit Tableaus

Missing docstring.

Missing docstring for OrdinaryDiffEq.constructBS3. Check Documenter's build log for details.

Missing docstring.

Missing docstring for DiffEqDevTools.constructDormandPrince. Check Documenter's build log for details.

Missing docstring.

Missing docstring for OrdinaryDiffEq.constructBS5. Check Documenter's build log for details.

DiffEqDevTools.constructPapakostasPapaGeorgiou5 — Function

S.N. Papakostas and G. PapaGeorgiou higher error more stable

A Family of Fifth-order Runge-Kutta Pairs, by S.N. Papakostas and G. PapaGeorgiou, Mathematics of Computation,Volume 65, Number 215, July 1996, Pages 1165-1181.

DiffEqDevTools.constructPapakostasPapaGeorgiou52 — Function

S.N. Papakostas and G. PapaGeorgiou less stable lower error Strictly better than DP5

A Family of Fifth-order Runge-Kutta Pairs, by S.N. Papakostas and G. PapaGeorgiou, Mathematics of Computation,Volume 65, Number 215, July 1996, Pages 1165-1181.

DiffEqDevTools.constructTsitouras5 — Function

Runge–Kutta pairs of orders 5(4) using the minimal set of simplifying assumptions, by Ch. Tsitouras, TEI of Chalkis, Dept. of Applied Sciences, GR34400, Psahna, Greece.

DiffEqDevTools.constructLutherKonen5 — Function

Luther and Konen's First Order 5 Some Fifth-Order Classical Runge Kutta Formulas, H.A.Luther and H.P.Konen, Siam Review, Vol. 3, No. 7, (Oct., 1965) pages 551-558.

DiffEqDevTools.constructLutherKonen52 — Function

Luther and Konen's Second Order 5 Some Fifth-Order Classical Runge Kutta Formulas, H.A.Luther and H.P.Konen, Siam Review, Vol. 3, No. 7, (Oct., 1965) pages 551-558.

DiffEqDevTools.constructLutherKonen53 — Function

Luther and Konen's Third Order 5 Some Fifth-Order Classical Runge Kutta Formulas, H.A.Luther and H.P.Konen, Siam Review, Vol. 3, No. 7, (Oct., 1965) pages 551-558.

DiffEqDevTools.constructLawson5 — Function

Lawson's 5th order scheme

An Order Five Runge Kutta Process with Extended Region of Stability, J. Douglas Lawson, Siam Journal on Numerical Analysis, Vol. 3, No. 4, (Dec., 1966) pages 593-597

DiffEqDevTools.constructSharpSmart5 — Function

Explicit Runge-Kutta Pairs with One More Derivative Evaluation than the Minimum, by P.W.Sharp and E.Smart, Siam Journal of Scientific Computing, Vol. 14, No. 2, pages. 338-348, March 1993.

DiffEqDevTools.constructBogakiShampine5 — Function

An Efficient Runge-Kutta (4,5) Pair by P.Bogacki and L.F.Shampine Computers and Mathematics with Applications, Vol. 32, No. 6, 1996, pages 15 to 28

DiffEqDevTools.constructButcher6 — Function

Butcher's First Order 6 method

On Runge-Kutta Processes of High Order, by J. C. Butcher, Journal of the Australian Mathematical Society, Vol. 4, (1964), pages 179 to 194

DiffEqDevTools.constructButcher62 — Function

Butcher's Second Order 6 method

On Runge-Kutta Processes of High Order, by J. C. Butcher, Journal of the Australian Mathematical Society, Vol. 4, (1964), pages 179 to 194

DiffEqDevTools.constructButcher63 — Function

Butcher's Third Order 6

On Runge-Kutta Processes of High Order, by J. C. Butcher, Journal of the Australian Mathematical Society, Vol. 4, (1964), pages 179 to 194

DiffEqDevTools.constructTanakaKasugaYamashitaYazaki6A — Function

TanakaKasugaYamashitaYazaki Order 6 A

On the Optimization of Some Eight-stage Sixth-order Explicit Runge-Kutta Method, by M. Tanaka, K. Kasuga, S. Yamashita and H. Yazaki, Journal of the Information Processing Society of Japan, Vol. 34, No. 1 (1993), pages 62 to 74.

DiffEqDevTools.constructTanakaKasugaYamashitaYazaki6B — Function

constructTanakaKasugaYamashitaYazaki Order 6 B

On the Optimization of Some Eight-stage Sixth-order Explicit Runge-Kutta Method, by M. Tanaka, K. Kasuga, S. Yamashita and H. Yazaki, Journal of the Information Processing Society of Japan, Vol. 34, No. 1 (1993), pages 62 to 74.

DiffEqDevTools.constructTanakaKasugaYamashitaYazaki6C — Function

constructTanakaKasugaYamashitaYazaki Order 6 C

On the Optimization of Some Eight-stage Sixth-order Explicit Runge-Kutta Method, by M. Tanaka, K. Kasuga, S. Yamashita and H. Yazaki, Journal of the Information Processing Society of Japan, Vol. 34, No. 1 (1993), pages 62 to 74.

DiffEqDevTools.constructTanakaKasugaYamashitaYazaki6D — Function

constructTanakaKasugaYamashitaYazaki Order 6 D

On the Optimization of Some Eight-stage Sixth-order Explicit Runge-Kutta Method, by M. Tanaka, K. Kasuga, S. Yamashita and H. Yazaki, Journal of the Information Processing Society of Japan, Vol. 34, No. 1 (1993), pages 62 to 74.

DiffEqDevTools.constructHuta6 — Function

Anton Hutas First Order 6 method

Une amélioration de la méthode de Runge-Kutta-Nyström pour la résolution numérique des équations différentielles du premièr ordre, by Anton Huta, Acta Fac. Nat. Univ. Comenian Math., Vol. 1, pages 201-224 (1956).

DiffEqDevTools.constructHuta62 — Function

Anton Hutas Second Order 6 method

Une amélioration de la méthode de Runge-Kutta-Nyström pour la résolution numérique des équations différentielles du premièr ordre, by Anton Huta, Acta Fac. Nat. Univ. Comenian Math., Vol. 1, pages 201-224 (1956).

DiffEqDevTools.constructVerner6 — Function

Verner Order 5/6 method

A Contrast of a New RK56 pair with DP56, by Jim Verner, Department of Mathematics. Simon Fraser University, Burnaby, Canada, 2006.

DiffEqDevTools.constructDormandPrince6 — Function

Dormand-Prince Order 5//6 method

P.J. Prince and J. R. Dormand, High order embedded Runge-Kutta formulae, Journal of Computational and Applied Mathematics . 7 (1981), pp. 67-75.

DiffEqDevTools.constructSharpVerner6 — Function

Sharp-Verner Order 5/6 method

Completely Imbedded Runge-Kutta Pairs, by P. W. Sharp and J. H. Verner, SIAM Journal on Numerical Analysis, Vol. 31, No. 4. (Aug., 1994), pages. 1169 to 1190.

Missing docstring.

Missing docstring for DiffEqDevTools.constructVern6. Check Documenter's build log for details.

DiffEqDevTools.constructChummund6 — Function

Chummund's First Order 6 method

A three-dimensional family of seven-step Runge-Kutta methods of order 6, by G. M. Chammud (Hammud), Numerical Methods and programming, 2001, Vol.2, 2001, pages 159-166 (Advanced Computing Scientific journal published by the Research Computing Center of the Lomonosov Moscow State Univeristy)

DiffEqDevTools.constructChummund62 — Function

Chummund's Second Order 6 method

A three-dimensional family of seven-step Runge-Kutta methods of order 6, by G. M. Chammud (Hammud), Numerical Methods and programming, 2001, Vol.2, 2001, pages 159-166 (Advanced Computing Scientific journal published by the Research Computing Center of the Lomonosov Moscow State Univeristy)

DiffEqDevTools.constructPapakostas6 — Function

Papakostas's Order 6

On Phase-Fitted modified Runge-Kutta Pairs of order 6(5), by Ch. Tsitouras and I. Th. Famelis, International Conference of Numerical Analysis and Applied Mathematics, Crete, (2006)

DiffEqDevTools.constructLawson6 — Function

Lawson's Order 6

An Order 6 Runge-Kutta Process with an Extended Region of Stability, by J. D. Lawson, Siam Journal on Numerical Analysis, Vol. 4, No. 4 (Dec. 1967) pages 620-625.

DiffEqDevTools.constructTsitourasPapakostas6 — Function

Tsitouras-Papakostas's Order 6

Cheap Error Estimation for Runge-Kutta methods, by Ch. Tsitouras and S.N. Papakostas, Siam Journal on Scientific Computing, Vol. 20, Issue 6, Nov 1999.

DiffEqDevTools.constructDormandLockyerMcCorriganPrince6 — Function

DormandLockyerMcCorriganPrince Order 6 Global Error Estimation

Global Error estimation with Runge-Kutta triples, by J.R.Dormand, M.A.Lockyer, N.E.McCorrigan and P.J.Prince, Computers and Mathematics with Applications, 18 (1989) pages 835-846.

DiffEqDevTools.constructMikkawyEisa — Function

Mikkawy-Eisa Order 6

A general four-parameter non-FSAL embedded Runge–Kutta algorithm of orders 6 and 4 in seven stages, by M.E.A. El-Mikkawy and M.M.M. Eisa, Applied Mathematics and Computation, Vol. 143, No. 2, (2003) pages 259 to 267.

DiffEqDevTools.constructSharpVerner7 — Function

Completely Imbedded Runge-Kutta Pairs, by P.W.Sharp and J.H.Verner, Siam Journal on Numerical Analysis, Vol.31, No.4. (August 1994) pages 1169-1190.

DiffEqDevTools.constructTanakaYamashitaStable7 — Function

On the Optimization of Some Nine-Stage Seventh-order Runge-Kutta Method, by M. Tanaka, S. Muramatsu and S. Yamashita, Information Processing Society of Japan, Vol. 33, No. 12 (1992) pages 1512-1526.

DiffEqDevTools.constructSharpSmart7 — Function

Explicit Runge-Kutta Pairs with One More Derivative Evaluation than the Minimum, by P.W.Sharp and E.Smart, Siam Journal of Scientific Computing, Vol. 14, No. 2, pages. 338-348, March 1993.

DiffEqDevTools.constructTanakaYamashitaEfficient7 — Function

On the Optimization of Some Nine-Stage Seventh-order Runge-Kutta Method, by M. Tanaka, S. Muramatsu and S. Yamashita, Information Processing Society of Japan, Vol. 33, No. 12 (1992) pages 1512-1526.

Missing docstring.

Missing docstring for OrdinaryDiffEq.constructTanYam7. Check Documenter's build log for details.

DiffEqDevTools.constructEnrightVerner7 — Function

The Relative Efficiency of Alternative Defect Control Schemes for High-Order Continuous Runge-Kutta Formulas W. H. Enright SIAM Journal on Numerical Analysis, Vol. 30, No. 5. (Oct., 1993), pp. 1419-1445.

DiffEqDevTools.constructCooperVerner8 — Function

Some Explicit Runge-Kutta Methods of High Order, by G. J. Cooper and J. H. Verner, SIAM Journal on Numerical Analysis, Vol. 9, No. 3, (September 1972), pages 389 to 405

DiffEqDevTools.constructCooperVerner82 — Function

Some Explicit Runge-Kutta Methods of High Order, by G. J. Cooper and J. H. Verner, SIAM Journal on Numerical Analysis, Vol. 9, No. 3, (September 1972), pages 389 to 405

DiffEqDevTools.constructEnrightVerner8 — Function

The Relative Efficiency of Alternative Defect Control Schemes for High-Order Continuous Runge-Kutta Formulas W. H. Enright SIAM Journal on Numerical Analysis, Vol. 30, No. 5. (Oct., 1993), pp. 1419-1445.

DiffEqDevTools.constructDormandPrince8_64bit — Function

constructDormandPrice8_64bit()

Constructs the tableau object for the Dormand-Prince Order 6/8 method with the approximated coefficients from the paper. This works until below 64-bit precision.

DiffEqDevTools.constructCurtis8 — Function

An Eighth Order Runge-Kutta process with Eleven Function Evaluations per Step, by A. R. Curtis, Numerische Mathematik, Vol. 16, No. 3 (1970), pages 268 to 277

Missing docstring.

Missing docstring for OrdinaryDiffEq.constructTsitPap8. Check Documenter's build log for details.

DiffEqDevTools.constructSharp9 — Function

Journal of Applied Mathematics & Decision Sciences, 4(2), 183-192 (2000), "High order explicit Runge-Kutta pairs for ephemerides of the Solar System and the Moon".

Missing docstring.

Missing docstring for OrdinaryDiffEq.constructVern9. Check Documenter's build log for details.

DiffEqDevTools.constructVerner916 — Function

Verner 1991 First Order 5/6 method

Some Ruge-Kutta Formula Pairs, by J.H.Verner, SIAM Journal on Numerical Analysis, Vol. 28, No. 2 (April 1991), pages 496 to 511.

DiffEqDevTools.constructVerner9162 — Function

Verner 1991 Second Order 5/6 method

Some Ruge-Kutta Formula Pairs, by J.H.Verner, SIAM Journal on Numerical Analysis, Vol. 28, No. 2 (April 1991), pages 496 to 511.

Missing docstring.

Missing docstring for DiffEqDevTools.constructFeagin10Tableau. Check Documenter's build log for details.

DiffEqDevTools.constructCurtis10 — Function

High-order Explicit Runge-Kutta Formulae, Their uses, and Limitations, A.R.Curtis, J. Inst. Maths Applics (1975) 16, 35-55.

DiffEqDevTools.constructBaker10 — Function

Tom Baker, University of Teeside. Part of RK-Aid http://www.scm.tees.ac.uk/users/u0000251/research/researcht.htm http://www.scm.tees.ac.uk/users/u0000251/j.r.dormand/t.baker/rk10921m/rk10921m

DiffEqDevTools.constructOno12 — Function

On the 25 stage 12th order explicit Runge-Kutta method, by Hiroshi Ono. Transactions of the Japan Society for Industrial and applied Mathematics, Vol. 6, No. 3, (2006) pages 177 to 186

Missing docstring.

Missing docstring for DiffEqDevTools.constructFeagin12Tableau. Check Documenter's build log for details.

Missing docstring.

Missing docstring for DiffEqDevTools.constructFeagin14Tableau. Check Documenter's build log for details.

Implicit Tableaus

+
Edit on GitHub

ODE Tableaus

Explicit Runge-Kutta Methods

  • constructEuler - Euler's 1st order method.
  • constructHeun() Heun's order 2 method.
  • constructRalston() - Ralston's order 2 method.
  • constructSSPRK22() - Explicit SSP method of order 2 using 2 stages.
  • constructKutta3 - Kutta's classic 3rd order method.
  • constructSSPRK33() - Explicit SSP method of order 3 using 3 stages.
  • constructSSPRK43() - Explicit SSP method of order 3 using 4 stages.
  • constructRK4 - The classic 4th order "Runge-Kutta" method.
  • constructRK438Rule - The classic 4th order "3/8th's Rule" method.
  • constructSSPRK104() - Explicit SSP method of order 4 using 10 stages.
  • constructBogakiShampine3() - Bogakai-Shampine's 2/3 method.
  • constructRKF4() - Runge-Kutta-Fehlberg 3/4.
  • constructRKF5() - Runge-Kutta-Fehlberg 4/5.
  • constructRungeFirst5() - Runge's first 5th order method.
  • constructCassity5() - Cassity's 5th order method.
  • constructLawson5() - Lawson's 5th order method.
  • constructLutherKonen5 - Luther-Konen's first 5th order method.
  • constructLutherKonen52() - Luther-Konen's second 5th order method.
  • constructLutherKonen53() - Luther-Konen's third 5th order method.
  • constructPapakostasPapaGeorgiou5() - Papakostas and PapaGeorgiou more stable order 5 method.
  • constructPapakostasPapaGeorgiou52() - Papakostas and PapaGeorgiou more efficient order 5 method.
  • constructTsitouras5() - Tsitouras's order 5 method.
  • constructBogakiShampine5() - Bogaki and Shampine's Order 5 method.
  • constructSharpSmart5() - Sharp and Smart's Order 5 method.
  • constructCashKarp() - Cash-Karp method 4/5.
  • constructDormandPrince() - Dormand-Prince 4/5.
  • constructButcher6() - Butcher's first order 6 method.
  • constructButcher62() - Butcher's second order 6 method.
  • constructButcher63() - Butcher's third order 6 method.
  • constructDormandPrince6() - Dormand-Prince's 5/6 method.
  • constructSharpVerner6() Sharp-Verner's 5/6 method.
  • constructVerner916() - Verner's more efficient order 6 method (1991).
  • constructVerner9162() - Verner's second more efficient order 6 method (1991).
  • constructVernerRobust6() - Verner's "most robust" order 6 method.
  • constructVernerEfficient6() - Verner's "most efficient" order 6 method.
  • constructPapakostas6() - Papakostas's order 6 method.
  • constructLawson6() - Lawson's order 6 method.
  • constructTsitourasPapakostas6() - Tsitouras and Papakostas's order 6 method.
  • constructDormandLockyerMcCorriganPrince6() - the Dormand-Lockyer-McCorrigan-Prince order 6 method.
  • constructTanakaKasugaYamashitaYazaki6A() - Tanaka-Kasuga-Yamashita-Yazaki order 6 method A.
  • constructTanakaKasugaYamashitaYazaki6B() - Tanaka-Kasuga-Yamashita-Yazaki order 6 method B.
  • constructTanakaKasugaYamashitaYazaki6C() - Tanaka-Kasuga-Yamashita-Yazaki order 6 method C.
  • constructTanakaKasugaYamashitaYazaki6D() - Tanaka-Kasuga-Yamashita-Yazaki order 6 method D.
  • constructMikkawyEisa() - Mikkawy and Eisa's order 6 method.
  • constructChummund6() - Chummund's first order 6 method.
  • constructChummund62() - Chummund's second order 6 method.
  • constructHuta6() - Huta's first order 6 method.
  • constructHuta62() - Huta's second order 6 method.
  • constructVerner6() - An old order 6 method attributed to Verner.
  • constructDverk() - The classic DVERK algorithm attributed to Verner.
  • constructClassicVerner6() - A classic Verner order 6 algorithm (1978).
  • constructButcher7() - Butcher's order 7 algorithm.
  • constructClassicVerner7()- A classic Verner order 7 algorithm (1978).
  • constructVernerRobust7() - Verner's "most robust" order 7 algorithm.
  • constructTanakaYamashitaStable7() - Tanaka-Yamashita more stable order 7 algorithm.
  • constructTanakaYamashitaEfficient7() - Tanaka-Yamashita more efficient order 7 algorithm.
  • constructSharpSmart7() - Sharp-Smart's order 7 algorithm.
  • constructSharpVerner7() - Sharp-Verner's order 7 algorithm.
  • constructVerner7() - Verner's "most efficient" order 7 algorithm.
  • constructVernerEfficient7() - Verner's "most efficient" order 7 algorithm.
  • constructClassicVerner8() - A classic Verner order 8 algorithm (1978).
  • constructCooperVerner8() - Cooper-Verner's first order 8 algorithm.
  • constructCooperVerner82() - Cooper-Verner's second order 8 algorithm.
  • constructTsitourasPapakostas8() - Tsitouras-Papakostas order 8 algorithm.
  • constructdverk78() - The classic order 8 DVERK algorithm.
  • constructEnrightVerner8() - Enright-Verner order 8 algorithm.
  • constructCurtis8() - Curtis' order 8 algorithm.
  • constructVerner8() - Verner's "most efficient" order 8 algorithm.
  • constructRKF8() - Runge-Kutta-Fehlberg Order 7/8 method.
  • constructDormandPrice8() - Dormand-Prince Order 7/8 method.
  • constructDormandPrince8_64bit() - Dormand-Prince Order 7/8 method. Coefficients are rational approximations good for 64 bits.
  • constructVernerRobust9() - Verner's "most robust" order 9 method.
  • constructVernerEfficient9() - Verner's "most efficient" order 9 method.
  • constructSharp9() - Sharp's order 9 method.
  • constructTsitouras9() - Tsitouras's first order 9 method.
  • constructTsitouras92() - Tsitouras's second order 9 method.
  • constructCurtis10() - Curtis' order 10 method.
  • constructOno10() - Ono's order 10 method.
  • constructFeagin10Tableau() - Feagin's order 10 method.
  • constructCurtis10() - Curtis' order 10 method.
  • constructBaker10() - Baker's order 10 method.
  • constructHairer10() Hairer's order 10 method.
  • constructFeagin12Tableau() - Feagin's order 12 method.
  • constructOno12() - Ono's order 12 method.
  • constructFeagin14Tableau() Feagin's order 14 method.

Implicit Runge-Kutta Methods

  • constructImplicitEuler - The 1st order Implicit Euler method.
  • constructMidpointRule - The 2nd order Midpoint method.
  • constructTrapezoidalRule - The 2nd order Trapezoidal rule (2nd order LobattoIIIA)
  • constructLobattoIIIA4 - The 4th order LobattoIIIA
  • constructLobattoIIIB2 - The 2nd order LobattoIIIB
  • constructLobattoIIIB4 - The 4th order LobattoIIIB
  • constructLobattoIIIC2 - The 2nd order LobattoIIIC
  • constructLobattoIIIC4 - The 4th order LobattoIIIC
  • constructLobattoIIICStar2 - The 2nd order LobattoIIIC*
  • constructLobattoIIICStar4 - The 4th order LobattoIIIC*
  • constructLobattoIIID2 - The 2nd order LobattoIIID
  • constructLobattoIIID4 - The 4th order LobattoIIID
  • constructRadauIA3 - The 3rd order RadauIA
  • constructRadauIA5 - The 5th order RadauIA
  • constructRadauIIA3 - The 3rd order RadauIIA
  • constructRadauIIA5 - The 5th order RadauIIA

Tableau Methods

DiffEqDevTools.stability_region — Function

stability_region(z,tab::ODERKTableau)

Calculates the stability function from the tableau at z. Stable if <1.

\[r(z) = 1 + z bᵀ(I - zA)⁻¹ e\]

where e denotes a vector of ones.

stability_region(tab::ODERKTableau; initial_guess=-3.0)

Calculates the length of the stability region in the real axis.

Explicit Tableaus

Missing docstring.

Missing docstring for OrdinaryDiffEq.constructBS3. Check Documenter's build log for details.

Missing docstring.

Missing docstring for DiffEqDevTools.constructDormandPrince. Check Documenter's build log for details.

Missing docstring.

Missing docstring for OrdinaryDiffEq.constructBS5. Check Documenter's build log for details.

DiffEqDevTools.constructPapakostasPapaGeorgiou5 — Function

S.N. Papakostas and G. PapaGeorgiou higher error more stable

A Family of Fifth-order Runge-Kutta Pairs, by S.N. Papakostas and G. PapaGeorgiou, Mathematics of Computation,Volume 65, Number 215, July 1996, Pages 1165-1181.

DiffEqDevTools.constructPapakostasPapaGeorgiou52 — Function

S.N. Papakostas and G. PapaGeorgiou less stable lower error Strictly better than DP5

A Family of Fifth-order Runge-Kutta Pairs, by S.N. Papakostas and G. PapaGeorgiou, Mathematics of Computation,Volume 65, Number 215, July 1996, Pages 1165-1181.

DiffEqDevTools.constructTsitouras5 — Function

Runge–Kutta pairs of orders 5(4) using the minimal set of simplifying assumptions, by Ch. Tsitouras, TEI of Chalkis, Dept. of Applied Sciences, GR34400, Psahna, Greece.

DiffEqDevTools.constructLutherKonen5 — Function

Luther and Konen's First Order 5 Some Fifth-Order Classical Runge Kutta Formulas, H.A.Luther and H.P.Konen, Siam Review, Vol. 3, No. 7, (Oct., 1965) pages 551-558.

DiffEqDevTools.constructLutherKonen52 — Function

Luther and Konen's Second Order 5 Some Fifth-Order Classical Runge Kutta Formulas, H.A.Luther and H.P.Konen, Siam Review, Vol. 3, No. 7, (Oct., 1965) pages 551-558.

DiffEqDevTools.constructLutherKonen53 — Function

Luther and Konen's Third Order 5 Some Fifth-Order Classical Runge Kutta Formulas, H.A.Luther and H.P.Konen, Siam Review, Vol. 3, No. 7, (Oct., 1965) pages 551-558.

DiffEqDevTools.constructLawson5 — Function

Lawson's 5th order scheme

An Order Five Runge Kutta Process with Extended Region of Stability, J. Douglas Lawson, Siam Journal on Numerical Analysis, Vol. 3, No. 4, (Dec., 1966) pages 593-597

DiffEqDevTools.constructSharpSmart5 — Function

Explicit Runge-Kutta Pairs with One More Derivative Evaluation than the Minimum, by P.W.Sharp and E.Smart, Siam Journal of Scientific Computing, Vol. 14, No. 2, pages. 338-348, March 1993.

DiffEqDevTools.constructBogakiShampine5 — Function

An Efficient Runge-Kutta (4,5) Pair by P.Bogacki and L.F.Shampine Computers and Mathematics with Applications, Vol. 32, No. 6, 1996, pages 15 to 28

DiffEqDevTools.constructButcher6 — Function

Butcher's First Order 6 method

On Runge-Kutta Processes of High Order, by J. C. Butcher, Journal of the Australian Mathematical Society, Vol. 4, (1964), pages 179 to 194

DiffEqDevTools.constructButcher62 — Function

Butcher's Second Order 6 method

On Runge-Kutta Processes of High Order, by J. C. Butcher, Journal of the Australian Mathematical Society, Vol. 4, (1964), pages 179 to 194

DiffEqDevTools.constructButcher63 — Function

Butcher's Third Order 6

On Runge-Kutta Processes of High Order, by J. C. Butcher, Journal of the Australian Mathematical Society, Vol. 4, (1964), pages 179 to 194

DiffEqDevTools.constructTanakaKasugaYamashitaYazaki6A — Function

TanakaKasugaYamashitaYazaki Order 6 A

On the Optimization of Some Eight-stage Sixth-order Explicit Runge-Kutta Method, by M. Tanaka, K. Kasuga, S. Yamashita and H. Yazaki, Journal of the Information Processing Society of Japan, Vol. 34, No. 1 (1993), pages 62 to 74.

DiffEqDevTools.constructTanakaKasugaYamashitaYazaki6B — Function

constructTanakaKasugaYamashitaYazaki Order 6 B

On the Optimization of Some Eight-stage Sixth-order Explicit Runge-Kutta Method, by M. Tanaka, K. Kasuga, S. Yamashita and H. Yazaki, Journal of the Information Processing Society of Japan, Vol. 34, No. 1 (1993), pages 62 to 74.

DiffEqDevTools.constructTanakaKasugaYamashitaYazaki6C — Function

constructTanakaKasugaYamashitaYazaki Order 6 C

On the Optimization of Some Eight-stage Sixth-order Explicit Runge-Kutta Method, by M. Tanaka, K. Kasuga, S. Yamashita and H. Yazaki, Journal of the Information Processing Society of Japan, Vol. 34, No. 1 (1993), pages 62 to 74.

DiffEqDevTools.constructTanakaKasugaYamashitaYazaki6D — Function

constructTanakaKasugaYamashitaYazaki Order 6 D

On the Optimization of Some Eight-stage Sixth-order Explicit Runge-Kutta Method, by M. Tanaka, K. Kasuga, S. Yamashita and H. Yazaki, Journal of the Information Processing Society of Japan, Vol. 34, No. 1 (1993), pages 62 to 74.

DiffEqDevTools.constructHuta6 — Function

Anton Hutas First Order 6 method

Une amélioration de la méthode de Runge-Kutta-Nyström pour la résolution numérique des équations différentielles du premièr ordre, by Anton Huta, Acta Fac. Nat. Univ. Comenian Math., Vol. 1, pages 201-224 (1956).

DiffEqDevTools.constructHuta62 — Function

Anton Hutas Second Order 6 method

Une amélioration de la méthode de Runge-Kutta-Nyström pour la résolution numérique des équations différentielles du premièr ordre, by Anton Huta, Acta Fac. Nat. Univ. Comenian Math., Vol. 1, pages 201-224 (1956).

DiffEqDevTools.constructVerner6 — Function

Verner Order 5/6 method

A Contrast of a New RK56 pair with DP56, by Jim Verner, Department of Mathematics. Simon Fraser University, Burnaby, Canada, 2006.

DiffEqDevTools.constructDormandPrince6 — Function

Dormand-Prince Order 5//6 method

P.J. Prince and J. R. Dormand, High order embedded Runge-Kutta formulae, Journal of Computational and Applied Mathematics . 7 (1981), pp. 67-75.

DiffEqDevTools.constructSharpVerner6 — Function

Sharp-Verner Order 5/6 method

Completely Imbedded Runge-Kutta Pairs, by P. W. Sharp and J. H. Verner, SIAM Journal on Numerical Analysis, Vol. 31, No. 4. (Aug., 1994), pages. 1169 to 1190.

Missing docstring.

Missing docstring for DiffEqDevTools.constructVern6. Check Documenter's build log for details.

DiffEqDevTools.constructChummund6 — Function

Chummund's First Order 6 method

A three-dimensional family of seven-step Runge-Kutta methods of order 6, by G. M. Chammud (Hammud), Numerical Methods and programming, 2001, Vol.2, 2001, pages 159-166 (Advanced Computing Scientific journal published by the Research Computing Center of the Lomonosov Moscow State Univeristy)

DiffEqDevTools.constructChummund62 — Function

Chummund's Second Order 6 method

A three-dimensional family of seven-step Runge-Kutta methods of order 6, by G. M. Chammud (Hammud), Numerical Methods and programming, 2001, Vol.2, 2001, pages 159-166 (Advanced Computing Scientific journal published by the Research Computing Center of the Lomonosov Moscow State Univeristy)

DiffEqDevTools.constructPapakostas6 — Function

Papakostas's Order 6

On Phase-Fitted modified Runge-Kutta Pairs of order 6(5), by Ch. Tsitouras and I. Th. Famelis, International Conference of Numerical Analysis and Applied Mathematics, Crete, (2006)

DiffEqDevTools.constructLawson6 — Function

Lawson's Order 6

An Order 6 Runge-Kutta Process with an Extended Region of Stability, by J. D. Lawson, Siam Journal on Numerical Analysis, Vol. 4, No. 4 (Dec. 1967) pages 620-625.

DiffEqDevTools.constructTsitourasPapakostas6 — Function

Tsitouras-Papakostas's Order 6

Cheap Error Estimation for Runge-Kutta methods, by Ch. Tsitouras and S.N. Papakostas, Siam Journal on Scientific Computing, Vol. 20, Issue 6, Nov 1999.

DiffEqDevTools.constructDormandLockyerMcCorriganPrince6 — Function

DormandLockyerMcCorriganPrince Order 6 Global Error Estimation

Global Error estimation with Runge-Kutta triples, by J.R.Dormand, M.A.Lockyer, N.E.McCorrigan and P.J.Prince, Computers and Mathematics with Applications, 18 (1989) pages 835-846.

DiffEqDevTools.constructMikkawyEisa — Function

Mikkawy-Eisa Order 6

A general four-parameter non-FSAL embedded Runge–Kutta algorithm of orders 6 and 4 in seven stages, by M.E.A. El-Mikkawy and M.M.M. Eisa, Applied Mathematics and Computation, Vol. 143, No. 2, (2003) pages 259 to 267.

DiffEqDevTools.constructSharpVerner7 — Function

Completely Imbedded Runge-Kutta Pairs, by P.W.Sharp and J.H.Verner, Siam Journal on Numerical Analysis, Vol.31, No.4. (August 1994) pages 1169-1190.

DiffEqDevTools.constructTanakaYamashitaStable7 — Function

On the Optimization of Some Nine-Stage Seventh-order Runge-Kutta Method, by M. Tanaka, S. Muramatsu and S. Yamashita, Information Processing Society of Japan, Vol. 33, No. 12 (1992) pages 1512-1526.

DiffEqDevTools.constructSharpSmart7 — Function

Explicit Runge-Kutta Pairs with One More Derivative Evaluation than the Minimum, by P.W.Sharp and E.Smart, Siam Journal of Scientific Computing, Vol. 14, No. 2, pages. 338-348, March 1993.

DiffEqDevTools.constructTanakaYamashitaEfficient7 — Function

On the Optimization of Some Nine-Stage Seventh-order Runge-Kutta Method, by M. Tanaka, S. Muramatsu and S. Yamashita, Information Processing Society of Japan, Vol. 33, No. 12 (1992) pages 1512-1526.

Missing docstring.

Missing docstring for OrdinaryDiffEq.constructTanYam7. Check Documenter's build log for details.

DiffEqDevTools.constructEnrightVerner7 — Function

The Relative Efficiency of Alternative Defect Control Schemes for High-Order Continuous Runge-Kutta Formulas W. H. Enright SIAM Journal on Numerical Analysis, Vol. 30, No. 5. (Oct., 1993), pp. 1419-1445.

DiffEqDevTools.constructCooperVerner8 — Function

Some Explicit Runge-Kutta Methods of High Order, by G. J. Cooper and J. H. Verner, SIAM Journal on Numerical Analysis, Vol. 9, No. 3, (September 1972), pages 389 to 405

DiffEqDevTools.constructCooperVerner82 — Function

Some Explicit Runge-Kutta Methods of High Order, by G. J. Cooper and J. H. Verner, SIAM Journal on Numerical Analysis, Vol. 9, No. 3, (September 1972), pages 389 to 405

DiffEqDevTools.constructEnrightVerner8 — Function

The Relative Efficiency of Alternative Defect Control Schemes for High-Order Continuous Runge-Kutta Formulas W. H. Enright SIAM Journal on Numerical Analysis, Vol. 30, No. 5. (Oct., 1993), pp. 1419-1445.

DiffEqDevTools.constructDormandPrince8_64bit — Function

constructDormandPrice8_64bit()

Constructs the tableau object for the Dormand-Prince Order 6/8 method with the approximated coefficients from the paper. This works until below 64-bit precision.

DiffEqDevTools.constructCurtis8 — Function

An Eighth Order Runge-Kutta process with Eleven Function Evaluations per Step, by A. R. Curtis, Numerische Mathematik, Vol. 16, No. 3 (1970), pages 268 to 277

Missing docstring.

Missing docstring for OrdinaryDiffEq.constructTsitPap8. Check Documenter's build log for details.

DiffEqDevTools.constructSharp9 — Function

Journal of Applied Mathematics & Decision Sciences, 4(2), 183-192 (2000), "High order explicit Runge-Kutta pairs for ephemerides of the Solar System and the Moon".

Missing docstring.

Missing docstring for OrdinaryDiffEq.constructVern9. Check Documenter's build log for details.

DiffEqDevTools.constructVerner916 — Function

Verner 1991 First Order 5/6 method

Some Ruge-Kutta Formula Pairs, by J.H.Verner, SIAM Journal on Numerical Analysis, Vol. 28, No. 2 (April 1991), pages 496 to 511.

DiffEqDevTools.constructVerner9162 — Function

Verner 1991 Second Order 5/6 method

Some Ruge-Kutta Formula Pairs, by J.H.Verner, SIAM Journal on Numerical Analysis, Vol. 28, No. 2 (April 1991), pages 496 to 511.

Missing docstring.

Missing docstring for DiffEqDevTools.constructFeagin10Tableau. Check Documenter's build log for details.

DiffEqDevTools.constructCurtis10 — Function

High-order Explicit Runge-Kutta Formulae, Their uses, and Limitations, A.R.Curtis, J. Inst. Maths Applics (1975) 16, 35-55.

DiffEqDevTools.constructBaker10 — Function

Tom Baker, University of Teeside. Part of RK-Aid http://www.scm.tees.ac.uk/users/u0000251/research/researcht.htm http://www.scm.tees.ac.uk/users/u0000251/j.r.dormand/t.baker/rk10921m/rk10921m

DiffEqDevTools.constructOno12 — Function

On the 25 stage 12th order explicit Runge-Kutta method, by Hiroshi Ono. Transactions of the Japan Society for Industrial and applied Mathematics, Vol. 6, No. 3, (2006) pages 177 to 186

Missing docstring.

Missing docstring for DiffEqDevTools.constructFeagin12Tableau. Check Documenter's build log for details.

Missing docstring.

Missing docstring for DiffEqDevTools.constructFeagin14Tableau. Check Documenter's build log for details.

Implicit Tableaus

diff --git a/dev/search/index.html b/dev/search/index.html index 020bc71..0746e60 100644 --- a/dev/search/index.html +++ b/dev/search/index.html @@ -3,4 +3,4 @@ function gtag(){dataLayer.push(arguments);} gtag('js', new Date()); gtag('config', 'UA-90474609-3', {'page_path': location.pathname + location.search + location.hash}); -

Loading search...

    +

    Loading search...