Seqanswers Leaderboard Ad

Collapse

Announcement

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

  • Assembly with a single library always fail?

    I'm trying to assemble a ~70M genome from a single Illumina PE library (100nt read, 160M each end, insert size=300bp).
    I've tried velvet, Abyss, and SOAPdenovo with K=75. The largest N50 is 2kb, with at least 77k contigs.

    My questions are:

    1. Generally does one have to use at least two libraries (one shorter insert and one longer insert) to get good assembly?

    2. When I only have one short read library like this, how can I get the best assembly? (a rough question I know. What I want to know is any tips in the parameter tuning? or any preprocessing?)

    3. It seems that SOAPdenovo always give me worst results with very small N50. But publication suggests this is a good assembler for large genome. I don't know if I did something wrong.

    4. The reported coverage is about 50X, with genome size estimated to be ~70M. But if I calculate the coverage from my reads, it would be 160M x 2 x 100/70M = ~400x. How can it be decreased to 50x? Well, fastqc did show that there is high duplication level in the raw reads (>70%). Could this be the reason?

    Here are my commands and results from each assembler:

    1. velvet: (N50=2k, #contigs=77k, reported coverage=50X)
    Code:
    velveth Sample_name 75 -shortPaired -fastq Sample_R1R2_rmdp_trimmed_SOAPec.fastq
    velvetg Sample_name -cov_cutoff auto -ins_length 300 -exp_cov auto
    2. Abyss: (Contig N50=2k, # contigs=460k; Scaffold N50=4k, #=400k)
    Code:
    abyss-pe n=10 name=Sample_k75 k=75 j=8 in='Sample_R1_rmdp_trimmed.fastq.cor.pair_1.fq Sample_R2_rmdp_trimmed.fastq.cor.pair_2.fq'
    3. SOAPdenovo: (Contig N50=170bp; Scaffold N50=300bp, #=47k)
    Code:
    SOAPdenovo-127mer all -s SOAPdenovo.config -K 75 -R -f -p 8 -F -V -o Sample_k75
    Before assembly, I did preprocessing:
    1. Use fastuniq to remove duplicates
    2. Use fastq-mcf to remove adapter seqs and trim low quality ends
    3. Use SOAPec to error correct the reads:
    Code:
    KmerFreq_HA -k 27 -f 1 -t 10 -L 101 -l fastqlistforSOAPec.lst -p Sample_k27
    Corrector_HA -k 27 -l 2 -e 1 -w 1 -q 30 -r 45 -t 10 -j 1 -Q 33 -o 1 Sample_k27.freq.gz fastqlistforSOAPec.lst
    I know assembly is quite case-dependent and I'm asking quite open questions. But any suggestions would be highly appreciated! Thanks!
    Last edited by metheuse; 11-27-2013, 08:26 AM.

  • #2
    A long insert library is definitely going to help your assembly. As for the library you have, picking one kmer size and fixing the library insert size may be suboptimal. You could try running preqc from SGA, see https://github.com/jts/sga/wiki/preqc, this can tll you a lot about your data. You may have gotten a library with a different insert size than you thought, for example. Also, try velvetOptimizer, part of velvet, to hget optimal settings for this program. I don't know enough about to other programs to be able to help you.

    Comment


    • #3
      Have you tried Ray? This looks like the sort of thing it was designed for.

      I find the coverage strange also. Your effective coverage should be much higher with a paired-end sequencing run. Perhaps there are so many duplicated errors that it is confusing the assembly process, and it's calculating an average read separation of 50bp rather than 300bp. Have you tried it out with a random subsample of your reads (say 20-40M)?

      Comment


      • #4
        Originally posted by metheuse View Post

        4. The reported coverage is about 50X, with genome size estimated to be ~70M. But if I calculate the coverage from my reads, it would be 160M x 2 x 100/70M = ~400x. How can it be decreased to 50x? Well, fastqc did show that there is high duplication level in the raw reads (>70%). Could this be the reason?
        velvet calculates coverage as kmer coverage, the formula is in the velvet manual, so that would account for some of the difference between what you calculated and what velvet reports.

        I find that the coverage velvet reports seems to be calculated on the number of reads it uses in the assembly, rather than the total number of reads.

        The last line in the Log file after running velvetg gives the number of reads used in the assembly.

        Comment


        • #5
          Originally posted by flxlex View Post
          A long insert library is definitely going to help your assembly. As for the library you have, picking one kmer size and fixing the library insert size may be suboptimal. You could try running preqc from SGA, see https://github.com/jts/sga/wiki/preqc, this can tll you a lot about your data. You may have gotten a library with a different insert size than you thought, for example. Also, try velvetOptimizer, part of velvet, to hget optimal settings for this program. I don't know enough about to other programs to be able to help you.
          Thanks a lot! I'll take a look at SGA and velvetOptimizer.

          Comment


          • #6
            Originally posted by gringer View Post
            Have you tried Ray? This looks like the sort of thing it was designed for.

            I find the coverage strange also. Your effective coverage should be much higher with a paired-end sequencing run. Perhaps there are so many duplicated errors that it is confusing the assembly process, and it's calculating an average read separation of 50bp rather than 300bp. Have you tried it out with a random subsample of your reads (say 20-40M)?
            Thanks! I'll take a look at Ray.
            I didn't try with random subsamples? Would that help?

            Comment


            • #7
              Originally posted by mastal View Post
              velvet calculates coverage as kmer coverage, the formula is in the velvet manual, so that would account for some of the difference between what you calculated and what velvet reports.

              I find that the coverage velvet reports seems to be calculated on the number of reads it uses in the assembly, rather than the total number of reads.

              The last line in the Log file after running velvetg gives the number of reads used in the assembly.
              Thanks! It used 85% of the input reads, so still it can't explain the coverage difference.

              Comment


              • #8
                Originally posted by metheuse View Post
                I didn't try with random subsamples? Would that help?
                It will reduce the number of random errors that appear multiple times. You could alternatively use the kmer-based error correction of SGA, but I'm not sure that SGA will work so well with 100bp reads.

                Comment


                • #9
                  Thanks a lot for all your replies above. I'm currently trying velvetoptimizer and SGA on the data.

                  Besides, I have another question:
                  Do I have to choose the same Kmer size for error correction and assembly? I was using SOAPec which allows up to 27 as k-mer size, but I wanted to use k=75 in assembly. Would this difference matter?
                  Thanks.

                  Comment


                  • #10
                    Do I have to choose the same Kmer size for error correction and assembly?
                    No, they are separate independent functions.

                    Comment


                    • #11
                      I've had pretty good results using SPAdes. Comparing my velvet runs against SPAdes from common files is pretty night and day.

                      An additional long-insert library might be helpful, especially if you've got an organism known to have lots of repetitive genome.

                      Comment

                      Latest Articles

                      Collapse

                      • seqadmin
                        Exploring the Dynamics of the Tumor Microenvironment
                        by seqadmin




                        The complexity of cancer is clearly demonstrated in the diverse ecosystem of the tumor microenvironment (TME). The TME is made up of numerous cell types and its development begins with the changes that happen during oncogenesis. “Genomic mutations, copy number changes, epigenetic alterations, and alternative gene expression occur to varying degrees within the affected tumor cells,” explained Andrea O’Hara, Ph.D., Strategic Technical Specialist at Azenta. “As...
                        07-08-2024, 03:19 PM
                      • seqadmin
                        Exploring Human Diversity Through Large-Scale Omics
                        by seqadmin


                        In 2003, researchers from the Human Genome Project (HGP) announced the most comprehensive genome to date1. Although the genome wasn’t fully completed until nearly 20 years later2, numerous large-scale projects, such as the International HapMap Project and 1000 Genomes Project, continued the HGP's work, capturing extensive variation and genomic diversity within humans. Recently, newer initiatives have significantly increased in scale and expanded beyond genomics, offering a more detailed...
                        06-25-2024, 06:43 AM

                      ad_right_rmr

                      Collapse

                      News

                      Collapse

                      Topics Statistics Last Post
                      Started by seqadmin, 07-16-2024, 05:49 AM
                      0 responses
                      22 views
                      0 likes
                      Last Post seqadmin  
                      Started by seqadmin, 07-15-2024, 06:53 AM
                      0 responses
                      30 views
                      0 likes
                      Last Post seqadmin  
                      Started by seqadmin, 07-10-2024, 07:30 AM
                      0 responses
                      40 views
                      0 likes
                      Last Post seqadmin  
                      Started by seqadmin, 07-03-2024, 09:45 AM
                      0 responses
                      205 views
                      0 likes
                      Last Post seqadmin  
                      Working...
                      X