PINA: a PyTorch and Lightning layer for PINNs, neural operators and equation learning
Physics-Informed Neural networks for Advanced modeling
At a glance
- What is it?
- PINA is an MIT-licensed Python library that puts problems, conditions, models and solvers behind composable abstractions, and the v0.3 line reworked its internals around mixins and condition-level evaluation. It suits teams who already run PyTorch and want a shared vocabulary for physics-informed work, not people looking for a black-box PDE solver.
- Who is it for?
- Adopt PINA if you already train in PyTorch and want one set of abstractions for PINNs, neural operators and time-dependent problems instead of maintaining a private copy of the same training loop per project. Do not adopt it if you need a solver you can point at a mesh file and walk away from, or if your stack is JAX or TensorFlow.
- Can I use it commercially?
- Yes. MIT 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 15 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 PINA fills between a PINN paper and a maintained codebase
A physics-informed neural network is a small idea with a large amount of plumbing around it. You need a model, a way to sample collocation points in the domain and on the boundary, a residual that evaluates the differential equation at those points, a loss that weights the residual against data and boundary terms, and a training loop that can checkpoint and distribute the work. Most groups write that plumbing once, then copy it into the next project with small edits. PINA's stated purpose is to replace those copies with a library: the README describes it as an open-source Python library designed to simplify and accelerate the development of Scientific Machine Learning solutions, including PINNs, Neural Operators, data-driven modeling, and more. The audience is therefore narrow and identifiable. It is researchers and engineers who already write PyTorch, who have at least one differential equation they care about, and who expect to write more than one such project. It is not aimed at someone who wants to hand over a geometry and receive a solution. The repository topics confirm the framing: physics-informed, neural-operators, pde, ode, equation-learning, all under a PyTorch and PyTorch Lightning umbrella.
Problems, conditions, models and solvers: the four moving parts
The architecture visible in the release notes is a pipeline of four object families. A problem declares the domain and the equations. Conditions carry the constraints: initial values, boundary values, data points, and the residuals that must vanish. A model is the neural network, which may be a plain multilayer perceptron or, per the v0.3 notes, a Kolmogorov-Arnold Network with a vectorized spline basis and analytical derivatives. A solver owns the training loop and the loss aggregation. The v0.3 announcement says the internals were redesigned around a mixin architecture, with lightweight single-responsibility mixins for preprocessing, forward evaluation and postprocessing that can be composed freely, and with residual computation separated from loss aggregation. The same announcement moves condition evaluation out of the solver and into the condition itself through a dedicated evaluate method. That is the design decision worth noticing. It means a solver no longer needs to know how a particular boundary condition is computed, so a new condition type does not require touching the training loop. The cost is indirection: when a loss term looks wrong, the code that produced it lives in the condition, not in the solver you were reading. The v0.3 notes also mention an autoregressive solver for sequential prediction, multi-model solver support, and dedicated time series and graph time series conditions, which is where the PyTorch Geometric dependency earns its place.
Installing PINA and the extras that decide what you can run
The README gives two installation paths. For a stable release, pip install "pina-mathlab". The distribution name differs from the import name and from the repository name, which is the first thing that trips people up. From source, the README lists git clone https://github.com/pina-org/PINA, cd PINA, git checkout master, then pip install . The extras are declared as pina-mathlab[extras], with dev, test, doc and tutorial listed as the available groups, so a working tutorial environment is pip install "pina-mathlab[tutorial]". Because the library is built on PyTorch, Lightning and PyTorch Geometric, the practical installation question is whether those three resolve cleanly against whatever your environment already pins. The README does not state version floors in the text; the Python version badge points at a pyproject.toml on the 0.3 branch, which is where the constraints actually live. Read that file before installing into an existing environment rather than after a resolver conflict. The MIT licence is permissive and imposes no copyleft obligation on your own code, but the README header carries an Apache-2.0 SPDX notice attributed to contributors to the Pyro project, so if you are vendoring files rather than depending on the package, check the header of the specific file you copy. That is a packaging detail to verify, not legal advice.
Where the framework model becomes the wrong tool
Abstraction has a cost, and PINA's is highest exactly where PINN research tends to be hardest. If your contribution is a new loss weighting scheme, a new sampling strategy or a modified residual, you will spend your first days learning where the mixin boundaries fall and which of the four object families is allowed to know about your change. The v0.3 release notes describe a substantial internal reorganisation: core internals migrated to the _src pattern, interfaces and base classes introduced across conditions, problems, losses and the data module, AbstractProblem renamed to BaseProblem, and the equation zoo reorganised with Burgers added. Anyone with code written against the pre-0.3 abstractions should expect to rewrite it, and the appearance of post releases such as v0.3.2.post2608 and v0.3.2.post2609 within a month suggests the surface is still settling. The second limitation is scope. PINA is a training framework, not a numerical solver. It does not replace a finite element or finite volume code, and for problems where a classical discretisation is fast and well understood, a neural surrogate is the more expensive answer. The README claims performance close to hand-crafted implementations with minimal overhead, but no measurement is given in the material available here, so treat that as a design goal rather than a number you can budget against. Third, the framework is PyTorch-only. If your group standardised on JAX, adopting PINA means running two stacks.
The alternative PINA is actually competing with
The real alternative is not another library. It is the single-file PINN script that most groups already have: one Python file with a torch.nn.Module, a hand-written residual function, an Adam loop and a matplotlib call at the end. That script is faster to write for one equation than any framework, and it has no version to pin. The difference in approach is what happens at the second and third equation. The script gets copied, the copies diverge, and the sampling logic in one no longer matches the boundary handling in another. PINA's bet is that paying the abstraction cost up front buys a shared vocabulary across problems, plus the pieces a script rarely grows: multi-device training, checkpointing through Lightning, graph-structured conditions for mesh-like data, and an autoregressive solver for sequential prediction. The bet fails if your work is genuinely one equation, or if your research contribution is the training loop itself, in which case a framework is an obstacle between you and the code you are trying to change.
Maintenance cost and the agentic addition in v0.3.2
Two maintenance signals are visible. The first is cadence. Releases listed here run v0.3.2 on 2026-07-17, then v0.3.2.post2608 on 2026-08-01, then v0.3.2.post2609 on 2026-09-01, which reads as a monthly post-release rhythm on a stable minor line rather than a frozen API. Pin an exact version in your requirements and upgrade deliberately. The second is the v0.3.2 headline feature: AI agents that guide users through the PINA pipeline, with dedicated skills for problem setup, model and solver selection, and training configuration. That is a notable direction for a numerical library, and it is the item most likely to change shape between releases, because it depends on model behaviour outside the repository's control. If your adoption decision is driven by reproducibility, treat the agent layer as optional and verify that the underlying pipeline still runs without it. The repository also carries the hacktoberfest topic, which usually means periodic external contributions and a corresponding review load; that is a signal about process, not about correctness, and it does not tell you anything about whether the code is right for your equation.
Editorial conclusion
Adopt PINA if you already train in PyTorch and want one set of abstractions for PINNs, neural operators and time-dependent problems instead of maintaining a private copy of the same training loop per project. Do not adopt it if you need a solver you can point at a mesh file and walk away from, or if your stack is JAX or TensorFlow. Before committing, pin the exact release, check that your installed PyTorch and Lightning versions satisfy the constraints in pyproject.toml, and run one of the tutorials end to end on your own hardware. The release cadence is the thing to watch: v0.3.2.post2609 landed on 2026-09-01, one month after v0.3.2.post2608, so treat post releases as moving targets and pin them.
Community notes