Hi,
Right now our team is working on a prokaryotic genome assembly generated on a Illumina MiSeq sequencer. We are currently using SPAdes and IDBA_Hybrid for assembly of the reads into contigs. At the first time we don't tell the programs to choose a specific kmer size, after the assembly we ran a quality check of it with Quast, after choosing the best kmer size we run another assembly but now indicating the kmers sizes close to the kmer size that generated the best assembly the first time. The problem is that when we run an assembly with the same kmer chosen by the software the first time, the results are different, some metrics change drastically, usually worst than the first assembly with the same kmer size. Why does this happen? The only parameters changed are the kmers sizes when compared to the first assembly, and somehow this is enough to make a different contig list. Could someone help me understand why does this happen and how can a replicate the first assembly on second run?
Thank you all for the attention
Hi Gustavo Manoel Teixeira ,
This could be possible for different reasons.
The first could be the high amount of the repetitive regions in your genome (like higher GC content).
Second, the quality trimming of Illumina adapters and low quality bases.
Third, the other parameters chosen (careful option, cov-cutoff, etc...).
Can you provide additional informations?
For example:
The average read lenght;
Which tool did you used to trim the raw data;
Which is the expected coverage;
Which is the expected GC%.
Maybe if you check the contig fasta files from the two assemblies you will see that the contigs less than 500 bp are contigs with a high GC% and very high coverage. Can you confirm this?
All the best
Salvatore
In your reproducing attempts, are you always starting with the absolute raw data, which has not been processed in any way?
Salvatore La China
The average read lenght of the raw data is about 300 pb, after trimming with Trimmomatic 0.39 the average decreased to 170/180 pb, the quality of the sequencing wasn't the best possible
The expected GC% according to the repport made on FastQC is around 48/49%
I couldn't find which was the expected coverage for the whole sequencing
For the contigs with less than 500 pb there aren't any patterns with the GC% content and coverage values.
Thanks for the help
Abhijeet Singh
All data was trimmed before procceding to the assembly proccess with Trommomatic 0.39
Hi Gustavo Manoel Teixeira ,
which k-mers lenght did you used?
In your case i would suggest you to use a k-mer size of 27,33,55,77 (based on your read lenghts). In addition, i suggest you to use the --careful option and the --cov-cutoff 100 option.
After assembly, i suggest you to check the contigs less than 500bp.
The name of contigs that usually SPAdes assigns to each contig reports the coverage (Node_*_lenght_*_cov*...). That coverage is referred to the coverage of K-mers. Usually when it is more higher than the contigs whit lenght > 1000 bp, that contigs is abundant GC content. In that case you should reduce the --cov-cutoff option.
I hope that this is helpfull
All the best
Thank you Salvatore La China I'll try new assemblies with your recommendations and also the --careful pipeline option activated, since the manual recommend using with small genomes
You're welcome Gustavo Manoel Teixeira , please let me know if the settings works for you.
All the best
- Badges
- Science method
- Similar topics
- Mathematics
- Statistics
- Statistical Techniques
- Meta-Analysis