NeuralOperator: torch is absent from its own dependency list

The install command is clone, editable install, then a second install

The documented installation from source is four lines, and the third and fourth are easy to skip past:

git clone https://github.com/NeuralOperator/neuraloperator
cd neuraloperator
pip install -e .
pip install -r requirements.txt

The editable flag is stated as deliberate so changes to the code take effect without reinstalling. What is not called out is that the last line is a separate operation with its own dependency list, so an editable install on its own gives you whatever pyproject declares and nothing more. The alternative is one line from PyPI:

pip install neuraloperator

Those two paths do not install the same set of packages. The source route resolves pyproject first and then overwrites or adds from requirements.txt, while the PyPI route resolves the packaging metadata alone. Anything present in one list and absent from the other is a package you either get or do not get depending on how you installed.

wandb
ruamel.yaml
configmypy
zencfg
tensorly
tensorly-torch
torch-harmonics
matplotlib
opt-einsum
h5py
zarr

torch is not in either list

The library describes itself as a PyTorch library, and the quickstart imports from neuralop.models, but the framework itself is not a declared dependency anywhere. pyproject.toml lists wandb, ruamel-yaml, zencfg, configmypy, tensorly, tensorly-torch, matplotlib, numpy>=1.25, opt-einsum, h5py, and a second zencfg entry. requirements.txt lists wandb, ruamel.yaml, configmypy, zencfg, tensorly, tensorly-torch, torch-harmonics, matplotlib, opt-einsum, h5py, and zarr. Torch appears in neither. numpy is declared with a floor of 1.25 in pyproject and not at all in requirements.txt. The practical reading is that the environment is expected to supply the framework, which is conventional for a research library that assumes a specific deep learning stack, but it means the two install routes can leave you with a package whose import fails until you install something the manifest never mentioned.

from neuralop.models import FNO

operator = FNO(n_modes=(64, 64),
              hidden_channels=64,
              in_channels=2,
              out_channels=1)

zencfg is declared twice with two different constraints

Inside the pyproject dependencies array, zencfg appears once as a bare name and again as zencfg>=0.3.0. Both entries are unconditional, so the effective requirement is the stricter of the two and the duplicate is redundant rather than optional. This is a small thing on its own, and it is worth naming because it is the kind of entry that survives review: nothing fails, the resolver takes the stronger bound, and the redundancy is invisible in an installed environment. The extras make the pattern clearer. The dev extra carries pytest, flaky, and black. The doc extra carries matplotlib, myst-nb, numpydoc, numpy>=1.25, sphinx, sphinx-gallery, sphinz-design and others including a pinned torch_harmonics==0.7.4, while the all extra is the union of dev and doc plus scipy and the same pin. torch_harmonics is the one dependency in the extras that is pinned to an exact version while everything else uses a floor, which tells you that the documentation build is the path most sensitive to version drift.

The version number is read from the package attribute, not from the manifest

The manifest declares version as dynamic and then resolves it from an attribute inside the package itself, which means the version is whatever neuralop.__version__ evaluates to at build time. Two consequences follow from that arrangement. First, there is no version literal anywhere in the packaging metadata to grep for, so a lockfile or an automation script that reads the manifest sees an empty version rather than 2.0.0. Second, the version follows the source tree, which is why the branch and the release can disagree. The last release is 2.0.0, described as a major release, dated 2025-10-22. Before that sit 1.0.2 from 2024-12-30 and 1.0.1 from 2024-12-20, and the 1.0.1 entry is labelled with a note about minor fixes and a link to a new white paper. The most recent commit is dated 2026-08-06, about two months before the current date and well after the newest tag, so anything on the branch describes a state no release has captured.

Tensorization is presented as the cheaper path, with a stated parameter count

The quickstart offers a second model beside the plain one, and frames it as an improvement rather than an alternative. The same four constructor arguments are reused, with three more:

from neuralop.models import TFNO

operator = TFNO(n_modes=(64, 64),
                hidden_channels=64,
                in_channels=2,
                out_channels=1,
                factorization='tucker',
                implementation='factorized',
                rank=0.1)

The rank of 0.1 is the parameter worth reading closely, because it is a fraction rather than an integer rank. The explanatory text says the factorization is Tucker, that the forward pass is efficient because the inputs are contracted directly with the factors of the decomposition, and that the Fourier layers end up with 10 percent of the parameters of an equivalent dense Fourier neural operator. That last figure is stated as a property of the configuration rather than measured, and it is the kind of number that should be verified against your own model before it is used in a capacity argument.

Weights and Biases logging is configured by writing a key into the package directory

The only integration described anywhere in the quickstart is a file dropped into a directory inside the installed package. To use W&B logging you create a file called wandb_api_key.txt under neuralop/config and paste your key into it. Two things follow. The first is where the file lives: it is not in your working directory and not in a user config path, so it sits inside the package tree, which for a non editable install is site-packages. Writing credentials there means they are only reachable by whoever can write to that directory, and the file is not obviously excluded from anything by name alone. The second is that wandb is an unconditional dependency in both lists rather than an extra, so the key is being collected by a library you installed for modelling work. Nothing in the visible documentation describes an environment variable alternative or how to disable the integration.

The README points at an arXiv practical guide and three citations

Beyond the install and the two quickstarts, the document routes readers outward twice. The first is documentation at neuraloperator.github.io, pointed at a dev path rather than a stable one. The second is a practical guide hosted on arXiv as 2512.01421, and it is linked from the same sentence that describes what the library is for. Three references are given for citation. The first is a library paper by Kossaifi and a long list of coauthors, arXiv:2412.10354 from 2025, which is the citable object for the codebase itself. The second is the same practical guide, Fourier Neural Operators Explained: A Practical Perspective, by Duruisseaux, Kossaifi and Anandkumar. The third is the original neural operator paper, Kovachki and coauthors, in JMLR volume 24 number 1, article 89, 97 pages, from 2023. The licence is MIT and the contributing text asks for implementations, benchmarks and interactive examples to be folded into the library rather than published alongside it.

Editorial conclusion

NeuralOperator fits a PyTorch research group that wants the official Fourier neural operator implementations and the Tucker variant, and it does not fit an environment that expects a library to declare its own framework dependency. Before installing, read the two dependency lists side by side, since torch is absent from both, zarr appears only in requirements.txt, and zencfg is written twice in pyproject.toml with two different constraints. If you rely on the editable install path, you get torch from your own environment and you own the version pin. Pin releases deliberately rather than tracking the branch, since the latest tag is 2.0.0 from 2025-10-22 and the most recent commit is dated 2026-08-06.

Frequently asked questions

Official sources

1. License: MIT
2. neuraloperator/neuraloperator on GitHub
3. Project website
4. README
5. Releases