# PINA's README still carries Pyro's Apache-2.0 header while the package is MIT

> A scientific machine learning library for physics-informed problems, built on PyTorch, PyTorch Geometric and Lightning, with a four step API and a foundation style governance tree. The rough edges are all in the metadata: two documentation domains, an extra name that does not exist, and version tags that count days.

**PINA-org/PINA** — Physics-Informed Neural networks for Advanced modeling

- Repository: https://github.com/PINA-org/PINA
- Website: https://pina-org.github.io/PINA/
- Stars: 798 · Forks: 112
- Language: Python
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/pina-org-pina

## The license header at the top of the README belongs to another project

The first thing in the README file is a comment, before any visible content:

```
Copyright Contributors to the Pyro project.

SPDX-License-Identifier: Apache-2.0
```

Pyro is a different project, and Apache-2.0 is a different licence from the one everything else says. The repository metadata says MIT, the project manifest declares it as MIT, and the licence text at the root is LICENSE.rst. So the file a reader opens first, the package index, and the licence file give three answers, one of which belongs to a project with no connection to this one.

This is not a cosmetic detail in a repository that also carries CITATION.cff, a joss/ directory for a journal paper, CHARTER.md, GOVERNANCE.md, STEERING-COMMITTEE.md, MAINTAINERS.md, ANTITRUST.md and TRADEMARKS.md. The governance apparatus is the shape of a foundation, and a foundation that wants downstream users to comply with MIT needs its own README to stop claiming Apache-2.0 on their behalf.

## Two documentation domains and a repository URL in another organisation

The URLs do not agree either. The repository metadata points its homepage at pina-org.github.io/PINA/. The project manifest points at mathlab.github.io/PINA/ for the homepage and at github.com/mathLab/PINA for the repository, a different organisation name from the one hosting this code. Every documentation link inside the README points at mathlab.github.io as well, down to per-section anchors, while the tutorial link points at the pina-org tree.

So there are two hosting identities in one package, and the manifest, which is what tooling reads, names the older looking one. The PyPI name is a third: pina-mathlab, with a mathlab of its own, while the import name is pina.

Small inconsistencies of that kind are common in projects that have been renamed. Two of them are in the manifest text itself. The project description reads Physic Informed Neural networks for Advance modeling, and the GitHub description spells out the same acronym as Physics-Informed Neural networks for Advanced modeling. Neither matches the README, whose tagline is A Unified Framework for Scientific Machine Learning. The keyword list also contains lightining, one n short of lightning, next to a copy of the real dependency name.

## The documented install command names an extra that is not defined

The stable install is one line:

```
pip install "pina-mathlab"
```

The extras route is printed as:

```
pip install "pina-mathlab[extras]"
```

There is no extra called extras. The manifest defines four, and the README names them right underneath: dev, test, doc and tutorial. So the documented command resolves to the base package and tells you nothing, while the names that work are in the same paragraph.

What each one pulls is also uneven. The dev extra is a single formatter, black. The doc extra is five Sphinx packages with a version ceiling, sphinx above 5.0 and below 8.2, plus two themes and a copy button. The test extra adds pytest, pytest-cov and scipy. The tutorial extra adds jupyter, torchvision, tensorboard, scipy and numpy, and it also lists a package called smithers, which is not a tutorial dependency under any name documented in the repository.

From source the sequence is a clone, a directory change, a checkout of the master branch and an install, which matches the default branch name.

## The version tags count days, and the manifest version never moves

The three newest release tags are v0.3.2.post2610 dated 2026-10-01, v0.3.2.post2609 dated 2026-09-01 and v0.3.2.post2608 dated 2026-08-01. One per month, all of them post releases of 0.3.2.

That shape comes from the build system. The manifest requires setuptools, wheel and setuptools-git-versioning, which derives a version from the git history rather than from a field, and the static version in the manifest is 0.3.2. So the recorded version and the installed version are different things: the manifest is the last tagged release, and the tag is that release plus a count of commits since, where the suffix appears to encode the year and the month.

The practical effect is that a pinned install is hard to reason about. A dependency spec written as 0.3.2 gives you the state of a specific month, and a spec written from the tag gives you a post release that a later checkout will have moved past. Nobody has documented which one to use, and the news section in the README, which is organised by minor version, has no entry for any of these monthly builds.

## v0.3 moved evaluation out of the solver and into the condition

The most consequential internal change in the 0.3 line is the conditions refactoring. Evaluation logic moved out of the solver and into the condition itself, through a dedicated evaluate method, with the stated goal of decoupling the training loop from problem specific logic and making conditions fully modular and solver agnostic.

That is a real architectural decision rather than a rename: a condition that knows how it is evaluated can be attached to any solver, and a solver no longer carries per problem branches.

Around it sit two more structural changes. The solver internals were redesigned around a mixin architecture, where lightweight single responsibility mixins for preprocessing, forward and postprocessing compose freely, with residual computation and loss aggregation kept separate. And the code base moved to a _src internal layout, with base classes introduced across conditions, losses and the data module, and the problem hierarchy changing from AbstractProblem to BaseProblem, which is a rename any code subclassing the old name will notice.

The new capability alongside that is an autoregressive solver for sequential prediction with multi model support, plus dedicated time series and graph time series conditions, KAN support with a vectorised spline basis and analytical derivatives, and a reorganised equation zoo with Burgers added.

## Agentic PINA ships agent files for three tools at once

The v0.3.2 entry is the only feature announcement in the news block that is not internal plumbing. Agentic PINA adds AI agents that guide users through the pipeline, with dedicated skills for problem setup, for model and solver selection, and for training configuration.

The repository is laid out for it. There is a .claude/ directory, a .opencode/ directory, an .agents/ directory, and both CLAUDE.md and AGENTS.md at the root. That is three different agent runtimes configured in one tree, and the skills are described by function rather than by runtime, so the same guidance is reachable from more than one.

It is a notable direction for a scientific library: the setup decisions in the four step pipeline, what problem to define, which solver to use, how to configure training, are exactly the decisions that are hard to make from documentation alone. What the repository does not say is how the agents were evaluated, which is the question to ask of any prompt shipped inside a package that downstream users will run.

## The worked example stops at the comment that introduces step one

The getting started path is a four step pipeline: define the problem and its constraints with the Problem API, design the model in PyTorch or PyTorch Geometric through the Model API, select or build a solver through the Solver API, and train with the Trainer API powered by PyTorch Lightning. A mermaid flowchart names the same four steps as problem and data, model design, solver selection and training.

The first worked example is a data driven modelling snippet, and it ends mid comment:

```python
import torch
from pina import Trainer
from pina.model import FeedForward
from pina.problem.zoo import SupervisedProblem
from pina.solver import SupervisedSingleModelSolver

input_tensor  = torch.rand((10, 1))
target_tensor = input_tensor.pow(3)

# Step 1. D
```

The last line in the file begins a comment and stops there, so the import list, the ten sample inputs and the cubic target are the most a reader gets from that example. The tutorial repository is the place the rest lives.

The runtime floor is Python 3.10 or newer, with torch, lightning, torch_geometric and matplotlib as the four required dependencies. Formatting is fixed in three places at once, a black line length of 80 in the manifest, an isort profile set to black, a .pylintrc at the root and a code_formatter.sh script beside them.

## Conclusion

PINA is a reasonable choice for a physics informed or neural operator project that already lives in PyTorch and Lightning, because the four step API and the condition owns its own evaluation refactor are aimed squarely at the awkward part of that work. Read the metadata before you cite it, though, because the licence, the URLs and the version scheme each have two answers. The README header carries an Apache-2.0 line for another project, the manifest sends you to a different documentation domain and a different GitHub organisation than the one hosting the code, and the install example names an extra that does not exist while the four that do work are listed below it. For reproducible installs, pin a tag and record which of the monthly post releases you took, since the manifest version alone will not tell a future reader what your environment contained.

## FAQ

### What package name do I install PINA from?

PyPI, as pina-mathlab: pip install "pina-mathlab". From source it is git clone https://github.com/pina-org/PINA, then cd PINA, git checkout master and pip install ., which matches the default branch name. The import name inside your code is pina.

### What optional extras does PINA define?

Four, and the names are dev, test, doc and tutorial. The README's own example for the extras route prints pina-mathlab[extras], which is not one of them, so that command resolves to the base package. dev pulls black, doc pulls five Sphinx packages, test pulls pytest, pytest-cov and scipy, and tutorial pulls jupyter, torchvision, tensorboard, scipy and numpy.

### What licence is PINA under?

MIT, according to the repository metadata, the project manifest and the LICENSE.rst file at the root. The first thing in the README file is a comment carrying an Apache-2.0 SPDX identifier and a copyright line for the Pyro project, which belongs to a different project and contradicts the rest of the repository.

### Which PINA version should I pin?

The manifest declares 0.3.2 and the build system uses setuptools-git-versioning, so the release tags are dated post releases of it: v0.3.2.post2610, v0.3.2.post2609 and v0.3.2.post2608, one per month. Pin a tag and record it, because the static version field does not distinguish those monthly builds.

### How do you solve a problem in PINA?

In four steps. Define the problem and its constraints with the Problem API, design the model in PyTorch or PyTorch Geometric through the Model API, select or build a solver through the Solver API, then train with the Trainer API, which is powered by PyTorch Lightning. Python 3.10 or newer is required.

## Sources

- [License: MIT](https://github.com/PINA-org/PINA/blob/master/LICENSE)
- [PINA-org/PINA on GitHub](https://github.com/PINA-org/PINA)
- [Project website](https://pina-org.github.io/PINA/)
- [README](https://github.com/PINA-org/PINA/blob/master/README.md)
- [Releases](https://github.com/PINA-org/PINA/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/pina-org-pina