[mira_talk] Re: Getting observed insert size etc for paired end reads
- From: Alan Tsang <alantsangmb@xxxxxxxxx>
- To: mira_talk@xxxxxxxxxxxxx
- Date: Fri, 14 Feb 2014 10:58:33 +0800
Hello Bastien,
I am using mira 4.0 right now.
And I am making an assembly setting the template_size = 100 2000 autorefine
and segment_placement = ---> <---
After all, the result maf file just report the template_size same as my
input manifest file:
@Version 2 0
@Program MIRALIB
@ReadGroup
@RG name SomeHiseqReadsIGotFromTheLab
@RG ID 1
@RG technology Solexa
@RG strainname Monkey
@RG templatesize 100 2000
@RG segmentplacement FR
@RG segmentnaming solexa
@EndReadGroup
How can I know the templatesize after refine? Thanks.
Alan
2014-02-13 18:32 GMT+08:00 Bastien Chevreux <bach@xxxxxxxxxxxx>:
> > On February 13, 2014 at 10:48 AM Peter Cock <p.j.a.cock@xxxxxxxxxxxxxx>
> wrote:
> > [...]
> > Those are the predictions for each of the five passes - settling down to
> a mean
> > template size of approx 230, standard deviation 114, skew 0.77, min 24,
> max 480.
> >
> > However, the MAF header seems to have the min/max from the first pass
> (22, 515),
> > is that an error?
>
> Yes. And no, it currently depends a bit on your manifest file.
>
> If the segment_placement is not known, MIRA determines the placement in
> the first pass and the size in the second pass. If you gave the placement
> (other than "unknown") as parameter in the manifest, then the size is
> directly determined in the first pass. Though maybe I should change that as
> first pass assemblies are a bit of a "warm-up" and can include quite some
> misassemblies. That's more of a problem for large libraries I think, though
> I need to ponder about this whether I should not push that to second pass
> per default.
>
> Size predictions from subsequent passes however are ignored on purpose as
> MIRA will have used the previous predictions to place reads and thus have
> rejected a couple of pairs which fell outside the prediction. If one
> recalculates predictions on that, the results will be ever shrinking ranges
> which is not what you want.
>
> B.
>
>
Other related posts:
