Header Leaderboard Ad

Collapse

BFAST indexing for 50+36 SOLiD paired end?

Collapse

Announcement

Collapse
No announcement yet.
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • BFAST indexing for 50+36 SOLiD paired end?

    The BFAST manual gives one set of recommended seeds for reads <40 bp and one for greater than 40 bp

    What if I have a SOLiD paired end dataset with one read above that threshold (50) and one below (35)? Suggestions?

  • #2
    Tried bfast+bwa (latest release)?

    Comment


    • #3
      Originally posted by krobison View Post
      The BFAST manual gives one set of recommended seeds for reads <40 bp and one for greater than 40 bp

      What if I have a SOLiD paired end dataset with one read above that threshold (50) and one below (35)? Suggestions?
      Those keys will work fine for 35bp reads. You'll get a small decrease in the total number of alignments compared to 50bp reads. You could also explore
      bfast+bwa branch and use bwaaln for the second tag.
      -drd

      Comment


      • #4
        Thanks -- I've just started trying to figure out bfast+bwa & the new options it gives

        Comment


        • #5
          In this thread I posted my experience with this kind of PE reads:
          http://seqanswers.com/forums/showthread.php?t=7100
          BFAST postprocess seems to rescue a lot of the 35 bp ends that did not get a match with bwaaln. (The bwaaln step might profit from allowing more mismatches instead of the default, but as I found with BWA on SOliD data that slows it down considerably.)
          Note that the git version of postprocess is an improvement over the one in the bfast+bwa package but still has a bug.
          Maybe it's because of the rather low quality of my data that the localalign step is now the most time-consuming part: 50 Mio read pairs on 8 CPUs usually take 70 h, some almost double the time. Multithreading is not that efficient that I'd want to use 16 threads (other people also want to use the cluster). I'm currently experimenting with the parameters.

          Comment


          • #6
            @epigen: Take a look to this.
            -drd

            Comment


            • #7
              Thanks for the link, but I tried that before and it is not helping: far too many reads do not get paired. This patch is what I mean with the git version of postprocess, which does help (in terms of speedup and pairing, unfortunately with a bug):
              http://sourceforge.net/mailarchive/m...mail.gmail.com

              Comment

              Working...
              X