BamGenotypeCheck

LaneCheck

Basic Usage Example

Here is an example of how laneCheck works:

  lanecheck  --referencegenome NCBI36.fa --dbSNPfile dbSNP.txt \
            --lanefile lane.lst --pedfile test.ped --datfile test.dat --mapfile test.map --prefix result

Command Line Options

Input Files

--referencegenome referencegenome file
--dbSNPfile       optional dbsnp position file, will provide more accurate background mismatch rate if excluding dbSNP positions
--lanefile        a list of lane file with path
--pedfile         genotype information of the samples for checking 
--datfile         a companion data file for pedigree file (each row: M snpname, e.g. M rs1234)
--mapfile         a companion data file for pedigree file (each row: chr snpname pos, e.g. 5 rs1234 56789)

Basic Output Options

--prefix specify the prefix name of the output file

Filtering 

--minmapquality   reads with with mapquality falling below this threshold will be excluded
--genocount       the maximum number of genotypes compared 
--verbose         print out detailed information for each hapmap position compared
--coverage        print out the proportion of markers in the map file covered by at least one read 
--countbysite     print out detailed mismatch counts for each base compared

Other Options

--memorymap use memory map technique for efficient memory sharing of reference genome file

Principle of operation:

The overall procedure is that the genotype identity checking program compares internal evidence from the sequence reads themselves to reference genotype information for a panel of candidate individuals. In the case of 1000 Genomes pilot data, these are HapMap genotypes from the same Coriell cell lines that are being sequenced. For each combination of [sequencing run x candidate individual] the program calculates the observed rate of mismatches at both "informative" and "background" locations and reports as "excess mismatch rate"

           excess rate  =  (informative rate  -  background rate).

"Informative" locations are those where the candidate individual is homozygous, according to the HapMap genotype information, and base calls are compared to the HapMap homozygous allele, rather than to the genome reference sequence. "Background" locations are all sites not known to be polymorphic and not recorded in dbSNP.

TODO

Frequently, we will want to run lane checking on a mapped .bam file which already contains sequence data from many different instrument runs merged together. They are merged because the sequencing center said they all belong to the same individual. In Pilot 3, this was true for all of the Baylor LS 454 sequencing data. In this case, the read identifier in column 1 of the .sam file carries information about which sequencing run each read belongs to, as well as information that uniquely identifies that read within its run. The read identifiers often are dot or colon-separated strings of the form 'run_name<sep>read_number'. The 'run_name' may be either an SRR / ERR identifier or the sequencing center's own alpha-numeric internal run identifier.

The "Read group classifier" is an extended regular expression such as '\(^[^.:]+\)[.:].*' which matches just the part of each read identifier that is common to all reads from one instrument run and which differs between instrument runs. The regular expression is passed into the lane checking program as an ascii string. The program keeps track of all distinct values it has seen for the matched portion, and must keep a separate tally of matches and mismatches for each combination of [read group x candidate individual]. By itself, the matched portion of each read identifier does not fully specify which original .fastq file a read came from. The 'bitwise flag' value in column 2 of the .sam format has the remaining information. This is able to distinguish between the 'left end', 'right end' and 'single end' reads which come from each Illumina paired-end sequencing run. The Baylor LS 454 data were all single end reads, so I did not have to deal with this complication.