DeepQMC installs the JAX build it tells you not to use

The default install gives you the configuration the docs advise against

Two installation routes exist, and only one of them produces what the project actually wants you to run.

pip install -U deepqmc

That leaves you with the CPU version of JAX, and the paragraph immediately after says that running DeepQMC on the GPU is highly recommended. Moving to a GPU build is a separate manual step, and it is not presented as an extra to install but as a version of JAX you have to replace yourself, matched to the CUDA and cuDNN versions already present on your machine.

# CUDA 12 installation
pip install "jax[cuda12]" -f https://storage.googleapis.com/jax-releases/jax_cuda_releases.html

The documented happy path is therefore install, then immediately undo part of what you just installed. A reader who stops at the first code block ends up on the slow configuration with no error and no warning, and the only signal that something is missing is how long a run takes. The pip install is also the one command that validates the environment, since running `deepqmc` on its own is what checks that the package and its dependencies came together correctly.

The setup.py troubleshooting note outlived setup.py

The installation section carries a support note that no longer maps to the project. If Pip complains about `setup.py` not being found, you are told to update to the latest Pip version. There is no `setup.py` in this repository. Packaging is declared entirely in `pyproject.toml` against a setuptools build backend that requires setuptools 61 or newer, which is the configuration that made a `setup.py` shim unnecessary. The advice is also self-defeating as written, because a modern Pip objecting to a missing `setup.py` is the exact symptom of the situation that renders the note obsolete. It is a small thing that nevertheless sits in the paragraph a stuck first-time user is reading. `setup.cfg` is also still present in the tree next to `pyproject.toml`, so two packaging configuration files are in play at once and the package metadata is split across both.

git clone https://github.com/deepqmc/deepqmc
cd deepqmc
pip install -e .[dev]

Seventeen direct dependencies and two hard upper bounds

The dependency list is long and includes some heavy company. Alongside JAX and Haiku the suite pulls in `folx`, `kfac-jax`, `optax`, `jaxtyping`, `jax-dataclasses` and `chex`, plus `pyscf` for classical quantum chemistry reference calculations, `h5py` for storage, `tensorboardX` for logging, `uncertainties` for error propagation, and `scipy` for numerics. Configuration runs through `hydra-core`. Two entries carry ceilings instead of floors: `jax<0.9.0` and `chex<1.0.0`, so a JAX upgrade is a coordinated decision rather than something pip resolves on its own. For an integrator the consequence is that DeepQMC occupies a real slice of the JAX version space, and the ceiling on the central dependency means reproducing an older result later can come down to pinning back a stack that its own neighbours have already moved past. Documentation carries its own extra as well, separate from the development one and holding sphinx and Jinja2 among other packages, so a single package ends up with three install profiles to reason about: runtime, contributor, and docs builder.

Six named ansatz variants are config files, not code

The general neural network ansatz is the point of the suite, and the named variants arrive as configuration rather than as separate implementations. Config files for Psiformer, PauliNet, FermiNet, DeepErwin, LapNet and TransPsiformer, the last described as a transferable extension of the self-attention ansatz, sit under `src/deepqmc/conf/ansatz`. That is the whole extension story for most users: choose a directory, adjust values, and you have one of six published wave function forms without writing a model. It also means the ansatz is not a plugin interface in any dynamic sense, since nothing suggests a registry that new code joins at run time. What each config directory contains, how many knobs a variant exposes, and whether a wave function outside that set can be added without forking the package are all left to the documentation site rather than stated here.

Excitation and geometry transfer are two separate switches

The physics scope is wider than the name suggests, and it is worth separating what the code does from how a run selects it. Ground and excited electronic states are both simulated using deep neural network trial wave functions. Excitation is reached through a penalty-based excited-state optimization rather than by building a different state, and a separate spin penalty lets a run target states inside a fixed spin sector. Effective core potentials are supported, which is what makes heavier elements tractable. Geometric transferability is the second axis: a single ansatz can be optimized across multiple configurations of the same set of atoms, either by training on a fixed set of molecular configurations or by sampling configurations dynamically throughout the optimization, and it can be combined with the excited-state work. That combination is the interesting part and the one easiest to underuse, since the published demonstration of transferability covers the fixed dataset case.

Four citation targets for one package

A suite this size accumulates citation obligations, and DeepQMC carries four of them plus a metadata file. If you used the implementation, cite the Journal of Chemical Physics paper from 2023. If your experiments involve excited-state optimization, cite the 2024 Journal of Chemical Theory and Computation paper on the improved penalty-based approach. If you used transferable optimization, cite the 2025 preprint on ab initio simulation of excited-state potential energy surfaces. Independent of all three, the repository itself is citable as software through a Zenodo deposit, and the tree also carries a `CITATION.cff`. The Zenodo identifier shows up both as a badge and inside the software entry, whose declared year is 2026 and whose copyright field is MIT. Handing four separate citation blocks for one package is careful work, and it also signals documentation written by people who expect to be counted. The prose follows the same division of labour. Basic usage and tutorials live on the documentation site, while the methodology, implementation details and exemplary experiments are deferred to the software paper, so the two references answer different questions and neither substitutes for the other.

Packaging metadata, two platforms, and two long release gaps

The packaging metadata is specific about what it supports and quiet about the rest. `requires-python` is `>=3.12`, and the classifiers name only Python 3.12 and 3.13, so the declared interpreter range is two versions wide. Operating system classifiers cover MacOS X and POSIX Linux, with no Windows classifier at all, which fits a JAX and CUDA-centred stack but leaves a Windows user without declared support at any version. Development status is declared as Beta. The default branch is still `master`, and the README badges point at `commits/master`, so those commit links will not resolve in a fork that renamed to `main`. No homepage field is set in the packaging metadata either, even though the documentation site, the PyPI project page and the release feed all exist and are linked from the README, so tooling that reads only declared metadata has nothing to follow. The release history is thin and unevenly tagged. The listed versions are 1.1.2 on 2023-11-20, 1.2.0 on 2024-09-16 and 1.3.0 on 2026-07-20, so roughly ten months separate the first two and about twenty-two separate the last two. The titles disagree as well: the older two are named DeepQMC 1.1.2 and DeepQMC 1.2.0 while the newest is simply 1.3.0, so anything that parses release names for a product prefix works on two entries out of three. The version declared in `pyproject.toml` is 1.3.0, which does agree with the newest tag instead of running ahead of it. The last recorded push is 2026-09-28, about two months after that release, which leaves the distance between a published version and unreleased fixes wide enough to matter when an environment is being pinned for a multi-week computation.

Regression tests hold the numbers, codespell holds the prose

For a Monte Carlo package the interesting test question is not whether the code runs but whether the numbers move. The development extra installs `pytest-regressions` alongside `pytest` and `pytest-cov`, and that plugin stores expected outputs and fails when they change, so the suite can catch silent numerical drift rather than only crashes. That is the right shape for variational Monte Carlo, where a refactor can shift an energy slightly and still import cleanly. Static checking is doubled up in a way worth knowing about: `jaxtyping` is a runtime dependency, so array shapes are annotated in code and checked while it executes, while `pyright` arrives with the contributor extras and checks the same annotations ahead of time. One practical consequence shows up in the install instructions. The editable install used for development is `pip install -e .[dev]`, which pulls black, codespell, pydocstyle, pep8-naming, pyright and pre-commit along with pytest, so a researcher who only wants to optimize a molecule installs the whole contributor toolchain. Spelling is meant to be enforced too, since codespell runs through `.pre-commit-config.yaml` and a `.codespellignore` file sits at the root, yet the README itself misspells transferable in the sentence about excited-state surface work. One concept also appears under four names across the page: geometric transferability, a transferable extension, transferable optimization, and transferable simulation. A working linter would have caught the first problem, so the open question is whether the ignore file is doing more work than the checker.

Editorial conclusion

Use deepqmc if you are running variational quantum Monte Carlo on small molecules and already have a working JAX and CUDA setup, because the suite assumes that environment rather than building one for you. Do not expect a smooth first install: replace the CPU JAX build deliberately, keep JAX below 0.9.0, and expect to select an ansatz by editing config files under src/deepqmc/conf/ansatz rather than by registering code. Before trusting a result, work out which of the four citation targets applies to your experiment, confirm the spin sector and effective core potential settings were what you intended, and reproduce the run on a fixed set of molecular configurations before trusting dynamic sampling, since the published transferability demonstration covers the fixed dataset case.

Frequently asked questions

Official sources

1. deepqmc/deepqmc on GitHub
2. Issues
3. License: MIT
4. README
5. Releases