some of the reads consist indeed of only gaps, per...
# phyloplace
a
some of the reads consist indeed of only gaps, perhaps with only one nucleotide. But reading the wiki, it would seem that EPA should be able to throw them out:
By default,
EPA-ng
enables premasking, which works similarily to the same option in pplacer: If a site of the alignment is all-gaps in either the reference OR query alignment, throw it out. Further, for each query sequence, ignore the leading, and trailing gap columns (this is where we differ from pplacer, as they ignore ALL query gap columns).
d
Funny. I've come across this too, and I solved it by removing the all-gap sequences. Your quote doesn't actually say what it does with sequences after throwing them out -- maybe it is supposed to abort?
One option might be to use the hmmsearch mode of the pipeline, i.e. have an hmm to select which sequences to pass to placement.
Now I found your quote in the documentation, and it does seem as if the tools should not abort but just continue quietly. Would perhaps be good if you issued a GitHub issue with a bit of example data?
a
I think indeed it was a different error that paused the overall process and it inputted by error that part, yes. Let me wait for the new run and I will be able to assure this.
OK so it seems that it appeared as an error because the total memory of the pipeline was misspecified (128 Gb vs my total of 125) and this created fast errors, prompting this output in the last one. It is weird because the query reads are reads that previously I have filtered with LAST (checking if they mapped to any sequences) and therefore they should have some kind of similarity to the sequences. Anyways, now it seems to be running smoothly. Let's see if it only happens to a small subset of samples or it happens to many of them. Thanks 🙂
d
Good!
a
it keeps getting errors there, and as you said, the premasking option should remove them. https://github.com/pierrebarbera/epa-ng/blob/1251dd43a6ae218bc5eb4c724f95374c015fb5ab/src/tree/Tiny_Tree.cpp#L183 Given that the amount of reads is pretty small, I could perhaps add the --no-premasking and this would remove the problems no.
at least now it throws an error and the workflow continues
d
Ok. If this turns out to be important and there's a flag we could add to the call we could expose this with a pipeline parameter
a
OK I let you know!