Hi everyone, I'm having trouble building the distance index (.dist) for a large plant pangenome graph generated by Minigraph-Cactus, and would appreciate any advice.

I'm building a plant pangenome using Minigraph-Cactus (v3.0.1) inside its official container, which includes VG team v1.67.0. The pipeline successfully produced a 12 GB GBZ file (clip.gbz), but it has been stuck for more than 20 days when generating the .dist distance index. The command used was:

vg index -t 40 -j clip.dist clip.gbz

No error message appears, CPU usage remains near idle, and the output .dist file stays at 0 bytes. To troubleshoot, I also tried building the distance index manually using the existing .gbz and .snarls files. The command completed and produced a .dist file, but when I used it in subsequent steps such as:

vg minimizer -t 40 -i clip.min -g clip.gbz -d clip.dist

or

apptainer exec -B /public4:/public4 -B /public2:/public2 "${VG}" \
      vg giraffe -t "${THREADS}" \
      -Z "${GRAPH_GBZ}" \
      -f "${r1}" -f "${r2}" \
      -o gaf \
      --sample "${sample}" 

the process failed with the message:

error: distance index has no distance information

The graph is extremely large and branched. According to odgi stats and odgi degree, it contains 505 million nodes, 687 million edges, and around 9,600 paths, with an average node degree of 2.7 and a maximum degree of 14. This complexity likely arises from including two divergent outgroups in the pangenome alignment.

I' d like to know the recommended way to construct a working distance index for such a large and highly branched graph generated by Minigraph-Cactus. Should I use specific options such as --snarl-limit or--no-nested-distance? Is there a known workflow for splitting or simplifying the graph before distance indexing? Or is there another recommended method for creating the .dist file that works better with GBZ graphs of this size?

Any suggestions or best practices would be greatly appreciated.