PaddleScience: a PaddlePaddle SDK for physics-informed and data-driven scientific computing
PaddleScience is SDK and library for developing AI-driven scientific computing applications based on PaddlePaddle.
At a glance
- What is it?
- PaddleScience wraps PaddlePaddle's automatic differentiation into a configuration-driven toolkit for PINNs, operator learning and supervised surrogate models, with roughly twenty worked examples. It is most useful if you already run PaddlePaddle; if you are on PyTorch, the switching cost is the whole story.
- Who is it for?
- Adopt PaddleScience if your stack is already PaddlePaddle and your problem maps onto one of the documented cases: forward PDE solving, operator learning, or a supervised surrogate over simulation data. Do not adopt it as a general numerical PDE library, and do not pick it purely to escape a PyTorch codebase, because the configuration layer assumes Paddle tensors and Paddle optimisers throughout.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 56 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 gap PaddleScience fills between a deep learning framework and a PDE solver
PaddlePaddle gives you tensors, automatic differentiation and optimisers. It does not give you a way to say "this network must satisfy the Navier-Stokes residual on these collocation points, with a no-slip condition on this boundary." PaddleScience is the layer that adds that vocabulary. The README describes it as an SDK and library for AI-driven scientific computing built on PaddlePaddle, using the framework's automatic differentiation (including higher-order derivatives) to attack problems in physics, chemistry and meteorology. The intended user is a researcher or engineer who has a differential equation and a mesh or point cloud, and who would rather configure a solver than hand-roll a training loop. Three solving modes are named: physics-driven, data-driven, and a hybrid of the two. That third mode is the one worth noting, because most competing toolkits lead with physics-informed training and treat data assimilation as an add-on. PaddleScience presents the three as peers, which matches how applied work usually looks: a partial physical model plus measurements where the model is weak.
Constraints, equations and the sympy path: how a case is actually assembled
The mechanism visible in the material is constraint-based. The feature list names Dirichlet, Neumann and Robin boundary conditions plus user-defined conditions, and geometry handling for both simple shapes and complex STL files, including boolean operations on those geometries. So a case is assembled from a geometry, a set of sampled points on it, and constraints attached to those regions. The equation side is handled through sympy: the README lists support for "equation representation and simultaneous equation system computation based on the sympy symbolic computation library." That is a design decision with consequences. Writing residuals symbolically means the framework can differentiate them through Paddle's autodiff rather than asking you to hand-code derivatives, which is why higher-order derivatives are feasible. It also means your PDE has to be expressible in sympy, and that symbolic differentiation cost is paid at setup. The case tables show how wide the constraint vocabulary has to stretch: Helmholtz, Allen-Cahn, Laplace, Burgers, Lorenz, Rossler, Volterra integral equations, fractional Poisson, optical soliton and rogue wave problems, XPINN domain decomposition, and three-dimensional Brusselator systems. Integral and fractional equations in the same list as straightforward Poisson problems is unusual, and it suggests the constraint interface is general enough to carry non-local terms rather than being hard-wired to integer-order PDE residuals.
Hydra configuration, experiment tracking and parallel runs
Configuration is Hydra-based, which the badge row confirms. In practice this means each case ships a YAML tree and you override values from the command line rather than editing Python. The feature list also advertises experiment source-code tracking and one-click parallel experiment launch, plus structured log saving and visualisation output. For a research workflow this is the part that decides whether the library saves you time. A PINN run is a hyperparameter search over network width, learning rate, collocation sampling and loss weighting, and the loss weighting in particular is where physics-informed training usually fails. Having the configuration externalised and the runs launchable in parallel is the difference between a weekend of manual edits and a sweep. The README does not specify which scheduler or launcher the parallel path targets, so if you depend on a particular cluster job system, verify that against the user guide before planning around it. The same caution applies to the tracking feature: the README names the capability, not the backend.
Getting it running: the install pair and the first case
The README points to a dedicated install and setup page rather than embedding commands, so the exact invocation should be read there. What the material does establish is the distribution name: the PyPI badge links to the paddlesci package, and there is a conda channel at anaconda.org/PaddleScience/paddlescience. The Python version badge indicates the supported interpreters are declared on PyPI. The latest release is v1.4.0, dated 2025-04-08, following v1.3.0 in July 2024 and v1.2.0 in November 2023. That cadence, roughly one release per year, matters for planning: this is not a project that ships breaking changes monthly, and it is not one that patches weekly either. The practical sequence is to install PaddlePaddle first, matching your CUDA build, then install paddlesci at the version you intend to pin, then clone the repository and run one example from the case list. The examples are the real documentation here. Each row in the case tables links to a documentation page and, where applicable, a dataset and a paper, and several rows link directly to a file under examples/ in the repository, such as examples/gpinn/poisson_1d.py and examples/fpde/fractional_poisson_2d.py. Reading one of those files alongside its YAML config is the fastest way to understand the constraint API, and it is more reliable than reading prose, because the prose documentation is published in Chinese.
Where PaddleScience is the wrong tool
Two limits stand out. The first is the ecosystem lock. PaddleScience is built on PaddlePaddle, and the README is explicit that the automatic differentiation doing the work is Paddle's. If your group's code, pretrained weights and deployment targets are PyTorch, adopting this means running two frameworks, and the hybrid mode, which is where the library is most interesting, is exactly the mode that would force you to move data between them. The second is the documentation language. Every documentation link in the README resolves to the zh-cn locale. The README itself is in Chinese, and the case tables are in Chinese. There is a DeepWiki badge offered as an auxiliary programming aid, but that is a third-party interface over the repository, not translated documentation. For a team without Chinese readers, the effective documentation is the example source files, which are Python and therefore readable, plus the linked papers. That is workable for someone porting a known method, and painful for someone learning the domain. A third, softer limit: the case list is a catalogue of methods, not a mesh-based solver. If your problem is well served by a conventional finite volume or finite element code, a neural surrogate is an extra approximation layer, and you should be clear about why you want it.
How it differs from DeepXDE and NeuralOperator
The closest comparison is DeepXDE, which also targets physics-informed neural networks with a constraint-style API and also supports symbolic equation entry. The difference is the substrate: DeepXDE runs on TensorFlow, PyTorch or JAX depending on backend, while PaddleScience runs only on PaddlePaddle. That single fact decides most adoption questions. If you need backend portability, PaddleScience is not the choice. If you are already on PaddlePaddle, the field narrows to almost nothing else. On the operator-learning side, NeuralOperator and similar libraries concentrate on learning mappings between function spaces from data, which corresponds to PaddleScience's data-driven mode. PaddleScience's distinguishing claim is that the same SDK covers physics-driven, data-driven and hybrid formulations, with the case list spanning DeepONet and latent neural operators alongside classical PINN problems. Whether that breadth holds up in practice depends on the constraint interface being general enough for your equation, which is the thing to test early. The references in the case tables show the intended reading: PaddleScience implementations are tied to specific papers, and the library is positioned as a way to reproduce and extend published methods rather than to serve as a black-box solver.
Licence, release cadence and the cost of staying current
The licence is Apache-2.0, which permits commercial use and modification provided the licence and notices are preserved and modified files are marked. It also includes a patent grant. This is a permissive licence and among the easiest to adopt in a corporate setting; it is not a copyleft licence, so it does not oblige you to publish your own code. That is a general description of the licence text, not legal advice, and if the project is going into a product you should have counsel read the LICENSE file at the pinned commit. The maintenance cost is dominated by the PaddlePaddle dependency, not by PaddleScience itself. PaddleScience releases about once a year, so the library is unlikely to break under you, but PaddlePaddle moves faster and its CUDA requirements move with it. Pin both versions together in the same environment file, and treat an upgrade as a joint operation. The upgrade cost is concentrated in the Hydra configs: a version bump can change config keys, and if you have forked example YAMLs, you will be diffing them against the new release. Keeping your configs as overrides on top of the shipped ones, rather than copies, reduces that cost. The last push to the develop branch was 2026-07-22, so the project is active between releases even though tagged versions are infrequent.
Editorial conclusion
Adopt PaddleScience if your stack is already PaddlePaddle and your problem maps onto one of the documented cases: forward PDE solving, operator learning, or a supervised surrogate over simulation data. Do not adopt it as a general numerical PDE library, and do not pick it purely to escape a PyTorch codebase, because the configuration layer assumes Paddle tensors and Paddle optimisers throughout. Before committing, install the pinned pair with python -m pip install paddlesci==1.4.0 paddlepaddle-gpu, run one example from the case list end to end on your own hardware, and check that the equation you need can be written in the sympy-based form the solver expects. If your PDE needs a boundary condition type the library does not expose, you will be writing a custom constraint rather than configuring one.
Community notes