Looking at QScore plot, it seems that you get somewhat nice data until the quality drops at a certain cycle (hard to say what cycle due to image resolution). I'd assume that your library is very short (probably only primer dimers) and once the machine is finished reading through the (short) template it makes random noise, giving low quality base-calls (thus the bad data quality histogram). The indexing might be off too, but I think this is less of an issue at this point... I'd suggest to run FastQC and look for overrepresented sequences and whether those are your primer/adaptor sequences.

Cluster density seems fine. With the sharp drop off in sequence quality after a certain number of cycles, my guess is that your library has too little sequence diversity in that region of the amplicon.

Adding to the explanation above, it is seen (based on experiment/experience) the sequencing quality drops quite much if the sample has too few amplicons (may be due to the low concentration of sample in pool or due to the sample type).

In recent experience in our lab, we found the primer type effect the sequencing results very much and especially the reverse primer mess the quality. Additionally the bacterial primers are better than archaeal primers, in which (archaeal primers) the quality of reverse reads drops even worse than the bacterial primers.

In our lab @Tong Liu has extensive experience in sequencing data analysis and he found out that it is somehow a technical fault in the laser detection in Illumina platform.

Moreover, please mention what kind of primers and target is. It would help in resolving the issue. And I assume with 16S rRNA you actually mean the sequencing of 16S rDNA gene (V3-V4 region).

Thank you Peter, Mark and Abhijeet for your valuable inputs.

@Peter, The drop is Q30 score starts from 41st cycle and then continuously decreasing. Libraries are not short, since 11 samples have been randomly choose to run on Bioanalyzer were of exact 630 bases as per illumina standard v3-v4 region of 16s-rRNA gene. I have run fastqc to check for over-represented sequences and I do not find primer dimers for a few of fastq-files checked. I am attaching the fastqc result screenshot for your reference.

@Mark, v3-v4 region of 16s-Amplicons do have little variability but not purely identical. Illumina already has optimized these primers for sequencing of these v3-v4 region and around 180 bases of read-1 fall within v3 region of 16s-rRNA. meanwhile i look for fastq files for over-representation of sequences of primer-dimers in those samples for whom % read-representation in overall reads are high.

@Abhijeet, Thanks a lot for your expert comments based upon your personal experiences. I am looking if over-represented samples have any issue with their libraries and it may take some time to investigate them in details. In this case, read-1 performance was quite similar as read-2, it was an overall effect on data quality. Since the primers are standard primers as per illumina recommendations, i can rule out primer specific effect on data quality for now. For MiSeq there using LED instead of LASER so I can not comment on your this section of suggestions.

Thanks all again for your feedback and looking to hear more suggestion.

Best,

Amit

@Amit. Nice that you did not see the bad quality issue in your reverse read, you were lucky in your case. Nevertheless, it has been an extensive discussion over the internet regarding the bad quality of reverse reads. Excuse me for the laser, but with laser I meant detection system. Moreover, even Illumina and sequencing company have experienced similar issue and came up with a possible explanation about the detection system which is mentioned earlier. Furthermore, another explanation they suggested was the polymerase problem. This was just to give explanation over your comment.

Now moving to the issue, I would again recommend you to check the samples for discrepancies. And Illumina has nothing to do with primer optimisation. It just the barcoding which they provide the suggestion for primers. Another thing worth mentioning, you still haven't processed the sequences for quality check, in that step you will realise the quality difference in forward and reverse reads. It seems like if your quality is falling around 180bp for forward reads, it will be much more you will find in later step(ofcourse depends what pipeline you are using). If you are sticking to MiSeq protocol from Illumina dont go for greengenes. It has many faults and wrong submissions. But that comes later, first you have to deal with the technical problems of your 16S rDNA or 16SrRNA gene run.

Thanks Abhijeet for the comments.

I agree with your comments fully. I have escalated the case to tech support to look if there could be lot issue. Also I find that around 4 M reads out of 16 M reads were found to be undermined. Although the quality was good for index reads, these proportion of reads were could not be allocated to samples. Do you think, it is common.

regarding Analysis, which tools, pipeline and database you prefer. In my case when there is low quality issue at 3' end of reads, is there any software would you recommend which can be used to stitch and align the PE-reads.

Thank you Abhijeet.

"these proportion of reads were could not be allocated to samples" - do you actually mean samples of taxonomy ?

Right Now, we are using the DADA2 pipeline which consider the individual sequence variance instead of the concept of OTUs. It is pretty good to handle the data and correct errors. i would recommend you to use this, since you are dealing with the reads which could have more errors, so choosing the improved pipeline would be a wise choice. If there reverse reads more problematic, you could try the single read approach, its better than using bad quality overlaps. Regarding the database, I would say Silva_database which is almost best at the moment.

Try this if you get any satisfactory results, since we can not do anything with the data we have on hand regarding what went wrong in the sequencing run.

Hi Abhijeet,

"these proportion of reads were could not be allocated to samples" - means for these fastq reads were not determined to assign with any of the samples. I suspect there could be some issue with the reagent or system. Techsupport has asked me for volume check.

In this situation, if i were you, I would first confirm if the barcoding was right or what was wrong in pooling/sequencing/dereplicatiing the sequencing raw data. It would be useless to proceed with the data if 25% of the reads is just unknown. I would strongly recommend not to use this data for any analysis as it could not be trusted. Please try to troubleshoot with the sequencing company.

Thanks Abhijeet for your suggestions...

Amit

Amit Chaurasia I have experienced almost the same problem in a recent experiment. The quality just drop at cycle 100-150, although expected library size was 630 bp, as checked before sequencing. Have you received any explanation from tech support? Could you fix the problem?

Thannk you