[mira_talk] RE Re: RE Re: convert_project behaviour when iterative mapping assembly
- From: Jorge.DUARTE@xxxxxxxxxxxx
- To: mira_talk@xxxxxxxxxxxxx
- Date: Tue, 24 Nov 2009 09:31:08 +0100
Hi Bastien,
I reduced the folowing exple to a few contigs in order to faciliate your
tests and to be able to send it by e-mail,
you should find in the archive 4 files : exple_out.caf, exple_6x.caf,
new_out.caf and new_6x.caf
From the initial de novo assembled 16 contigs and 162 reads
(exple_out.caf), convert_project extracts 5 contigs and 105 reads with 6x
coverage at least.
Giving these 5 contigs as backbone to 43 new reads (including reads
assembled in contigs with less than 6x coverage in first de novo assembly)
in a mapping assembly, results in adding 41 reads to the assembly
(new_out.caf), but when i use again convert_project, it results in only
one contig
beeing extracted (new_6x.caf).
Hope this is clear,
jorge.
mira_talk-bounce@xxxxxxxxxxxxx a écrit sur 23/11/2009 22:33:31 :
> On Montag 23 November 2009 Jorge.DUARTE@xxxxxxxxxxxx wrote:
> > [...]
> > Here is what happens in more details:
> > [...]
>
> Eeeek? That does not look normal.
>
> Could you please put somewhere on a server
> a) the first CAF (8051 contigs, 111k reads)
> b) the second CAF (2451 contigs + the new 6k/7k mapped reads)
>
> I'll have a look at what happens.
>
> > Looking at the different caf files, i can't understand what makes
these
> > contigs selected compared to others,
> > apart from the fact that the mapped reads increased their coverage by
> > 6-fold, which makes me wonder where
> > and how this information is stored in the caf format !?..
>
> Coverage is not stored explicitly in the CAF, it must be recomputed by
> convert_project when loading.
>
> Regards,
> Bastien
>
> --
> 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
Other related posts:
