Thanks for the suggestions. Investigating these issues take some time for me, since I'm still in the process of implementing tools for whole genome analysis and any recommendations on useful tools are welcome. Nevertheless, I have BLASTed some of the LCB-junctions and noted that the assembly differences involve genes with one or more homologs in completed genomes (e.g. glutamate carboxylase, putative phage regulatory protein, 5S rRNA, transposase insK,.). Concerning the question of rearrangements between contigs or within contigs, it seems that the rearrangements involve both types, and that the LCB-end that harbors a gene with homologs are linked to "between contigs".
Jan ______________________ Hi Jan, Based on your description, the issue lies with VelvetOptimiser, not Mauve. The two read sets resulted in assembly differences which were then detected by Mauve. My guess is that the assembly differences / rearrangements correlate with repeats in the genome (rRNA operons, IS elements). Guy Plunkett III On 10/9/13, Söderman Jan wrote: >Hi, > >In order to get acquainted with Mauve I have generated two different sets of >reads from a single set of E. coli WGS data. My expectation was that >Progressive Mauve (after applying Contig Mover relative a completed and >related genome) should have been able to produce LCBs without rearrangements, >since the two sets only differ with respect to quality trimming of the reads. >However, using the default settings, Progressive Mauve generates a number of >rearrangements and two LCBs in the reverse orientation. By significantly >increasing the Min LCB weight (to >180k) I'm able to reduce the number of >rearrangements. Nevertheless, one rearrangement persists. Neither does the use >of different seeds solve this problem. Similar results are also obtained using >the contigs of one set of reads as a reference (in Contig Mover) for the other >set of contigs. How do I produce confident alignments of reads originating >from different E. coli isolates, given this difficulty in aligning contigs >originating from the same sequencing event? > >The two sets of reads contained a similar number of paired-end reads (2*945k >vs. 2*904k) of high quality scores according to FastQC. VelvetOptimiser >produced 146 contigs from the first set of reads (n50 = 169k, longest contig >422k) and 159 contigs from the second set (n50 = 162k, longest contig = 268k). > >I'm grateful for any input on this matter. > >Sincerely, > >Jan Söderman > >------------------------------------------------------------------------------ >October Webinars: Code for Performance >Free Intel webinars can help you accelerate application performance. >Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from >the latest Intel processors and coprocessors. See abstracts and register > >http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk >_______________________________________________ >Mauve-users mailing list >Mauve-users@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/mauve-users ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk _______________________________________________ Mauve-users mailing list Mauve-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mauve-users
