StochasticDiffEq.jl
SciMLSensitivity.jl
StochasticDiffEq.jl | SciMLSensitivity.jl | |
---|---|---|
1 | 2 | |
235 | 316 | |
0.9% | 2.9% | |
7.8 | 9.5 | |
11 days ago | about 18 hours ago | |
Julia | Julia | |
GNU General Public License v3.0 or later | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
StochasticDiffEq.jl
-
Writing unit tests in scientific computing
For stochastic processes you have to work a little bit more. However maybe the StochasticDiffEq.jl package can give some guiding there https://github.com/SciML/StochasticDiffEq.jl/tree/master/test
SciMLSensitivity.jl
-
Accurate and Efficient Physics-Informed Learning Through Differentiable Simulation - Chris Rackauckas (ASA Statistical Computing & Graphics Sections)
Plenty of code examples! https://sensitivity.sciml.ai/dev is the main resource, but most of the papers mentioned have their own code repositories. I'm trying to get most of them updated and into the larger SciMLSensitivity docs so they are all tested, though we need new hosting computers to actually get that done.
-
“Why I still recommend Julia”
Can you point to a concrete example of one that someone would run into when using the differential equation solvers with the default and recommended Enzyme AD for vector-Jacobian products? I'd be happy to look into it, but there do not currently seem to be any correctness issues in the Enzyme issue tracker that are current (3 issues are open but they all seem to be fixed, other than https://github.com/EnzymeAD/Enzyme.jl/issues/278 which is actually an activity analysis bug in LLVM). So please be more specific. The issue with Enzyme right now seems to moreso be about finding functional forms that compile, and it throws compile-time errors in the event that it cannot fully analyze the program and if it has too much dynamic behavior (example: https://github.com/EnzymeAD/Enzyme.jl/issues/368).
Additional note, we recently did a overhaul of SciMLSensitivity (https://sensitivity.sciml.ai/dev/) and setup a system which amounts to 15 hours of direct unit tests doing a combinatoric check of arguments with 4 hours of downstream testing (https://github.com/SciML/SciMLSensitivity.jl/actions/runs/25...). What that identified is that any remaining issues that can arise are due to the implicit parameters mechanism in Zygote (Zygote.params). To counteract this upstream issue, we (a) try to default to never default to Zygote VJPs whenever we can avoid it (hence defaulting to Enzyme and ReverseDiff first as previously mentioned), and (b) put in a mechanism for early error throwing if Zygote hits any not implemented derivative case with an explicit error message (https://github.com/SciML/SciMLSensitivity.jl/blob/v7.0.1/src...). We have alerted the devs of the machine learning libraries, and from this there has been a lot of movement. In particular, a globals-free machine learning library, Lux.jl, was created with fully explicit parameters https://lux.csail.mit.edu/dev/, and thus by design it cannot have this issue. In addition, the Flux.jl library itself is looking to do a redesign that eliminates implicit parameters (https://github.com/FluxML/Flux.jl/issues/1986). Which design will be the one in the end, that's uncertain right now, but it's clear that no matter what the future designs of the deep learning libraries will fully cut out that part of Zygote.jl. And additionally, the other AD libraries (Enzyme and Diffractor for example) do not have this "feature", so it's an issue that can only arise from a specific (not recommended) way of using Zygote (which now throws explicit error messages early and often if used anywhere near SciML because I don't tolerate it).
So from this, SciML should be rather safe and if not, please share some details and I'd be happy to dig in.
What are some alternatives?
SciMLTutorials.jl - Tutorials for doing scientific machine learning (SciML) and high-performance differential equation solving with open source software.
DiffEqSensitivity.jl - A component of the DiffEq ecosystem for enabling sensitivity analysis for scientific machine learning (SciML). Optimize-then-discretize, discretize-then-optimize, and more for ODEs, SDEs, DDEs, DAEs, etc. [Moved to: https://github.com/SciML/SciMLSensitivity.jl]
DiffEqBase.jl - The lightweight Base library for shared types and functionality for defining differential equation and scientific machine learning (SciML) problems
SciMLStyle - A style guide for stylish Julia developers
OrdinaryDiffEq.jl - High performance ordinary differential equation (ODE) and differential-algebraic equation (DAE) solvers, including neural ordinary differential equations (neural ODEs) and scientific machine learning (SciML)
RecursiveArrayTools.jl - Tools for easily handling objects like arrays of arrays and deeper nestings in scientific machine learning (SciML) and other applications
Lux.jl - Explicitly Parameterized Neural Networks in Julia
DiffEqOperators.jl - Linear operators for discretizations of differential equations and scientific machine learning (SciML)
DiffEqGPU.jl - GPU-acceleration routines for DifferentialEquations.jl and the broader SciML scientific machine learning ecosystem
DifferentialEquations.jl - Multi-language suite for high-performance solvers of differential equations and scientific machine learning (SciML) components. Ordinary differential equations (ODEs), stochastic differential equations (SDEs), delay differential equations (DDEs), differential-algebraic equations (DAEs), and more in Julia.
julia - The Julia Programming Language