DeepXDE: A Backend-Agnostic Library for PINNs and DeepONets
A library for scientific machine learning and physics-informed learning
At a glance
- What is it?
- DeepXDE wraps physics-informed neural networks, DeepONet operator learning and multifidelity networks behind one compact API, with TensorFlow, PyTorch, JAX and PaddlePaddle as interchangeable backends. The judgement: it removes the boilerplate of assembling PDE residuals by hand, but it does not remove the cost of training them.
- Who is it for?
- Adopt DeepXDE if you are prototyping a forward or inverse PDE problem and want the residual, boundary conditions and sampling handled by a library rather than by your own training loop. Do not adopt it if you need a solver for a well-posed problem that a classical finite element or finite volume code already handles, or if you cannot afford repeated hyperparameter search.
- Can I use it commercially?
- Yes, with conditions. LGPL-2.1 is a weak copyleft licence: you can use it inside commercial and closed-source software, but if you distribute changes to its own files, you must publish those changes under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 29 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem DeepXDE removes: assembling PDE residuals by hand
Anyone who has written a physics-informed neural network from scratch knows the shape of the work. You define a network, sample collocation points in the domain, sample boundary points, write a residual function that differentiates the network output with respect to its inputs, weight the boundary and interior losses against each other, and then write a training loop. Almost none of that code is about your equation. DeepXDE targets exactly that layer. The README states the goal in one line: user code should be compact and resemble the mathematical formulation. The algorithms listed are physics-informed neural networks for forward and inverse ODEs and PDEs, integro-differential equations, fractional PDEs, stochastic PDEs and inverse design, plus deep operator networks (DeepONet, MIONet, POD-DeepONet, Fourier-DeepONet, physics-informed DeepONet, multifidelity DeepONet) and multifidelity neural networks. The intended user is a researcher or engineer who has a differential equation and a mesh-free formulation in mind, not someone looking for a general-purpose solver. DeepXDE is not a replacement for a finite element code on a problem where the finite element code already works. It is a framework for the class of problems where you want the solution as a neural network function of the coordinates, or where the operator itself is the object you are learning.
Geometry, boundary conditions and the residual: the actual mechanism
The architecture is built around four loosely coupled objects, and the README explicitly says the components are loosely coupled and highly configurable. First, a geometry. The primitive set is interval, triangle, rectangle, polygon, disk, ellipse, star-shaped, cuboid, sphere, hypercube and hypersphere, and other shapes are built as constructive solid geometry from three boolean operations: union, difference and intersection. A geometry can also be a point cloud. Second, boundary conditions. Five types are listed: Dirichlet, Neumann, Robin, periodic, and a general boundary condition that can be defined on an arbitrary domain or on a point set. There are also approximate distance functions for hard constraints, which is the hPINN path for inverse design and topology optimization. Third, sampling. Uniform, pseudorandom, Latin hypercube, Halton, Hammersley and Sobol sequences are available, and the README notes that training points can either stay fixed or be resampled adaptively every certain number of iterations. That last option is the residual-based adaptive sampling algorithm, one of the listed accuracy improvements alongside gradient-enhanced PINN and multi-scale Fourier features. Fourth, differentiation. Three automatic differentiation modes are implemented: reverse mode (backpropagation), forward mode, and zero coordinate shift. The data flow is therefore: geometry supplies points, the boundary condition objects supply the constraints on those points, the network maps coordinates to the field, and the automatic differentiation mode produces the derivatives that the residual function consumes. The loss combines the interior residual with the boundary terms. Optimizers listed are Adam and L-BFGS, and callbacks cover early stopping and monitoring of internal states during training.
Installing against one of five backends
DeepXDE does not pick a tensor library for you. The README states that it supports TensorFlow 1.x (through tensorflow.compat.v1 in TensorFlow 2.x), TensorFlow 2.x, PyTorch, JAX and PaddlePaddle, and the installation section gives a version floor per backend. TensorFlow 1.x requires TensorFlow >= 2.7.0. TensorFlow 2.x requires TensorFlow >= 2.3.0 and TensorFlow Probability >= 0.11.0. PyTorch requires PyTorch >= 2.0.0. For JAX the listed dependencies are JAX and Flax, and the README text is truncated at that point, so the minimum Flax version is not something I can state from this material. The documentation page Working with different backends is the reference for choosing one. The practical consequence is that installation is two steps: install the backend at a version inside the supported range, then install DeepXDE. That ordering matters because the backend is a hard dependency rather than an optional extra, and because the version floor is not the same across backends. If you are already invested in one framework, the choice is usually made for you. If you are not, the decision is about which differentiation mode and which dtype you need, since float16, float32 and float64 are all listed as supported, and about whether you want data-parallel training on multiple GPUs, which the README lists as a feature without tying it to a specific backend.
What the abstraction costs you
The trade-off is the familiar one for any framework that hides a training loop. You get a compact residual definition, and in exchange the failure modes are less visible. If the loss plateaus, the cause could be the sampling distribution, the relative weighting of the boundary terms, the choice of automatic differentiation mode, or the optimizer schedule. DeepXDE exposes knobs for all of these (weighted losses, learning rate schedules, adaptive resampling, callbacks), which means the debugging surface is wide even though the code is short. A second limitation is specific to the mesh-free formulation rather than to the library: PINN training is an optimization problem over a non-convex loss, and the listed accuracy improvements (adaptive sampling, gPINN, Fourier features) exist precisely because the plain formulation struggles on some problems. The README does not claim otherwise, but it also gives no guidance on which problems are tractable. A third point is the geometry API. The primitive list is broad but finite, and CSG covers the rest through three boolean operations. If your domain does not decompose cleanly into those operations, the point-cloud geometry is the remaining option, and a point cloud changes how boundary conditions are expressed because there is no analytic boundary to test against. That is a real constraint on complex industrial geometry, and it is not something the feature list resolves.
DeepXDE against writing the PINN yourself
The obvious alternative is a hand-written PINN in the framework you already use. The difference is not accuracy, since the underlying method is the same, but what you own. A hand-written implementation gives you direct control over the residual function, the sampling strategy and the loss weighting, at the cost of reimplementing geometry sampling, Sobol and Halton sequences, the boundary condition types, the three differentiation modes and the checkpointing. DeepXDE's own README points to the published methods it implements, including the SIAM Review paper on physics-informed neural networks and the Nature Machine Intelligence paper on DeepONet, so the algorithms are documented in the literature rather than invented here. The second alternative is a classical numerical solver. For a forward problem on a simple domain, a finite element or finite volume code will reach a solution faster and with error estimates that a neural network does not provide. DeepXDE becomes the better tool when the problem is inverse (you are fitting unknown coefficients in the equation), when you need the solution as a differentiable function of coordinates, when the domain is high-dimensional, or when you are learning an operator that maps one function to another and want DeepONet variants such as POD-DeepONet or Fourier-DeepONet. Those are cases where a mesh-based solver is awkward, not cases where DeepXDE is simply faster.
Maintenance, releases and the LGPL-2.1 licence
The repository is not archived and the last push recorded is 2026-08-18. Releases are regular rather than rapid: v1.13.2 in March 2025, v1.14.0 in May 2025, v1.15.0 in December 2025. That cadence suggests a maintained project with a long gap between minor versions, which matters if you depend on a specific backend version, because the backend version floors in the installation section move with those releases. The upgrade cost is therefore mostly the cost of keeping your backend inside the supported range rather than the cost of chasing API churn. On licensing, DeepXDE is distributed under LGPL-2.1. The practical implication of a weak copyleft licence is that modifications to the library itself carry obligations, while code that merely imports it is treated differently. That is a general description of how LGPL-2.1 is usually understood, not legal advice, and if you plan to ship DeepXDE inside a proprietary product you should have your own counsel read the LICENSE file in the repository rather than rely on a summary. The five-backend support also has a maintenance consequence for users: a bug that only appears under one backend may take longer to surface, and the README's pointer to the backends documentation page is the only guidance offered on choosing between them.
Editorial conclusion
Adopt DeepXDE if you are prototyping a forward or inverse PDE problem and want the residual, boundary conditions and sampling handled by a library rather than by your own training loop. Do not adopt it if you need a solver for a well-posed problem that a classical finite element or finite volume code already handles, or if you cannot afford repeated hyperparameter search. Before committing, verify two things on your own machine: that the backend you intend to use is the one whose version range the installation page lists for it, and that the geometry class you need exists among the primitives or can be built from union, difference and intersection operations, because a point-cloud geometry is the fallback and it changes how boundary conditions are specified.
Community notes