The qiime diversity alpha-reformation step runs slowly

[sqzhou]

When I run qiime diversity alpha rarefaction to calculate the dilution curve on the table flattened by metagenome, I found that the running time is very long(it has been running for about 5 days but not yet finished). Is there any good way to solve it? The running command is as follows:

qiime diversity alpha-rarefaction \
  --i-table rarefied_table.qza \
  --p-metrics observed_features shannon simpson chao1 goods_coverage \
  --p-max-depth 12158633 --p-min-depth 10 \
  --p-steps 20 --p-iterations 30 \
  --m-metadata-file sample_map.txt \
  --o-visualization alpha-rarefaction.qzv

[colinbrislawn (Colin J Brislawn)]

Here are the docs for:
qiime diversity alpha-rarefaction

@sqzhou

Is there any good way to solve it?

First, 5 days could be indicative of an error or another problem. Maybe check the HPC error logs?

You could try the using the new parallelized plugin, q2-boots!

QIIME 2 Library

And finally, you could also change some settings

  --p-max-depth 12158633 --p-min-depth 10 \

So 12,158,633 is 12m reads. Maybe just go to 1m reads, or 100k reads, or 10k reads?

  --p-steps 20 --p-iterations 30 \

That's 20x30 = 600 total tables. Fewer tables would be faster!

[gregcaporaso]

@sqzhou

--p-steps 20 --p-iterations 30

Following on @colinbrislawn's reply, this is where I would start. --p-steps 10 --p-iterations 3 should give you a pretty informative view, but depending on the table size this could still take a long time.

Also, what version of QIIME 2 are you using (call qiime tools info to find that information if you don't know off-hand)? There may have been some performance improvements that could impact this, so best to use 2025.10 (the most recent release).

@colinbrislawn

--p-max-depth 12158633 --p-min-depth 10

I'll often set the max-depth to about 75% of the largest sequence / sample count (at least on a first pass at this). min-depth of 10 is fine, but probably not super informative (so starting around 10000 might be more interesting - that probably won't impact run time much though).

@colinbrislawn

You could try the using the new parallelized plugin, q2-boots!

Note that this doesn't yet have an alpha-rarefaction action, though we may get there.

@colinbrislawn

Maybe check the HPC error logs?

That's also not a bad idea. Alternatively you could ssh into the node that the job is running on and run htop to make sure it's using CPU.