tobiasrausch
commented
3 years ago For a reference-guided trace assembly, the reference determines the alignment direction and the traces are aligned in decreasing order of alignment quality (e.g., best trace first). For a reference-free (so-called de novo) assembly, tracy doesn't parse the filenames for "forward" or "reverse" so all traces are treated equally and of course, tracy allows >2 input traces. The final direction solely depends on the multiple-sequence alignment guide tree constructed from pairwise profile alignment scores. I guess what other tools do here is to simply flag one input trace as the proper direction and of course, the same could be done in tracy and then exposed as an input field in Pearl. That hasn't been implemented but it's something to consider in the future.
kaldari
sebkopf
I suspect this is a bug in Tracy rather than Pearl, but Pearl is where I see it manifested. Sometimes when I have Pearl analyze a pair of ab1 trace files, it incorrectly assigns the forward sequence as reverse and the reverse sequence as forward, leading to a consensus sequence that is the reverse compliment of the true sequence. I'll attach two trace files that cause this problem. Note that these are actual high quality trace files of DNA barcodes for insects, which is a fairly standard application for a trace assembler. It's a bit mysterious that Pearl/Tracy doesn't let you manually assign the forward and reverse directions for the traces, as this is standard in all other trace assemblers I've used. I'm curious how you're automatically assigning the directions. traces.zip