Hello Veranja,
Either process is fine - in one you are dividing the groups based on a single match to one end of the pair, in the other based on two independent matches, one to each end of the pair. So the first is less stringent, the second more so. If there are differences in the final result, then this is likely due to sequence quality. If you know the quality is better at the 5' end or vice-versa, then splitting on that single end only might simplify things, but this is your call. A tool like "FastQC" can be useful when assessing quality.
Using the joiner tool is one way to quickly synch the files (and discard unmatched parts of pairs). You could also use identifiers as I suggested before. But, this is often not necessary. Instead, many people will go forward with mapping and filter for properly paired mapped data after the alignment step. Our team doesn't recommend a workflow that involves using a join/split method to synch paired inputs prior to mapping (mainly to reduce unnecessary processing/disk space usage, not because it is harmful).
Others are welcome to add additional comments/feedback to this thread.
Best wishes for your project,
Jen Galaxy team
On 4/24/13 3:04 PM, Veranja Liyanapathirana wrote:
Dear Galaxy team I am so sorry for repeatedly posting the same question, but I do need some inputs in to this. Please let mek now the best way to use barcode splitter on Paired end Miseq data. The data is already split for the Illumina indexes using Miseq reporter, what I want to do is to split some inhouse barcodes within each of the sample. Barcodes are there in both 5' and 3' end but they are both the same. Please let me know if the best practise is to
- Join read 1 and two - barcode split and split the two reads
- Split Read 1 and 2 and them join using FastQ joiner and split again
Basically I want to exclude any reads where the same numbered reads are not categorised in to the same barcode. Thanks Kind Regards, Veranja Veranja Liyanapathirana Graduate student Microbiology, CUHK
The Galaxy User list should be used for the discussion of Galaxy analysis and other features on the public server at usegalaxy.org. Please keep all replies on the list by using "reply all" in your mail client. For discussion of local Galaxy instances and the Galaxy source code, please use the Galaxy Development list:
http://lists.bx.psu.edu/listinfo/galaxy-dev
To manage your subscriptions to this and other Galaxy lists, please use the interface at:
To search Galaxy mailing lists use the unified search at: