Verified on Python 3.12, installable only below 3.11

The metadata excludes Python 3.12 while the README calls it verified

The compatibility section is written carefully and it says the project officially targets Python 3.9, JAX 0.4.11, PyTorch 1.13.0 and CUDA 11.7, then adds that most components were verified against Python 3.12, JAX 0.9.2, PyTorch 2.11.0 and CUDA 13.0. The packaging disagrees at the first item. pyproject.toml declares `requires-python = ">=3.9,<3.11"`, so a package manager refuses to install this on 3.12 no matter what the README verified. The runtime dependencies compound it, pinning `torch~=1.13.0`, `torchvision~=0.14.1` and `numpy<2`. The scope of the verification is also narrower than the heading suggests: the note names the core codebase, forward training in `pdebench/model`, and data generation in `data_gen_NLE`, and then says compatibility for the remaining components is still under investigation. Both notes carry the same date, 2026-03-30, which is also the last push to the branch.

The datagen extras install from wheel URLs and one pinned git commit

There are two extras for data generation, `datagen310` and `datagen39`, differing mainly in which Python interpreter the wheels target. Neither resolves through an index. Each lists `torch` and `torchvision` as direct URLs on the PyTorch download host, pinned to the cu117 build for cp39 or cp310 on linux x86_64, so the wheel is selected by string match rather than by a version constraint. Each also pins `jax==0.4.11` and a `jaxlib` URL pointing into a Google Storage bucket path specific to cuda11 and cudnn86. And each pins clawpack to a single commit with `git+https://github.com/clawpack/clawpack.git@d619d6835ce128a0421aa52d70d2a6c9d9d1ce93`, so installing the extra reaches GitHub, resolves that revision and builds from source. Note also that `torch~=1.13.0` already appears in the unconditional dependency list, which the extras then override by URL. The 3.10 extra begins:

datagen310 = [
    "six",
    "clawpack@git+https://github.com/clawpack/clawpack.git@d619d6835ce128a0421aa52d70d2a6c9d9d1ce93",
    "dash",
    "phiflow",
    "torch @ https://download.pytorch.org/whl/cu117/torch-1.13.1%2Bcu117-cp310-cp310-linux_x86_64.whl",
    "jax==0.4.11",
]

The `datagen39` extra repeats that shape with cp39 wheel names, which is why the two extras are named after an interpreter rather than after a capability.

A live data path bug is fixed by uncommenting lines 185 to 188

There is a known defect with a source-level workaround rather than a fix. Hydra modifies `data_path` at runtime, which breaks paths during forward training in `model/fno/utils.py` and `model/unet/utils.py`, and the instruction is to use the commented lines: 185 to 188 in the fno file and 185 to 187 in the unet file. The change is a `to_absolute_path` call in Hydra, which the note says requires Hydra 0.11.0 or newer. The fragility is in the addressing. A repository that ships commented-out code plus a README pointing at line numbers is one commit away from the instruction naming the wrong lines, and a reader who follows it in the wrong place gets a silent behaviour change rather than an error. The two files sit under the `model/` path while the package itself is `pdebench/`, so the paths in the note are relative to the repository root rather than to the installed package.

hatch-vcs is a build requirement while the version is written by hand

The build system requires both `hatchling` and `hatch-vcs`, the tool that derives a version from git tags. The project table then sets `version = "0.1.0"` statically, which is the value hatch-vcs would otherwise produce, so the dependency is present but the derivation is not in use. The published history matches: one release, v0.1.0, on 2023-08-25. That tag is nearly three years older than the last push on 2026-03-30, so the artifact on PyPI predates the compatibility work, the data path note and whatever else the branch has accumulated since. Anything installed from the index is therefore not the code in this repository. Licensing has a similar shape: the project table declares `license = {file = "LICENSE.txt"}` and a LICENSE.txt sits at the root, while the license information attached to the repository asserts nothing at all.

Datasets are two DOIs and the uploader wants a token in a file named .env

None of the data is in the repository. Two separate deposits on the same Dataverse instance hold the rest: `doi:10.18419/darus-2986` for the PDEBench datasets and `doi:10.18419/darus-2987` for the pre-trained models. The repository holds the code to generate, upload, download, train and evaluate, and the upload path is the part with a secret in it. `uploader.py` pushes generated data to the data repository, and the credentials it needs, a Dataverse URL and an API token, live in a `.env` file inside the data generation directory. The note about that file is specific about its name: it must be strictly `.env`, with the word example removed from the filename. That instruction exists because a copy left as `.env.example` would be ignored rather than loaded, which is safe, but nothing in the note reminds you that the populated version must not be committed, and the repository root's ignore rules are not restated here. The `noxfile.py` and `.pre-commit-config.yaml` at the root are the project's own gates for tests and formatting.

Two code trees cover two unrelated families of equations

Data generation is split into two directories with different conventions. The first, `data_gen`, is a flat set of scripts named for what they produce: `gen_diff_react.py` for 2D diffusion-reaction, `gen_diff_sorp.py` for 1D diffusion-sorption, `gen_radial_dam_break.py` for 2D shallow-water, and `gen_ns_incomp.py` for 2D incompressible inhomogeneous Navier-Stokes. Alongside them sit `plot.py`, `uploader.py`, a `configs` directory of YAML per simulation, and a `src` directory holding the solver sources such as `sim_diff_react-py`, `sim_diff_sorp.py` and a `swe` directory for shallow-water. The second tree, `data_gen/data_gen_NLE`, is one directory per equation instead, with `utils.py` holding boundary and initial conditions and separate directories for AdvectionEq, BurgersEq, CompressibleFluid and ReactionDiffusionEq. DarcyFlow is not a directory at all; it is generated by a shell script, `run_DarcyFlow2D.sh`, and that line is where the listing stops.

JAX is called six times faster, for a component with unresolved compatibility

The GPU section attaches a performance claim to one framework: JAX is described as approximately 6 times faster than PyTorch for simulations in the authors' tests, with a link to the JAX install instructions. The scope word is doing work. The claim is about simulation and data generation, not about model training, and the data generation path is exactly where the newer-version compatibility is unresolved, since the verification note names `data_gen_NLE` but not `data_gen`. Meanwhile the extras still pin `jax==0.4.11`, the version the project officially targets. Two smaller version drifts sit alongside: the unconditional pins say `torch~=1.13.0` while the GPU section says the latest PyTorch supported is v1.13.1 and the conda instructions install v1.13.1 with torchvision 0.14.1 and torchaudio 0.13.1. DeepXDE also needs a manual step, since the note says the tests used PyTorch as its backend and points at separate documentation to enable it.

Editorial conclusion

It fits a researcher on the stack it was written for, Python 3.9 or 3.10 with PyTorch 1.13, who wants the published datasets and the baseline models rather than a maintained library. It does not fit anyone who expects a current environment to install cleanly, because the upper Python bound in the metadata excludes the version the README calls verified, and the data generation extras bypass the package index entirely. Before running anything, read which of your components the compatibility note actually covers, since it names the core code, forward training and one data generator rather than the whole package, and apply the Hydra data path fix by checking the current line numbers yourself rather than trusting the ones printed.

Frequently asked questions

Official sources

1. Issues
2. pdebench/PDEBench on GitHub
3. Project website
4. README
5. Releases