vg call runs for days with no output

[Victoria-pda]

1. What were you trying to do?

I was trying to perform variant calling using vg call on a maize pangenome constructed with the cactus-minigraph workflow.

Specifically, I built a pangenome from 25 maize assemblies (GBZ size ~8.0 Gb), aligned Illumina paired-end reads from 200 resequenced individuals to this graph using vg giraffe, generated per-sample coverage with vg pack, and then attempted to call variants (SNPs, indels, SVs) using vg call.

2. What did you want to happen?

I expected vg call to eventually produce a VCF file for each individual, even if the runtime was long, or at least to show progress or emit warnings/errors if the computation was infeasible at this scale.

3. What actually happened?

**For the very first sample, vg call has been running for more than 5 days with:

• no VCF output produced,
• no error messages,
• no stack trace,
• and no visible progress information.

The process does not appear to be killed by the system (no OOM), but it seems either stalled or extremely slow. This makes it difficult to determine whether the behavior is expected or whether something is misconfigured.**
4. If you got a line like Stack trace path: /somewhere/on/your/computer/stacktrace.txt, please copy-paste the contents of that file here:

No stack trace was produced.

5. What data and command can the vg dev team use to make the problem happen?

Data:

• Pangenome constructed using the standard cactus-minigraph workflow
• 25 maize assemblies
• Final graph index: maize_pg.gbz (~8.0 Gb)
• Illumina paired-end resequencing data

Commands used (for one sample):

# Graph alignment
vg giraffe \
  -Z maize_pg.gbz \
  -f ${id}_1.clean.fq.gz \
  -f ${id}_2.clean.fq.gz \
  -t 50 \
  > ${id}.gam

# Snarl detection
vg snarls -t 20 maize_pg.gbz > maize_pg.snarls

# Coverage packing
vg pack \
  -x maize_pg.gbz \
  -g ${id}.gam \
  -Q 5 \
  -t 20 \
  -o ${id}.pack

# Variant calling
vg call \
  maize_pg.gbz \
  -r maize_pg.snarls \
  -k ${id}.pack \
  -a -A \
  -t 20 \
  -s ${id} \
  > ${id}.vcf

6. What does running vg version say?

vg version v1.65.0 "Carfon"
Compiled with g++ (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0 on Linux
Linked against libstd++ 20230528
Using HTSlib headers 101990, library 1.19.1-29-g3cfe8769
Built by anovak@courtyard.gi.ucsc.edu

[Victoria-pda]

After adding the "-z -c 50 -C 10000000" parameters, the vg call command completed quickly and output approximately 7G of VCF results.
Additionally, I further tested the "-C 1000000" parameter and found that the two VCF files were identical in size and content.
These results have met my requirements. I suspect the reason the program got stuck previously might be due to a particularly large snarl. Unfortunately, I did not add the "--progress" parameter to the previous command, so I cannot provide more detailed information.

[faithokamoto]

Is this problem resolved for you, then?