I am trying to process some 454 titanium data of an ITS analysis (just a few steps via mothur). Basically I have data to denoise and when I run trim.flows all the reads/flows get scrapped for length (and b and f) and in the scrap file the flowgram lengths are around 20-200 (while the actual reads range between 30 and ~1200bp). The flow order is A and the flowgram files have the number 1779 at the top (instead of 800). I am unsure why the flowgrams are getting scrapped and the scrapped ones are shorter than the original. I have tried trim.seqs with the same oligos file and it works perfectly (so the barcodes and primer seqs are OK).
Is this a bug? I’m using the most recent version of mothur for OSX, 1.32.1
I have emailed my fasta, flow, qual and oligos file to mothur.bugs
Hi, I recently had a similar problem. From what I gathered from the sequencing platform, that’s due to the FLX + “technologies”. Instead of producing 200flows per nucleotides resulting in 800flows, it does 400flows per nucleotides, so a total of 1600. It has been “improved” to get longer reads. Also there is some starting flows which are responsible to delay the beginning of the reads (your barcode and primer arrive later than usually, that explain why they are not found). There are also some “washing” flows at the end of the reads. Those both kind of flows explain why you get more than 1600flows. I think the length problem is due to the fact that the LookUp files is designed for 800flows and no more (like the other one is for 450) but I’m not sure of that. I guess that a LookUp files for about 1600 flows could solved that (I also had 1779flows, but I don’t know if it is a standard for FLX + technology).
Edit: I tried the order B (after posting, I apologize about that), and it solves the problem. Thanks a lot for that ^^