-
Notifications
You must be signed in to change notification settings - Fork 142
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
Combining dada2 runs #716
Comments
After. Just make sure to trim each run to the same gene region (i.e. same
Probably after. You would only split before if you think the error process is different between the studies (perhaps because of different PCR protocols) as that is what matters to dada2. |
Thank you! What are the reasons/justification for processing the data in this order? Is the error rate estimation dependent on sequencing run? |
Yes it can be. If you are running your own samples on your own machine, probably the same run-to-run, but different machines can have different empirical relationships between the assigned quality scores and the error rates, hence it is recommended to learn the error rates on a run-by-run basis. |
I have a related question, in my case I'm looking to merge reads from three sequencing runs targeting the V4-V5 region. run 1 was 2x250 bp and had poor quality reverse reads. The other two runs were 2x150 bp. My approach is to use only the forward read of run 1 with truncLen = 240 bp. Then for the runs 2 and 3, I use trimLeft to get the merged reads to be right around 240 bp (most are at 240 bp, but there are a few (~100 sequence variants out of 11,000 in total) that are +/- 2 bp from 240). This leaves me with two questions:
The case that I've been thinking about is there may be two sequence variants that have exactly the same sequence for the 240 bp, but since one is 1 bp longer then it would be identified as a unique variant? |
Are you perhaps using the V4 region? V4V5 is longer than 300 nts, you won't get reads to merge at all.
I don't think you want to use
Sure, just truncate the reads in your sequence table:
That is true, but the |
yes, sorry this is the V4
I think I should clarify, I used trimLeft on the reverse reads to trim 13 bp (without trimming my merged lengths were 253, so by adding this trimming I get 240 bp merged reads, and if I'm following correctly I am trimming off the start of the reverse read so this would result in keeping the 240 bp that would correspond to the 240 bp lengths of the forward only reads from my run 1 and they would all start at the same place? However, maybe the better approach is to just merge the reads without trimming and truncate with substr as you mention above? Then perform collapseNoMismatch? |
I see, that is probably OK then. It doesn't fix everything though because there is length variation in the V4 locus (i.e. some biological V4 segments are e.g. 252 or 255 nts long).
That's probably what I would do. But you can probably just merge the data you already have and run |
Hi Ben @benjjneb , Although I have read your comments from different threads on combining the data from two different sequencing runs, I will really appreciate if you can clarify my following doubt: I have data from two different MiSeq runs and I understand that the pre-processing of these two runs should be carried out separately and merged later before the chimera removal step. I am concerned about the TruncLen function. As the quality profile for both these runs is different, I have to use a different TruncLen based on the quality for both these runs. My question is, is this difference still fine to proceed with the downstream analysis? (I have made sure that I use the same TrimLeft value for both, as the primers and targeted region is the same). Can you please let me know what would be a good option with some explanation. Thank you! |
It's fine to use different |
Thank you! I will proceed with truncating them as per the quality profiles for the specific run and will check if there is still a good overlap and that I receive a good amount of merged reads. |
Hi there, this thread has been quite helpful; but I have 2 follow up questions. (1) I work with microbial time series data so data is always streaming in and thus working with ASV's provides many advantages to having to re-cluster with OTU-based methods. so, thanks! but, with this, run quality varies among runs. so, i just want to confirm one quick thing. i gather from above that it is okay to use different (2). I have been using the QIIME2 implementation of dada2. I don't think the Would I need to change the OTUID column to something else? Thank you so much. I have been puzzling over this for a while and am happy to have found this thread! Colleen |
Regarding this question - i think i figured out that i need to covert the MD5 Hashes to actual sequences for the R implementation of dada2 and am testing some ways to do this in a streamlined manner in QIIME2.
Which I guess just leaves the first part of my question above remaining to be answered (to the degree that it can actually be answered). Thank you! colleen |
What I would strongly recommend is that you keep the same
|
That is an ugly dropoff in quality early in R2. Yes, it might be appropriate to enforce |
Okay. Thanks! And yes, frustrating and nastry dropoff indeed! But alas, since these samples are part of a time series, I don't want to drop the 600 samples from the dataset so I guess trimming is the only option short of resequencing.... Thanks again. I very much appreciate your thoughts (and validation of my intuition!). Colleen |
I still have some questions regarding merging different runs from dada2. Particularly, I am interested in understanding exactly why the same But then, since
If one would need to remove primers from run A but reads from run B would come with primers already removed, for example, using the same Thank you in advance!! |
@blancaverag I think you understand everything pretty well actually. For simple merging (i.e. using
Yep, you would just use it in the first case. When we say that
These kinds of details are why it's ideal to have ASVs already trimmed to span the same sequence region. I don't think that |
Dear @benjjneb, this is indeed a very useful thread, though I still have a follow-up question: Thanks so much for any help on this! |
Yes. Particularly before chimera removal, so as to make consistent chimera identifications across the batches.
More important is the fraction of reads in the shared ASVs. This should be much higher if the samples are indeed supposed to be very similar. |
Hi, This thread has been enormously helpful. However for unmerged ITS reads, the amplicon length is biologically variable, and even if the ASV's all start at the same position, "having ASV trimmed to span the same sequence region" seems to negate the directives of trimming to the same length of ITS reads. The ultimate goal is to use the collapseNoMismatch command to combine the ASV files. |
What you want is for, after truncation, the same biological sequence to results in the same sequencing reads. Two ways to do this -- truncate at a fixed position after the end of the forward primer, or truncate at the start of the reverse primer. For ITS data, especially forward read only data, you may need to do both because of the length variability in that locus, which will cause some reads to extend to the reverse primer while others do not reach it. One way to do this would be to truncate your 454/Illumina reads to a common length (maybe 250nts for everything, or less depending on where quality crashes), and then to do a second step in which you use an external program to remove the reverse primers from the ends of the reads (when they exist). Our ITS tutorial shows how to do that part with cutadapt: https://benjjneb.github.io/dada2/ITS_workflow.html |
Hi Ben, Thanks greatly for this explanation. Sorry to belabor the point, but could you explain why collapseNoMismatch dosen't perform as well if the amplicons are of different lengths, and/or the ASV are derived from a slightly different coding region? |
|
I have output from multiple sequencing runs that I want to analyze together, and some data from the same sequencing runs that I want to analyze separately. So my questions are:
The text was updated successfully, but these errors were encountered: