Plugin error from fragment-insertion: 'tree.nwk returned non-zero exit status.'

Hi

I am conducting a meta-analysis involving 2903 studies, resulting in a table size of 107GB. I am attempting to create a phylogenetic tree this September. I've been running the process for two months on an HPC (High-Performance Computing) node with 80 cores and 250GB of RAM, using the command with --threads 78.

However, I encountered an error with the message 'Plugin error from fragment-insertion' stating that 'tree.nwk returned non-zero exit status.'

The command I used was:

qiime fragment-insertion sepp \
  --i-representative-sequences KT_sequences5011.qza \
  --i-reference-database sepp-refs-gg-13-8 \
  --o-tree kt83_5011_tree.qza \
  --o-placements kt83_5011_tree_placements.qza \
  --p-threads 78

Do you have any suggestions on how to speed up the process and generate my phylogenetic tree more quickly?"

Hello @kulandai1. Can you please rerun the failing command with the --p-debug flag and post the output here? Thank you.

Hi Oddant
Thank you for your reply, the command is running.
Following are the log file of previous run
Removing /home/balamurugan.s/temp/tmp.vU9KnSQllU/sepp-tmp-1vA2EubnN1
Traceback (most recent call last):
File "/home/dell_emc/easybuild/software/QIIME2/2023.5/lib/python3.8/site-packages/q2cli/commands.py", line 468, in call
results = action(**arguments)
File "", line 2, in sepp
File "/home/dell_emc/easybuild/software/QIIME2/2023.5/lib/python3.8/site-packages/qiime2/sdk/action.py", line 274, in bound_callable
outputs = self.callable_executor(
File "/home/dell_emc/easybuild/software/QIIME2/2023.5/lib/python3.8/site-packages/qiime2/sdk/action.py", line 509, in callable_executor
output_views = self._callable(**view_args)
File "/home/dell_emc/easybuild/software/QIIME2/2023.5/lib/python3.8/site-packages/q2_fragment_insertion/_insertion.py", line 71, in sepp
_run(str(representative_sequences.file.view(DNAFASTAFormat)),
File "/home/dell_emc/easybuild/software/QIIME2/2023.5/lib/python3.8/site-packages/q2_fragment_insertion/_insertion.py", line 53, in _run
subprocess.run(cmd, check=True, cwd=cwd)
File "/home/dell_emc/easybuild/software/QIIME2/2023.5/lib/python3.8/subprocess.py", line 516, in run
raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '['run-sepp.sh', '/home/balamurugan.s/temp/qiime2/balamurugan.s/data/9deb2fb4-3dc2-4a2a-8cfc-95c40a964528/data/dna-sequences.fasta', 'q2-fragment-insertion', '-x', '80', '-A', '1000', '-P', '5000', '-a', '/home/balamurugan.s/temp/qiime2/balamurugan.s/data/a14c6180-506b-4ecb-bacb-9cb30bc3044b/data/aligned-dna-sequences.fasta', '-t', '/home/balamurugan.s/temp/qiime2/balamurugan.s/data/a14c6180-506b-4ecb-bacb-9cb30bc3044b/data/tree.nwk', '-r', '/home/balamurugan.s/temp/qiime2/balamurugan.s/data/a14c6180-506b-4ecb-bacb-9cb30bc3044b/data/raxml-info.txt']' returned non-zero exit status 1.

I will post the --p-debug as soon as possible

Thank you

Hello @kulandai1. Apologies for the delay, I was out of office. Unfortunately that log file is not giving me a lot of information to work with. it's unlikely that --p-debug would give me much more, but can you try that anyway and post the result here?

Currently, my best guess is that you are running out of RAM. Can you run the free command and post the output here, additionally can you run the command /usr/bin/time -v <your QIIME 2 command here> and post the output of that here too. That should let me verify if you are running out of RAM or not.

If you are running out of RAM your best bet is probably to lower the number of threads.

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.

Hi
In follow up previous threads, I am still facing the same error in insertion tree.
Sorry for the late reply,

Herewith, I have attached the log file and error file, kindly give suggestions.

Thanks for you time.
ktseq_13jan.all.txt (724 Bytes)
q2-insertion.txt (1.1 KB)
qiime2-q2cli-err-x155tdcv.txt (1.8 KB)

Hello @kulandai1. At this point one thing you might try is updating to the latest QIIME 2 2023.9 release, but since you are on an HPC I understand if this is not an option for you.

Can you try adding /usr/bin/time -v in front of your qiime command like so?

/usr/bin/time -v qiime fragment-insertion sepp \
  --i-representative-sequences file_for_phylogeny_gg/TK_mangrove_rep_seqs_nonchimeric_wo_mit_ch.qza \
  --i-reference-database sepp-refs-gg-13-8.qza \
  --o-tree file_for_phylogeny_gg/TK_insertion_tree_gg.qza \
  --o-placements file_for_phylogeny_gg/TK_tree_placements_gg.qza \
  --p-threads 32

This should cause the output to show some diagnostic information including the amount of RAM used. You do have a lot of RAM, but you also have big data, so it is possible you are running out.

Hi
Thank you for the reply
I have placed the job as per your suggestion, once I got the output I give reply here.

Thanks

Hi
Here is the output for the command with /usr/bin/time -v
Plugin error from fragment-insertion:

Command '['run-sepp.sh', '/home/balamurugan.s/temp/qiime2/balamurugan.s/data/464974e9-a547-4f90-aa8c-41a21a18a202/data/dna-sequences.fasta', 'q2-fragment-insertion', '-x', '32', '-A', '1000', '-P', '5000', '-a', '/home/balamurugan.s/temp/qiime2/balamurugan.s/data/a14c6180-506b-4ecb-bacb-9cb30bc3044b/data/aligned-dna-sequences.fasta', '-t', '/home/balamurugan.s/temp/qiime2/balamurugan.s/data/a14c6180-506b-4ecb-bacb-9cb30bc3044b/data/tree.nwk', '-r', '/home/balamurugan.s/temp/qiime2/balamurugan.s/data/a14c6180-506b-4ecb-bacb-9cb30bc3044b/data/raxml-info.txt']' returned non-zero exit status 1.

Debug info has been saved to /home/balamurugan.s/temp/qiime2-q2cli-err-qfoq0dja.log
Command exited with non-zero status 1
Command being timed: "qiime fragment-insertion sepp --i-representative-sequences file_for_phylogeny_gg/TK_mangrove_rep_seqs_nonchimeric_wo_mit_ch.qza --i-reference-database sepp-refs-gg-13-8.qza --o-tree file_for_phylogeny_gg/TK_insertion_tree_gg.qza --o-placements file_for_phylogeny_gg/TK_tree_placements_gg.qza --p-threads 32"
User time (seconds): 14483756.15
System time (seconds): 123453.17
Percent of CPU this job got: 2044%
Elapsed (wall clock) time (h:mm:ss or m:ss): 198:28:12
Average shared text size (kbytes): 0
Average unshared data size (kbytes): 0
Average stack size (kbytes): 0
Average total size (kbytes): 0
Maximum resident set size (kbytes): 254063000
Average resident set size (kbytes): 0
Major (requiring I/O) page faults: 3584
Minor (reclaiming a frame) page faults: 80059536312
Voluntary context switches: 137450392
Involuntary context switches: 39143917
Swaps: 0
File system inputs: 288230216
File system outputs: 4616557128
Socket messages sent: 0
Socket messages received: 0
Signals delivered: 0
Page size (bytes): 4096
Exit status: 1
Thank you

Hello @kulandai1. It looks like you are in fact running out of memory. This is the maximum memory usage of your action:

 Maximum resident set size (kbytes): 254063000

Which is about 254GB. It is likely your action would need more RAM than that to succeed; that's just the maximum amount it was able to use before the OS killed it. If you cannot get access to more RAM, then your best bet is probably to decrease the number of threads you are using even down to 1 if necessary. This could take a very long time, but fewer threads uses less RAM.

Thank you
I will try using --p-n-thread 16 and hope for the best.