AIRS: nine open source projects for AI for science, organised by physical scale

A collection repository, not a tool

AIRS is described as a collection of open source software tools, datasets and benchmarks associated with the paper Artificial Intelligence for Science in Quantum, Atomistic, and Continuum Systems. The stated goal is to develop and maintain an integrated, open, reproducible and sustainable set of resources for the field of AI for Science, and the documentation is explicit that the list of resources will grow as the research progresses.

That framing matters, because it changes what you get. The repository is not a library, not a package and not a framework. There is no install step, no single dependency to add and no API to call. What is at the top level is an index.

The primary language is recorded as Jupyter Notebook, which is consistent with a collection whose members are research code and notebooks rather than a published library. The top level listing makes the structure plain: nine directories named after the sub-projects, plus `Overview/`, `figures/`, the logo, the licence and the overview image.

The audience is the AI for Science research community, and specifically people who want both the code and the evaluation data for a specific scientific domain. The companion survey paper and the website at air4.science are given as the places with more detail, and a BibTeX entry is provided for citing the survey.

One thing the repository does not attempt is unification. Each sub-project is a separate body of work with its own dependencies and its own setup, and nothing in the top level suggests they share a common runtime or a single install path.

Nine projects across three scales of physics

The sub-projects are grouped by the physical description they model, and the grouping is the taxonomy of the survey.

At the quantum level is OpenQM, for AI for Quantum Mechanics, containing LCN and DiffVMC.

The atomistic group is the largest. OpenDFT covers AI for Density Functional Theory with QHNet, QHBench, OrbEvo and OrbFlow. OpenMol covers AI for Small Molecules with SphereNet, ComENet, GraphDF, G-SphereNet, PACE, Geo2Seq, TDN and Force2Geo. OpenProt covers AI for Protein Science with ProNet and LatentDiff.

Continuum systems are covered by OpenMat for AI for Materials Science with Matformer, PotNet, SyMat, ComFormer, GMTNet, Mat2Seq and HIENet, and OpenMI for AI for Molecular Interactions with GraphBP and Frag2Seq.

Finally the differential equation end of the spectrum: OpenPDE for AI for Partial Differential Equations with G-FNO, CFRF, SineNet, GeoMPNN and ShockCast, and OpenODE for AI for Ordinary Differential Equations, which lists a single entry, IFL-DIF.

Counting the entries gives roughly thirty named methods across nine directories. The names themselves are a useful signal of the field's shape: several are graph or equivariant network architectures for atoms and materials, a couple are flow or sequence generative models for structures and fragments, and the PDE side includes a Fourier neural operator variant and a shock casting method, which is a domain specific solver rather than a generic architecture.

Note the two benchmark directories, QHBench in OpenDFT and the datasets referenced across the collection. For a field where reported numbers often depend on the data split, a shipped benchmark is worth more than a model alone.

Why the codes are open at all

The stated rationale is in the documentation, and it is a specific one rather than a generic open source mission.

The goal is an integrated, open, reproducible and sustainable set of resources. Reproducibility is the operative word here. Machine learning methods in physical science are notoriously hard to reproduce, because a reported result depends on the dataset split, the preprocessing, the random seeds and the evaluation protocol, and a paper that ships only a model description leaves all of that implicit.

Shipping the code alongside the benchmarks and datasets is the attempt to make the numbers checkable. When QHBench travels with QHNet, a reader can run the same evaluation rather than trust a table.

There is a second motivation visible in the project names, which is that these methods are not confined to their originating groups. OpenMol contains G-SphereNet as well as SphereNet, and OpenProt contains LatentDiff as well as ProNet. Once two implementations of a method sit in the same open collection, the question of which code produced a number becomes checkable, and the methods themselves become usable baselines rather than one-off artifacts attached to a paper.

That also explains the licensing choice. The repository is GPL-3.0, with the licence file at the root and a badge pointing at it. For research code that others are expected to build on and re-run, a copyleft licence keeps derivatives in the same terms, which is a reasonable way to stop a method from being vendored into a closed product while still allowing reuse.

This is a description of the licence terms, not legal advice, and for a commercial team the implication is the same as for any GPL project: read the terms before you copy code rather than a citation.

Finding your way in without a getting started guide

There is a practical problem with the repository, and it is the absence of installation instructions rather than the presence of them.

Nothing at the top level says how to run anything. There is no requirements file, no environment specification, no single command. The documentation points at the survey paper and the website for more detail, and the directory listing of each sub-project is where the actual setup instructions live.

That means the realistic path is: identify your domain from the table, open the relevant directory, and follow that project's own documentation. If you are coming from the survey paper, you will arrive with a specific method in mind, which maps to a specific directory entry, and from there the setup is ordinary research code setup.

The risk is that this is a research collection with a natural rate of churn. Code accompanying a paper is often written to reproduce a specific result, and the environment that made it work is sometimes assumed rather than pinned. Nothing in the top level promises coordinated maintenance across the nine projects, and the last push on the top level repository was on 2026-10-01, so the collection itself is being touched, but that says nothing about the individual sub-projects.

The overview image and the `Overview/` and `figures/` directories are there to give you the map before you dive into a subtree, which is the right design for a collection this size. Nine projects times several methods each is a lot of codebases, and without the survey's taxonomy you would be guessing which one is even relevant to your problem.

How this compares with the alternatives

There are two other routes to AI for Science code, and the difference in approach is worth being explicit about.

The first is a single framework that aims to cover several domains at once, where one codebase offers model classes and training loops that can be pointed at different physics. The appeal is uniformity and a shared toolchain. The cost is that the abstractions are shaped by the domains the authors knew best, and a method from a paper whose data pipeline does not fit those abstractions ends up fighting the framework rather than using it.

The second is the model repository pattern, where a single paper's code is released on its own, often with its weights, and the community accumulates many of them side by side. This is the dominant pattern in machine learning generally, and it has the advantage that each artefact is optimised for its own task. Its weakness is exactly what AIRS is organised against: comparing methods means reconciling data pipelines yourself, and reproducibility depends on the original authors keeping their environments alive.

AIRS sits between the two. It is curated, in the sense that a group has chosen which methods to include and grouped them by physical scale, and it is reproducible in the sense that benchmarks and datasets travel with the code. What it does not attempt is a unified interface, so adopting it means adopting one of the sub-projects and living with its setup.

For a researcher who already knows which method they need, the practical comparison is simpler than the taxonomy: check whether the relevant sub-project is here and whether its environment still installs. For a researcher surveying the field, the survey paper and this collection are a considerably better starting point than a search across individual repositories.

Who should adopt it, and what to check first

AIRS is worth adopting for its curation and its benchmarks, not as code you drop into a project.

It is aimed at people doing AI for Quantum Mechanics, Density Functional Theory, small molecules, proteins, materials, molecular interactions, partial differential equations or ordinary differential equations, and at the people reviewing or extending that work. If you are building an application that needs one of these methods, the sub-project for it is a legitimate reference implementation with the evaluation harness that produced the published numbers, which is more than most individual releases offer.

The cases where it is the wrong tool are just as clear. If you want an installable package with versioned releases and a support commitment, this is not that, since the repository has no GitHub releases and the individual sub-projects are the unit of work. If your interest is data rather than methods, the datasets are scattered across sub-projects rather than offered as one curated corpus.

The first thing to verify is which sub-project matches your domain and whether its environment still installs, because the collection does not pin it for you. The second is the licence, if you intend to copy code rather than cite it, since GPL-3.0 is the term you inherit. The third is the survey paper itself, because it is the piece that tells you how the methods relate, and a collection without its taxonomy is just a list of directories.

On activity, the repository is not archived, the last push was on 2026-10-01, and the licence is GPL-3.0 with the file at the repository root.

Editorial conclusion

Adopt AIRS if you are looking for a citable, curated set of implementations and benchmarks for AI applied to physical science rather than a single tool, and you want the survey paper's taxonomy to orient you. Do not adopt it as a library you install, since the repository is a collection of separate research projects with their own dependencies, and there is no install command or package to pull. Verify first which sub-project matches your domain, since OpenPDE, OpenODE, OpenQM and the rest are independent codebases with their own setup, and check the survey paper before assuming the implementations are maintained in step with each other.

Frequently asked questions

Official sources

1. divelab/AIRS on GitHub
2. Issues
3. License: GPL-3.0
4. Project website
5. README