runCA is giving me errors about invalid QVs in an Illumina fastq file. I checked the file with fastqAnalyze and it's Illumina 1.8+. The -type parameter I used for fastqToCA was illumina. Reads are 101bp.
I have, once, seen an Illumina file that had a QV one higher than the spec allowed. I wonder if this is another one like that.
Does fastqAnalyze -stats report anything odd?
Are there any error messages to either the screen or files (*errorLog is likely)? I would expect that 'gatekeeper' is logging the invalid QV somewhere.
I don't deal with Illumina reads much anymore. Surely there is something out there what will clean up and/or analyze the QVs. As a last resort, we could make a code change to allow (fix, really) the bad QVs.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't see anything odd when I run fastqAnalyze -stats.
I'm attaching a file with some info from the error files. Almost every read has at least one invalid QV. I included the first two reads from the fq file - the error log reports 10 and 8 invalid QVs.
After looking at the QVs more and doing some research, I came across some changes that were made to Casava 1.8. The fastq quality score encoding now uses the standard offset value of 33 rather than the previous Illumina specific offset value of 64. I'm going to change the -type parameter for fastqToCA to sanger and see if that works.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have, once, seen an Illumina file that had a QV one higher than the spec allowed. I wonder if this is another one like that.
Does fastqAnalyze -stats report anything odd?
Are there any error messages to either the screen or files (*errorLog is likely)? I would expect that 'gatekeeper' is logging the invalid QV somewhere.
I don't deal with Illumina reads much anymore. Surely there is something out there what will clean up and/or analyze the QVs. As a last resort, we could make a code change to allow (fix, really) the bad QVs.
I don't see anything odd when I run fastqAnalyze -stats.
I'm attaching a file with some info from the error files. Almost every read has at least one invalid QV. I included the first two reads from the fq file - the error log reports 10 and 8 invalid QVs.
Last edit: Jessica Hill 2015-11-30
After looking at the QVs more and doing some research, I came across some changes that were made to Casava 1.8. The fastq quality score encoding now uses the standard offset value of 33 rather than the previous Illumina specific offset value of 64. I'm going to change the -type parameter for fastqToCA to sanger and see if that works.