The parameter bestn for blasr in the template XML protocol is set to 1 and I found in other threads that a lot of people use that value.
But if my reference data consists of scaffolds I want to assemble using PacBio long reads, bestn 1 should not work to achieve this, should it?
So lets say I know that I have two scaffolds which can be "glued together" by several reads. The reads should then be mapped to both scaffolds and therefore mapped twice. So bestn 1 would not cover this.
Or is PBJelly checking if a read that maps e.g. at the end of one scaffold with a huge overlap also maps at the beginning of an other scaffold in the gapfilling step (or at an other point)?
And if I use a bestn > 1, is PBJelly able to use every multiple mapped read only once for the final result?
If I should use bestn 1, please tell me why (:
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The latter.
You only want to use a read once in an assembly. We then trim unmapped
tails and give them a chance to span. The 2nd Bestn mapping could be a
subsequence of the first
On Jan 13, 2017 6:50 AM, Cornelia Mühlich blackfirefly@users.sf.net wrote:
The parameter bestn for blasr in the template XML protocol is set to 1 and
I found in other threads that a lot of people use that value.
But if my reference data consists of scaffolds I want to assemble using
PacBio long reads, bestn 1 should not work to achieve this, should it?
So lets say I know that I have two scaffolds which can be "glued together"
by several reads. The reads should then be mapped to both scaffolds and
therefore mapped twice. So bestn 1 would not cover this.
Or is PBJelly checking if a read that maps e.g. at the end of one scaffold
with a huge overlap also maps at the beginning of an other scaffold in the
gapfilling step (or at an other point)?
And if I use a bestn > 1, is PBJelly able to use every multiple mapped read
only once for the final result?
The parameter bestn for blasr in the template XML protocol is set to 1 and I found in other threads that a lot of people use that value.
But if my reference data consists of scaffolds I want to assemble using PacBio long reads, bestn 1 should not work to achieve this, should it?
So lets say I know that I have two scaffolds which can be "glued together" by several reads. The reads should then be mapped to both scaffolds and therefore mapped twice. So bestn 1 would not cover this.
Or is PBJelly checking if a read that maps e.g. at the end of one scaffold with a huge overlap also maps at the beginning of an other scaffold in the gapfilling step (or at an other point)?
And if I use a bestn > 1, is PBJelly able to use every multiple mapped read only once for the final result?
If I should use bestn 1, please tell me why (:
The latter.
You only want to use a read once in an assembly. We then trim unmapped
tails and give them a chance to span. The 2nd Bestn mapping could be a
subsequence of the first
On Jan 13, 2017 6:50 AM, Cornelia Mühlich blackfirefly@users.sf.net wrote:
The parameter bestn for blasr in the template XML protocol is set to 1 and
I found in other threads that a lot of people use that value.
But if my reference data consists of scaffolds I want to assemble using
PacBio long reads, bestn 1 should not work to achieve this, should it?
So lets say I know that I have two scaffolds which can be "glued together"
by several reads. The reads should then be mapped to both scaffolds and
therefore mapped twice. So bestn 1 would not cover this.
Or is PBJelly checking if a read that maps e.g. at the end of one scaffold
with a huge overlap also maps at the beginning of an other scaffold in the
gapfilling step (or at an other point)?
And if I use a bestn > 1, is PBJelly able to use every multiple mapped read
only once for the final result?
If I should use bestn 1, please tell me why (:
Confusion about bestn parameter
https://sourceforge.net/p/pb-jelly/discussion/general/thread/968cbb6c/?limit=25#44d9
Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/pb-jelly/discussion/general/
To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/
Thank you for your answer. That's really good to know!