gappa examine assign Segmentation fault with --consensus-thresh 1

[johnne]

I'm running gappa examine assign to assign taxonomy to queries placed into a reference tree of 48313 sequences.

The command is:

gappa examine assign \
    --threads 2 \
    --out-dir out \
    --jplace-path epa-ng_result.jplace \
    --taxon-file chesters_expanded_taxonomy_reformat.tsv \
    --ranks-string 'Kingdom|Phylum|Class|Order|Family|Clade|Genus|Species' \
    --consensus-thresh 1 \
    --best-hit \
    --allow-file-overwriting \
    --per-query-results

but it quits after running for about 5 minutes with Segmentation fault error.

I've tried with both version 0.9.0 and 0.8.4, running with both apptainer and a conda environment, with the same result. This is part of a workflow where the input queries are split into files of 500 sequences each and weirdly enough I noticed that one of the files did not fail and in fact produced the per-query-result file. Then I also noted that if I reduce the consensus threshold from 1 then the command completes without errors, also for the input file that failed with consensus threshold set to 1. Anything below a strict 1 seems to work (I tested 0.5 and 0.99).

I'm attaching the --taxon-file and two *.jplace files:

• epa-ng_result.FAILS.jplace : This is the jplace file that fails with consensus threshold 1 (but works with threshold <1)
• epa-ng_result.WORKS.jplace : This file works with threshold = 1 (and <1).

I'm wondering if the problem could be that some queries get placed so that using a strict consensus of 1 results in no label being possible?

If you have time to look into this I'd greatly appreciate it.

jplace.tar.gz

[lczech]

Hi John,

thanks for reporting this!

I'm wondering if the problem could be that some queries get placed so that using a strict consensus of 1 results in no label being possible?

Yes, that was my first guess as well. The assign command is the only one in gappa that I did not write myself, so I'll need to examine the code in some more detail to get to the bottom of this. Not sure when I'll have the time for that... :-(

Are you able to work for now with a threshold < 1, to circumvent this issue for now?

Cheers
Lucas

[johnne]

Thanks for the quick reply! Yes I'll try running a full dataset with threshold 0.99 which should be fine for now.

[lczech]

Hi @johnne,

just was about to look into this, and noticed that you did not attach the --taxon-file. Unfortunately, without it, I cannot run your command. Could you please share this here?

Cheers
Lucas

[johnne]

Sorry about that, here it is.

chesters_expanded_taxonomy_reformat.tsv

[lczech]

Thanks! Now however I am seeing that something is wrong with the jplace.tar.gz file.

First, I'm extracting the archive:

> tar -xvzf jplace.tar.gz 
._epa-ng_result.FAILS.jplace
tar: Ignoring unknown extended header keyword 'LIBARCHIVE.xattr.com.apple.provenance'
epa-ng_result.FAILS.jplace
epa-ng_result.WORKS.jplace

But then the FAILS file is still gzipped somehow (it says), and when I unzip it, it unpacks to a file identical to the WORKS file again...

Not sure what went wrong there (Mac vs Linux gzip?!). Could you please check and re-upload those files here again?

Cheers
Lucas

[lczech]

Hey @johnne, any news on this? In short, your gzip file seems broken - could you please re-upload it here?

[johnne]

Hi,
Sorry about the late reply. I lost the original file during a clean-up unfortunately. Also, I realized I was passing the original reference tree to epa-ng for placement while I should be passing the info.raxml.bestTree from my raxml evaluate step. Correcting this seems to have also corrected the jplace files so that I don't see the error anymore.

[lczech]

Thanks for the update! Hm, that's a pity, because the Segmentation fault that you described initially should not happen either way, even with a wrong tree file. Do you see any chance to recover those files so that I can attempt to fix the issue? If not, I guess we can close this issue, or is there anything we can try to investigate still without those original files?