-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adapters trimming #16
Comments
How many adapters got removed, and how many not? AfterQC trims adapters for pair-end sequencing data based on searching for best overlap. But if there are too many sequencing errors, it will make AfterQC failed to find the overlap and consequently failed to trim adapters. Recording the adapter information in the report is a good idea, I will implement it in future release. |
multiqc report before any processing multiqc report after AfterQC Also quick question, what would happen if I run AfterQC again on good reads? |
If you run AfterQC with good reads, you should get every good read being kept. But you can have a try. |
From the figures you post, seems that the adapters those cannot be trimmed are at positions < 40, which means these DNA templates are shorter than 40? |
Yes, which is weird. The original paper says:
So, I'm not sure if they trimmed adapters. For me it is important to understand how AfterQC works, e.g. if what I got is expected, because of many sequencing errors, which makes AfterQC fail to find the overlap, and if it is advised to apply additional trimming after AfterQC in such case. |
It's not the major reason that sequencing error results in overlap detection failure, I think less than 1%. From the figure you post, the major reason is that the DNA templates are too short. AfterQC requires at least 30bp overlap to detect adapters, that's why the adapters under or near position 30 are not trimmed but the adapters beyond position are all trimmed. I am very curious why your sequencing library contains so many short fragments, I suspect that most of them may be self-ligased adapters. Did you perform fragment length selection after adapter ligation? |
I'm curious myself. It's not my article, I'm analyzing public dataset. Here is the article. Please, read the section "Shotgun library sequencing and quality control". But regarding sequencing protocol they reference one more article, so I'm unable to answer your question currently, need to read more. Additionally, here is sequence quality after AfterQC (raw is similar, but worse): |
Ok, seems the quality drop cycle by cycle is a bit serious, and there are two gaps... |
Yes, I thought that the gaps are bubble related. That's how I found AfterQC, because I googled the tool, which can correct that. But AfterQC didn't find anything. So I have no idea how those drops are generated. |
UPDATE. For NexteraXT transposon protocol when the insert is shorter than the length of a single read it results in the presence of adapter at the end of the read. Article, blog post, biostars post. But for metagenomics datasets I don't think we can identify read pairs with small insert sizes prior. I will try to play with fastqc report by increasing k-mer size and see if I can identify the issue by looking on k-mers (i.e. without knowing nextera adapters sequence). I think AfterQC can deal with this particular problem, but for that you either need to check against particular sequence or change the trimming algorithm somehow. But anyway just having adapters-related qc report would be great. I don't think that the tool should cover all the possible situations, but it should provide the user with information to see potential problems. |
As far as I understood you don't have predefined sequences for adapters:
"By searching the best overlapping of each pair, AfterQC automatically detects and cuts adapters for pair-end data, with no need of adapter sequence input"
I used AfterQC on metagenomics data and it seemed to reduce the numbers of adapters, but not entirely. What could be the cause? Also, what is important, I couldn't see it from the AfterQC report, I checked it with fastqc/multiqc, so from the user's point of view I would want to still see the validation for typical adapters in QC report.
Please, check the last post here - Sudden quality drop in the middle of HiSeq R1 reads but not in R2
If it is somehow beneficial for you I can send you full reports.
The text was updated successfully, but these errors were encountered: