empty mutation results - varscan +- samtools

[GoogleCodeExporter]

If you label a lane as "illumina" when it is really "sanger", the 
copy_uncompress fastq step can sometimes not see the fastqc log file that 
automatically checks the quality encoding.  This results in the scores being 
shifted from #J to !+, which in turn causes mutation callers to fail to find 
any mutations.  SAMtools still reported indels for the test case.

copy_uncompress_fastq_read1.log 2012-10-12 11:54:15,194 - root - WARNING - 
Could not locate FASTQC data to determine encoding, using value illumina found 
in XML
2012-10-12 11:54:15,194 - root - INFO - Copying and converting FASTQ files with 
quality scores in illumina format
2012-10-12 12:26:59,156 - root - DEBUG - Processed 59273105 fragments

copy_uncompress_fastq_read1.log 
2012-10-11 08:40:29,008 - root - WARNING - Auto-detected FASTQ format sanger 
differs from XML file (illumina)
2012-10-11 08:40:29,008 - root - INFO - Copying and converting FASTQ files with 
quality scores in sanger format
2012-10-11 08:46:16,212 - root - DEBUG - Processed 48578911 fragments

temporary fix - do not enter the quality encoding incorrectly

Original issue reported on code.google.com by Veene...@gmail.com on 4 Nov 2012 at 11:38

[GoogleCodeExporter]

nb - we believe this may be caused by a pbs job dependency issue

Original comment by Veene...@gmail.com on 4 Nov 2012 at 11:40

[GoogleCodeExporter]

I believe this will be fixed in version 0.3.0 and above for several reasons. 
First, quality scores are now auto-detected and users no longer label them. 
Second, PBS job dependencies have been eliminated in this version. We may give 
users an option to run the pipeline with a PBS job dependency chain in 
subsequent versions.

Original comment by matthew....@gmail.com on 10 Feb 2013 at 6:31

• Changed state: Fixed