The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning. Learn more →
Top 23 Sciml Open-Source Projects
-
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.
-
SciMLBook
Parallel Computing and Scientific Machine Learning (SciML): Methods and Applications (MIT 18.337J/6.338J)
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
ModelingToolkit.jl
An acausal modeling framework for automatically parallelized scientific machine learning (SciML) in Julia. A computer algebra system for integrated symbolics for physics-informed machine learning and automated transformations of differential equations
-
NeuralPDE.jl
Physics-Informed Neural Networks (PINN) Solvers of (Partial) Differential Equations for Scientific Machine Learning (SciML) accelerated simulation
-
SciMLTutorials.jl
Tutorials for doing scientific machine learning (SciML) and high-performance differential equation solving with open source software.
-
Optimization.jl
Mathematical Optimization in Julia. Local, global, gradient-based and derivative-free. Linear, Quadratic, Convex, Mixed-Integer, and Nonlinear Optimization in one simple, fast, and differentiable interface.
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
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)
-
diffeqpy
Solving differential equations in Python using DifferentialEquations.jl and the SciML Scientific Machine Learning organization
-
Catalyst.jl
Chemical reaction network and systems biology interface for scientific machine learning (SciML). High performance, GPU-parallelized, and O(1) solvers in open source software.
-
DataDrivenDiffEq.jl
Data driven modeling and automated discovery of dynamical systems for the SciML Scientific Machine Learning organization
-
SciMLSensitivity.jl
A component of the DiffEq ecosystem for enabling sensitivity analysis for scientific machine learning (SciML). Optimize-then-discretize, discretize-then-optimize, adjoint methods, and more for ODEs, SDEs, DDEs, DAEs, etc.
-
DiffEqBase.jl
The lightweight Base library for shared types and functionality for defining differential equation and scientific machine learning (SciML) problems
-
SciMLBenchmarks.jl
Scientific machine learning (SciML) benchmarks, AI for science, and (differential) equation solvers. Covers Julia, Python (PyTorch, Jax), MATLAB, R
-
DiffEqGPU.jl
GPU-acceleration routines for DifferentialEquations.jl and the broader SciML scientific machine learning ecosystem
-
StochasticDiffEq.jl
Solvers for stochastic differential equations which connect with the scientific machine learning (SciML) ecosystem
-
NonlinearSolve.jl
High-performance and differentiation-enabled nonlinear solvers (Newton methods), bracketed rootfinding (bisection, Falsi), with sparsity and Newton-Krylov support.
-
RecursiveArrayTools.jl
Tools for easily handling objects like arrays of arrays and deeper nestings in scientific machine learning (SciML) and other applications
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
The documentation has a manifest associated with it: https://docs.sciml.ai/NeuralPDE/dev/#Reproducibility. Instantiating the manifest will give you all of the exact versions used for the documentation build (https://github.com/SciML/NeuralPDE.jl/blob/gh-pages/v5.7.0/assets/Manifest.toml). You just ]instantiate folder_of_manifest. Or you can use the Project.toml.
Project mention: SciPy: Interested in adopting PRIMA, but little appetite for more Fortran code | news.ycombinator.com | 2023-05-18Interesting response. I develop the Julia SciML organization https://sciml.ai/ and we'd be more than happy to work with you to get wrappers for PRIMA into Optimization.jl's general interface (https://docs.sciml.ai/Optimization/stable/). Please get in touch and we can figure out how to set this all up. I personally would be curious to try this out and do some benchmarks against nlopt methods.
Project mention: [P] LagrangeBench: A Lagrangian Fluid Mechanics Benchmarking Suite | /r/MachineLearning | 2023-12-11LagrangeBench is a machine learning benchmarking library for CFD particle problems based on JAX. It is designed to evaluate and develop learned particle models (e.g. graph neural networks) on challenging physical problems. To our knowledge it's the first benchmark for this specific set of problems. Our work was inspired by the grid-based benchmarks of PDEBench and PDEArena, and we propose it as a Lagrangian alternative.
Project mention: Symbolicregression.jl – High-Performance Symbolic Regression in Julia and Python | news.ycombinator.com | 2023-07-15
There has been a lot of research in Runge Kutta methods in the last couple decades which resulted in all kind of specialized Runge Kutta methods. You have high order ones, RK methods for stiff problems, embedded RK methods which benefit from adaprive step size control, RK-Nystrom methods for second order Problems, symplectic RK methods which preserve energy (eg. hamiltonian) ando so on. If you are interested in the numerics and the use cases I highly recommend checking out the Julia Libary OrdinaryDiffEq (https://github.com/SciML/OrdinaryDiffEq.jl). If you look into the documentation you find A LOT of implemented RK methods for all kind of use cases.
What about the other benchmarks on the same site? https://docs.sciml.ai/SciMLBenchmarksOutput/stable/Bio/BCR/ BCR takes about a hundred seconds and is pretty indicative of systems biological models, coming from 1122 ODEs with 24388 terms that describe a stiff chemical reaction network modeling the BCR signaling network from Barua et al. Or the discrete diffusion models https://docs.sciml.ai/SciMLBenchmarksOutput/stable/Jumps/Dif... which are the justification behind the claims in https://www.biorxiv.org/content/10.1101/2022.07.30.502135v1 that the O(1) scaling methods scale better than O(log n) scaling for large enough models? I mean.
> If you use special routines (BLAS/LAPACK, ...), use them everywhere as the respective community does.
It tests with and with BLAS/LAPACK (which isn't always helpful, which of course you'd see from the benchmarks if you read them). One of the key differences of course though is that there are some pure Julia tools like https://github.com/JuliaLinearAlgebra/RecursiveFactorization... which outperform the respective OpenBLAS/MKL equivalent in many scenarios, and that's one noted factor for the performance boost (and is not trivial to wrap into the interface of the other solvers, so it's not done). There are other benchmarks showing that it's not apples to apples and is instead conservative in many cases, for example https://github.com/SciML/SciPyDiffEq.jl#measuring-overhead showing the SciPyDiffEq handling with the Julia JIT optimizations gives a lower overhead than direct SciPy+Numba, so we use the lower overhead numbers in https://docs.sciml.ai/SciMLBenchmarksOutput/stable/MultiLang....
> you must compile/write whole programs in each of the respective languages to enable full compiler/interpreter optimizations
You do realize that a .so has lower overhead to call from a JIT compiled language than from a static compiled language like C because you can optimize away some of the bindings at the runtime right? https://github.com/dyu/ffi-overhead is a measurement of that, and you see LuaJIT and Julia as faster than C and Fortran here. This shouldn't be surprising because it's pretty clear how that works?
I mean yes, someone can always ask for more benchmarks, but now we have a site that's auto updating tons and tons of ODE benchmarks with ODE systems ranging from size 2 to the thousands, with as many things as we can wrap in as many scenarios as we can wrap. And we don't even "win" all of our benchmarks because unlike for you, these benchmarks aren't for winning but for tracking development (somehow for Hacker News folks they ignore the utility part and go straight to language wars...).
If you have a concrete change you think can improve the benchmarks, then please share it at https://github.com/SciML/SciMLBenchmarks.jl. We'll be happy to make and maintain another.
Indeed, and this year we created a system for compiling ODE code not just optimized CUDA kernels but also OneAPI kernels, AMD GPU kernels, and Metal. Peer reviewed version is here (https://www.sciencedirect.com/science/article/abs/pii/S00457...), open access is here (https://arxiv.org/abs/2304.06835), and the open source code is at https://github.com/SciML/DiffEqGPU.jl. The key that the paper describes is that in this case kernel generation is about 20x-100x faster than PyTorch and Jax (see the Jax compilation in multiple ways in this notebook https://colab.research.google.com/drive/1d7G-O5JX31lHbg7jTzz..., extra overhead though from calling Julia from Python but still shows a 10x).
The point really is that while deep learning libraries are amazing, at the end of the day they are DSL and really pull towards one specific way of computing and parallelization. It turns out that way of parallelizing is good for deep learning, but not for all things you may want to accelerate. Sometimes (i.e. cases that aren't dominated by large linear algebra) building problem-specific kernels is a major win, and it's over-extrapolating to see ML frameworks do well with GPUs and think that's the only thing that's required. There are many ways to parallelize a code, ML libraries hardcode a very specific way, and it's good for what they are used for but not every problem that can arise.
Project mention: Julia as a unifying end-to-end workflow language on the Frontier exascale system | news.ycombinator.com | 2023-11-19
Sciml related posts
- Std: Clamp generates less efficient assembly than std:min(max,std:max(min,v))
- Good linear algebra libraries
- Julia 1.9: A New Era of Performance and Flexibility
- Julia's latency: Past, present and future
- Please help me make a case to implement Julia in enterprise
- How much useful are Runge-Kutta methods of order 9 and higher within double-precision arithmetic/floating point accuracy?
- Interpolant Coefficients for the BS5 Runge-Kutta method
-
A note from our sponsor - WorkOS
workos.com | 29 Apr 2024
Index
What are some of the best open-source Sciml projects? This list will help you:
Project | Stars | |
---|---|---|
1 | DifferentialEquations.jl | 2,756 |
2 | SciMLBook | 1,790 |
3 | ModelingToolkit.jl | 1,335 |
4 | NeuralPDE.jl | 903 |
5 | SciMLTutorials.jl | 708 |
6 | Optimization.jl | 658 |
7 | PDEBench | 618 |
8 | SymbolicRegression.jl | 526 |
9 | OrdinaryDiffEq.jl | 498 |
10 | diffeqpy | 496 |
11 | Catalyst.jl | 421 |
12 | DataDrivenDiffEq.jl | 398 |
13 | Surrogates.jl | 314 |
14 | SciMLSensitivity.jl | 311 |
15 | 18S096SciML | 303 |
16 | DiffEqBase.jl | 297 |
17 | SciMLBenchmarks.jl | 290 |
18 | DiffEqGPU.jl | 267 |
19 | StochasticDiffEq.jl | 234 |
20 | NonlinearSolve.jl | 204 |
21 | ReservoirComputing.jl | 198 |
22 | RecursiveArrayTools.jl | 202 |
23 | SciMLStyle | 192 |
Sponsored