Bastien Chevreux wrote: > On Saturday 05 March 2011 16:17:43 Martin Mokrejs wrote: >> I haven't tested this for vector screening (large matches) but for 30nt >> adaptor smalt always crashed on my 32bit linux > > Switch to 64 bit. There is nowadays no compelling reason for 64 bit. > Especially not in the area of sequence assembly. > >> Hope you clarified that in the docs if one has to ask smalt to produce >> ssaha2-like format or if mira can use some other ... ;-) > > Yup. > >> [SSAHA2/SMALT] >> What will happen when the match regions are partially overlapping? Will >> their union be used, or the intersection? > > Union. Not prgramatically done, but simply because the same routines are > called once for the SSAHA2 file and once for SMALT. Which is a union in > effect. > > And of course, as in every clipping: rightmost leftlip and leftmost rightclip > will win. I don't see anything obvious in that logic, I expected that actually the leftmost leftclip wins. Is it documented somewhere in the Definitive guide? ;-) Does this apply to inconsistencies between XML traceinfo positions and positions derived from lower-cased FASTA sequences? Well, it makes sense to do the largest clipping defined ... instead of a minimal overlap, right. > >> What if there is no overlap between the two methods? > > Well, union still :-) > > But please do not built upon this behaviour ... I might very well remove it > in > the future when consolidating the code. Hmm, that's bad if it is going to be changed silently. Hope you document current approach and then document changes so that people know what is going on after they upgrade mira. ;) Thanks Martin > >> Yeah, the section in the docs about adapter >> clipping is also unclear, > > What there? Will do later. > > B. > -- You have received this mail because you are subscribed to the mira_talk mailing list. For information on how to subscribe or unsubscribe, please visit http://www.chevreux.org/mira_mailinglists.html