Huge drop in reads after pre-processing #314
Replies: 3 comments
-
Hi @idalarsson, Thanks for using CRISPResso and sorry to hear that you are having trouble! Through looking at the log you attached (thank you for that!) it does look like FLASH is having trouble merging your reads, FLASH was only able to merge 0.54% of your reads. It looks like many of your reads (63.61%) have an overlap >100bp, which is the default maximum overlap. See the following warning from FLASH.
If you would like to change this parameter via CRISPResso, you can add the |
Beta Was this translation helpful? Give feedback.
-
Hi @idalarsson from your running log it appears that your amplicon is 506bp long. How long are your reads? Do you expect to see overlap between your R1 and R2 reads? If so, your R1 and R2 needed to be at least 250bp sequencing. If you sequenced with standard 100/150bp sequencing, flash will be unable to merge your reads for this amplicon because there is no overlap between R1 and R2. Does that make sense? |
Beta Was this translation helpful? Give feedback.
-
Thank you both @Colelyman and @kclem for the quick response! My reads are 250 bp, so my first thought was that they are too short to have overlap for this particular amplicon. However, after posting this issue I also noticed the warning from Flash regarding the overlap being >100 bp, which really confused me. I tried increasing that parameter to both max overlap 200 and 300 but with the same result. I don't really know what to conclude from this, but it seems like an issue outside of CRISPResso. Thank you for your input though! |
Beta Was this translation helpful? Give feedback.
-
I'm running CRISPResso and noticed that there is a huge drop in reads that pass pre-processing. I'm trying to troubleshoot the entire setup and was wondering if you have any input on where the problem most likely is.
The fastq-file contains reads from 9 different conditions (target KD, NT, WT x 3), so my first step before running CRISPResso was to demultiplex the fastq-file. For one of the targets, the output is as expected with ~ 98 % reads kept after pre-processing. For the other two targets, the no of reads passing pre-processing drops and ranges from ~30% best case and 0.5 % worst case. If running CRISPResso on the original fastq-file the no of reads passing pre-processing is 22 %.
I found this post #118 and suspect that the issue lies in that FLASH is unable to merge my reads (?) but I can't understand why. Anyone experience something similar or have any clue to if and how I can fix this?
I'm attaching the log from the run where only 0.5 % of reads are kept after pre-processing.
CRISPResso_RUNNING_LOG.txt
Beta Was this translation helpful? Give feedback.
All reactions