sciml/diffeqproblemlibrary.jl

A library of premade problems for examples and testing differential equation solvers and other SciML scientific machine learning tools

DiffEqProblemLibrary.jl

DiffEqProblemLibrary.jl is a component package in the DifferentialEquations ecosystem. It contains premade problems for the differential equations solvers. These can either be used as tests or as examples to show how to use the the solvers. Check out the problems in the src directory. Users interested in using this functionality should check out DifferentialEquations.jl.

diffeqproblemlibrary.jl's Issues

Update Bruss for a new release of DiffEqOperators.jl

The API of DerivativeOperator has been changed.

https://github.com/JuliaDiffEq/DiffEqProblemLibrary.jl/blob/master/src/ode/brusselator_prob.jl#L100-L107

Published test problem set

https://128.84.21.199/abs/1901.04098

Register

@JuliaRegistrator register()
@JuliaRegistrator register subdir=lib/ODEProblemLibrary
@JuliaRegistrator register subdir=lib/DDEProblemLibrary
@JuliaRegistrator register subdir=lib/DAEProblemLibrary
@JuliaRegistrator register subdir=lib/JumpProblemLibrary
@JuliaRegistrator register subdir=lib/SDEProblemLibrary

Switch to JLD2

Lately it was difficult to test DelayDiffEq on Windows 32bit, since we often got HDF5 build errors (see SciML/DelayDiffEq.jl#17 (comment)). At least for DelayDiffEq, the dependency on HDF5 originates from DiffEqProblemLibrary, and in particular from its requirement JLD. Maybe it would be a good idea to switch to JLD2 which does not depend on the HDF5 C library?

Incremental compilation may be fatally broken for this module

I don't know how the current version of DiffEqProblemLibrary should be used in my package. If I run

using TestImports

for the following MWE

module TestImports

using DiffEqProblemLibrary.DDEProblemLibrary

DDEProblemLibrary.importddeproblems()

@show DDEProblemLibrary.prob_dde_constant_1delay_ip

end # module

with DiffEqProblemLibrary as only dependency, I get a lot of

  ** incremental compilation may be fatally broken for this module ** 

warnings, finally resulting in a segfault:

signal (11): Segmentation fault
in expression starting at REPL[3]:1
unknown function (ip: 0x7f6bafeb964f)
jl_deserialize_datatype at /buildworker/worker/package_linux64/build/src/dump.c:1343 [inlined]
jl_deserialize_value at /buildworker/worker/package_linux64/build/src/dump.c:2160
jl_deserialize_value_svec at /buildworker/worker/package_linux64/build/src/dump.c:1479 [inlined]
jl_deserialize_value at /buildworker/worker/package_linux64/build/src/dump.c:2008
jl_deserialize_value at /buildworker/worker/package_linux64/build/src/dump.c:1456
jl_deserialize_value_svec at /buildworker/worker/package_linux64/build/src/dump.c:1479 [inlined]
jl_deserialize_value at /buildworker/worker/package_linux64/build/src/dump.c:2008
jl_deserialize_value at /buildworker/worker/package_linux64/build/src/dump.c:1456
jl_deserialize_value_any at /buildworker/worker/package_linux64/build/src/dump.c:1932 [inlined]
jl_deserialize_value at /buildworker/worker/package_linux64/build/src/dump.c:2163
jl_deserialize_value at /buildworker/worker/package_linux64/build/src/dump.c:1784
jl_deserialize_value_array at /buildworker/worker/package_linux64/build/src/dump.c:1544
jl_deserialize_value at /buildworker/worker/package_linux64/build/src/dump.c:2029
_jl_restore_incremental at /buildworker/worker/package_linux64/build/src/dump.c:3159
jl_restore_incremental at /buildworker/worker/package_linux64/build/src/dump.c:3218
_include_from_serialized at ./loading.jl:669
_require_from_serialized at ./loading.jl:736
_require at ./loading.jl:1023
require at ./loading.jl:911
require at ./loading.jl:906
jl_apply_generic at /buildworker/worker/package_linux64/build/src/gf.c:2197
jl_apply at /buildworker/worker/package_linux64/build/src/julia.h:1614 [inlined]
call_require at /buildworker/worker/package_linux64/build/src/toplevel.c:399 [inlined]
eval_import_path at /buildworker/worker/package_linux64/build/src/toplevel.c:436
jl_toplevel_eval_flex at /buildworker/worker/package_linux64/build/src/toplevel.c:656
jl_toplevel_eval_flex at /buildworker/worker/package_linux64/build/src/toplevel.c:764
jl_toplevel_eval_in at /buildworker/worker/package_linux64/build/src/toplevel.c:844
eval at ./boot.jl:330
jl_apply_generic at /buildworker/worker/package_linux64/build/src/gf.c:2191
eval_user_input at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.2/REPL/src/REPL.jl:86
run_backend at /home/david/.julia/packages/Revise/JCJHO/src/Revise.jl:953
#77 at ./task.jl:268
jl_apply_generic at /buildworker/worker/package_linux64/build/src/gf.c:2197
jl_apply at /buildworker/worker/package_linux64/build/src/julia.h:1614 [inlined]
start_task at /buildworker/worker/package_linux64/build/src/task.c:596
unknown function (ip: 0xffffffffffffffff)
Allocations: 12720233 (Pool: 12717515; Big: 2718); GC: 26
zsh: segmentation fault (core dumped)  $HOME/opt/julia-1.2.0/bin/julia

After replacing module DDEProblemLibrary... end with

export importddeproblems
function importddeproblems()
  include(joinpath(@__DIR__, "dde/dde_premade_problems.jl"))
  nothing
end

and wrapping everything in dde_premade_problems.jl inside of a module DDEProblemLibrary + removing the deprecations in that file, and using

module TestImports

using DiffEqProblemLibrary

importddeproblems()

using DiffEqProblemLibrary.DDEProblemLibrary

@show DDEProblemLibrary.prob_dde_constant_1delay_ip

end # module

I can successfully run

julia> using TestImports                                                       
DDEProblemLibrary.prob_dde_constant_1delay_ip = DDEProblem with uType Array{Float64,1} and tType Float64. In-place: true
timespan: (0.0, 10.0)           
u0: [1.0]                                                                                                                           

However, unfortunately that's not a general solution since the same changes do not work for ODEProblemLibrary due to some evaluations of ModelingToolkit.

So I started to believe that the cleanest solution might actually be to break this package up into different packages such as (DiffEq)ODEProblemLibrary, (DiffEq)DDEProblemLibrary, and so on. Then there's no need for any optional evaluations anymore and (hopefully) everything should work as intended. Also, it would probably reduce the amount and interactions of dependencies which might sometimes be an issue, as we saw in the case of HomotopyContinuation in DiffEqBase.

Split into subpackages?

Would it be possible to move the submodules into separate packages, possibly in this repo? I still manage to hit pre-compilation/module loading issues with the current setup (a while ago: #51), and the current setup with importodeproblems() etc. that cause evaluation into the submodules is arguably a bit ugly. Personally I think it would be much nicer to be able to just write using DDEProblemLibrary instead of

using DiffEqProblemLibrary.DDEProblemLibrary
DDEProblemLibrary.importddeproblems()

Register

@JuliaRegistrator register()

Register

@JuliaRegistrator register()

Typo in the `vanstiff` docstring

The ODEs in the docstrings of prob_ode_vanderpol and prob_ode_vanstiff are not the same, even though both use the same van function.

If the problem is correctly defined, then line 83

DiffEqProblemLibrary.jl/src/ode/ode_simple_nonlinear_prob.jl

Line 83 in 87ca6f6

\\frac{dy}{dt} = μ(1-x^2)y -x

should be changed to be the same as line 67

DiffEqProblemLibrary.jl/src/ode/ode_simple_nonlinear_prob.jl

Line 67 in 87ca6f6

\\frac{dy}{dt} = μ((1-x^2)y -x)

I'll open a PR right away.

Register

@JuliaRegistrator register()

Set of Problems for Scientific Machine Learning

https://ftp.mcs.anl.gov/pub/tech_reports/reports/P153.pdf provides a decent list of "real-world" applications that could serve as a good test-bed for

1. https://github.com/SciML/ModelOrderReduction.jl @bowenszhu
2. https://github.com/SciML/MethodOfLines.jl @xtalax
3. https://github.com/SciML/NeuralOperators.jl @yuehhua
4. ...

Ties together well with SciML/NeuralOperators.jl#71

`prob_ode_lotkavoltera` should be called `prob_ode_lotkavolterra`

The system is called "Lotka-Volterra" - see for example the corresponding wikipedia article - so the problem and docstring should probably be adjusted to have the correct spelling. However, since probably a lot of tests everywhere depend on prob_ode_lotkavoltera, I have no idea how one would do such a change.

Register

@JuliaRegistrator register()

TagBot trigger issue

This issue is used to trigger TagBot; feel free to unsubscribe.

If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.

If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

BigFloat segfault

https://discourse.julialang.org/t/segfault-in-libgmp-so-in-show/4411

Error tagging new release

The tag name "v.2.4.6" is not of the appropriate SemVer form (vX.Y.Z).
cc: @ChrisRackauckas

Vectorized Bruss

 kernel_u! = let N=N, xyd=xyd_brusselator, dx=step(xyd_brusselator)
    @inline function (du, u, A, B, α, II, I, t)
      i, j = Tuple(I)
      x = xyd[I[1]]
      y = xyd[I[2]]
      ip1 = limit(i+1, N); im1 = limit(i-1, N)
      jp1 = limit(j+1, N); jm1 = limit(j-1, N)
      du[II[i,j,1]] = α[II[i,j,1]]*(u[II[im1,j,1]] + u[II[ip1,j,1]] + u[II[i,jp1,1]] + u[II[i,jm1,1]] - 4u[II[i,j,1]])/dx^2 +
      B[II[i,j,1]] + u[II[i,j,1]]^2*u[II[i,j,2]] - (A[II[i,j,1]] + 1)*u[II[i,j,1]] + brusselator_f(x, y, t)
    end
  end
  kernel_v! = let N=N, xyd=xyd_brusselator, dx=step(xyd_brusselator)
    @inline function (du, u, A, B, α, II, I, t)
      i, j = Tuple(I)
      ip1 = limit(i+1, N)
      im1 = limit(i-1, N)
      jp1 = limit(j+1, N)
      jm1 = limit(j-1, N)
      du[II[i,j,2]] = α[II[i,j,2]]*(u[II[im1,j,2]] + u[II[ip1,j,2]] + u[II[i,jp1,2]] + u[II[i,jm1,2]] - 4u[II[i,j,2]])/dx^2 +
      A[II[i,j,1]]*u[II[i,j,1]] - u[II[i,j,1]]^2*u[II[i,j,2]]
    end
  end
  brusselator_2d = let N=N, xyd=xyd_brusselator, dx=step(xyd_brusselator)
    function (du, u, p, t)
      @inbounds begin
        ii1 = N^2
        ii2 = ii1+N^2
        ii3 = ii2+2(N^2)
        A = @view p[1:ii1]
        B = @view p[ii1+1:ii2]
        α = @view p[ii2+1:ii3]
        II = LinearIndices((N, N, 2))
        kernel_u!.(Ref(du), Ref(u), Ref(A), Ref(B), Ref(α), Ref(II), CartesianIndices((N, N)), t)
        kernel_v!.(Ref(du), Ref(u), Ref(A), Ref(B), Ref(α), Ref(II), CartesianIndices((N, N)), t)
        return nothing
      end
    end
  end

compats deactivated

https://github.com/SciML/DiffEqProblemLibrary.jl/actions/workflows/CompatHelper.yml

BVP Test Problems

https://archimede.dm.uniba.it/~bvpsolvers/testsetbvpsolvers/?page_id=29

DDETST Equations

For evaluating DDEs

https://link.springer.com/chapter/10.1007%2F978-1-5041-2940-4_14

@devmotion

Submodules

It would be best to put the different types of problems in submodules, that way we can cut down on the test times.

DAE Test Problems

http://wwwf.imperial.ac.uk/~jcash/IVP_software/finaldae/readme.html
https://archimede.dm.uniba.it/~testset/testsetivpsolvers/?page_id=26

Stiff ODE Test Problems

We should try to finish up the standard problems.

http://www.unige.ch/~hairer/testset/testset.html
https://archimede.dm.uniba.it/~testset/testsetivpsolvers/?page_id=26

Nonlinear system of reactions with an analytical solution

https://link.springer.com/article/10.1007/s11071-011-0200-6

check problem name spelling

also, pleides not exported.
Maybe others as well?