Hi Kristin, On Mon, 2010-09-06 at 19:44 -0700, Kirstin Hanks wrote: > Hi, > > > I'm looking at the backbone file from a progressive mauve alignment in > an excel spreadsheet, doing a bit of a "sanity check" on my data. I've > noticed that there are some aligned regions which seem bizarrely > short, as short as 2 bp, it seems like these should have been removed > by the step of the algorithm which removes insignificant matches?
The presence of some extremely short backbone fragments is normal when analyzing 3 or more genomes and results from the way progressiveMauve infers the boundaries of backbone regions. This is not a bug, although one might argue that it's a deficiency in the way backbone regions are delineated. When progressiveMauve identifies backbone regions, it does so by examining the alignment of each pair of genomes individually. That is to say, backbone regions are predicted in a pairwise fashion for all pairs of genomes. For each pair of genomes in turn, the full multiple genome alignment is projected to an alignment for just that pair by by temporarily ignoring the other genomes. Then gaps in that pairwise alignment larger than some fixed value (defaults to 20) are considered "non-backbone" and the backbone is everything else. Thus, backbone consists of regions where the pair do not have any gaps larger than 20nt. Backbone is identified in each pair of genomes, and then predictions from each pair are merged into a consistent set of backbone predictions for the entire set of genomes. This allows the transitive identification of backbone regions, e.g. if genomes A and C are too homologous but too diverged to recognize the backbone, and genome B is an intermediate, the aligner may identify backbone shared by A and B, and also B and C, and then by merging identify the backbone shared by A and C. The downside of the merging procedure is that sometimes the boundaries of the backbone regions are predicted slightly differently in each pairwise prediction. In our 3 genome example, the backbone between B and C might extend slightly beyond that identified among A and B. In that case, a long backbone segment shared by A,B,C will be neighbored by a tiny segment shared by only B and C. The small extra regions get broken up into individual backbone pieces, often just a few nt long, and this is what you observed. One might argue that these should really be merged into the neighboring backbone region which is often both longer and higher-multiplicity. Depending on what you are trying to do with the backbone file, it may be safe to discard the small regions. > > Also, do the negative numbers in the backbone file just mean the > co-ordinates are on the reverse strand? I can't think of anything else > they could mean, but i can't find anywhere that states this > explicitly. > Yes, that is exactly what it means. That notational convention is used in many of the output files generated by Mauve and is defined in the Mauve user guide, but not in the section which discusses the backbone file format. Regards, -Aaron ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ Mauve-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mauve-users
