DiGress generates graphs by denoising them step by step

Graph generation as a denoising process

DiGress is the code for the paper DiGress: Discrete Denoising diffusion for graph generation, published at the Eleventh International Conference on Learning Representations in 2023, by Clement Vignac, Igor Krawczuk, Antoine Siraudin, Bohan Wang, Volkan Cevher and Pascal Frossard. The idea is that a graph is a discrete object, so the generation process is framed as a discrete denoising diffusion rather than a continuous one, and the code reflects that with a separate continuous model available alongside the discrete one. The run entry point is a single script for everything, driven by Hydra for parameter overrides, which is why the README spends most of its space on the environment setup rather than on the model.

Running the code through Hydra

All code is launched through main.py, and the README points at the Hydra documentation for overriding defaults. The recommended first step is the debug configuration:

python3 main.py +experiment=debug.yaml

The README advises trying debug mode before launching full experiments, which is the right order for a codebase where the default run may train for hours. The other invocations it documents are equally short. To run on only a few batches, the general name override is used, and the model is selected by configuration group, with model=continuous for the continuous model and no override for the discrete one. The dataset is chosen the same way, for example dataset=guacamol, and the list of available datasets lives in configs/dataset. Adding a dataset means both a file in that directory and adapting the code in main.py to handle it.

The environment is the hard part

The installation instructions are unusually specific, and the reason is a dependency conflict that has not been resolved. The code was tested with PyTorch 2.0.1, cuda 11.8 and torch_geometrics 2.3.1. The rdkit environment is created directly from conda-forge with rdkit=2023.03.2 and python=3.9, and the instructions ask you to verify it by importing Chem from rdkit in a one-line python3 command. graph-tool is installed separately at version 2.45 and checked with a graph_tool import, the cuda drivers come from the nvidia channel for your cuda version, and the matching torch version is installed from the PyTorch wheel index, for example torch==2.0.1 with the cu118 index. The remaining Python packages come from the requirements file and the project is installed in editable mode. One step is not Python at all: the orca analyser has to be compiled by hand in the src/analysis/orca directory with g++.

The known bug in the graph transformer

The most recent entry in the README, dated September 10th, 2026, records a bug that was identified by Arda Arslan: in the construction of the GraphTransformer, dim_ffy is ignored and the default value of 2048 is used, so the value described in the paper is incorrect. The author's own comment is that the impact on performance is unknown. This is worth reading carefully before using any result from this repository, because a silently ignored dimension parameter in the feature network is the kind of defect that changes what the model computes without changing whether it runs. The README also points at a second branch, fixed_bug, in which some neural network layers have been fixed, and the recommendation for anyone training new models from scratch is to use that branch. The fixed_bug branch has not been evaluated, but should normally perform better, and the author asks for results from it on the datasets provided here.

Checkpoints that mostly do not exist any more

The checkpoint section carries an unusual request at the top: the author's drive account was deleted and access to the checkpoints was lost, and the author asks that anyone holding a downloaded checkpoint send it by email or raise an issue. The README then lists what should work with the latest commit, a QM9 checkpoint for heavy atoms only and a Planar checkpoint hosted on a Swiss file share, both pointing at the same link, plus a MOSES checkpoint on Google Drive that the author says was sent to him but that he has not tested, and a Guacamol checkpoint in the same condition. The SBM checkpoint is struck through, and the README keeps its measured performance instead: a test NLL of 4757.903, with spectre at 0.0060, clustering at 0.0502, orbit at 0.0462 and sbm_acc at 0.675.

Adding a dataset of your own

The extension path is documented in enough detail to be useful. A new dataset means a new file in src/datasets, and depending on whether you are working with molecules or abstract graphs you base it on moses_dataset.py or spectre_datasets.py. That file has to implement a Dataset class to process the data, following the PyG documentation, and a DatasetInfos class that defines the noise model and some metrics. For molecular datasets, DatasetInfos has to specify the atom_encoder, which defines the one-hot encoding of the atom types, the atom_decoder, described as simply the inverse mapping of the atom encoder, the atomic weight for each atom type, and the most common valency for each atom type. Node counts and the distribution of node types and edge types are computed automatically by functions from AbstractDataModule. Once the file exists, main.py is adapted and a file is added in configs/dataset.

Where DiGress is the wrong choice

Three cases. The first is production use, because the pretrained weights are on personal file shares, two of the three listed checkpoints are explicitly untested, and the author is asking the community for replacements. The second is large graphs, where the README points you to SparseDiff, a sparse version of DiGress maintained separately, for anything beyond roughly 100 to 200 nodes. The third is macOS, where the README says graph_tool and torch_geometric currently seem to conflict and that the issue has not been solved. Against a graph generation approach that does not diffuse at all, such as an autoregressive model that adds nodes and edges one at a time, the difference in approach is that DiGress denoises a whole corrupted graph toward a clean one, which changes the training signal and the sampling cost profile, and the repository's per-dataset checkpoints and metric reporting exist because that is a research workflow. The dependency set is heavy for what it buys: rdkit, graph-tool, torch_geometric, pytorch_lightning, wandb and a hand-compiled analyser.

Editorial conclusion

DiGress is a good fit for a research group that wants to reproduce or extend discrete diffusion for graph generation and is prepared to build a conda environment with rdkit and graph-tool and compile a C++ analyser by hand. It is a poor fit for a production pipeline, since the model weights are hosted on personal file shares, the reference checkpoints are described as untested, and the README asks for help recovering them. Check three things before you plan a run: that you use the fixed_bug branch rather than the default one, since the README says the default main branch has network layers that were fixed in a branch that has not been evaluated but should normally perform better; that the environment matches what was tested, PyTorch 2.0.1, cuda 11.8 and torch_geometrics 2.3.1 with a rdkit 2023.03.2 conda environment on Python 3.9; and that you compile orca yourself in src/analysis/orca, since a missing orca binary is the documented cause of the PermissionError in the troubleshooting section.

Frequently asked questions

Official sources

1. cvignac/DiGress on GitHub
2. Issues
3. License: MIT
4. README