Understanding 9th field of Bam file - insert size?
I have a pair of reads that look like this:
SRR8441376.13963941 69 g4_1 558410 0 * = 558410 0 GTATAATCTAATTGTTCATGATGGAATTCATATTGTTCAATTGCGTTATTATAATTACTTAGTTGCTTAATTTG AAAAAEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEAEEEEEEEEEEEEEEEEEEE<EEEEEEEEEEEEEEEE YT:Z:UP
SRR8441376.13963941 153 g4_1 558410 0 74M = 558410 0 TATAATTACTTAGTTGCTTAATTTGATTTTTCGTCGTTGCATAACTGTGAGGATTTAATTCTGCCGTGTAGCGT EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEAEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEAAAAA AS:i:-15 XS:i:-20 XN:i:0 XM:i:3 XO:i:0 XG:i:0 NM:i:3 MD:Z:28C23G18T2 YT:Z:UP
The insert size looks likes its zero? When I use Picard Tools insert metrics will this be zero? Does this not account for the size of the read?
1 answer
http://broadinstitute.github.io/picard/explain-flags.html flag 69: the read is UNMAPPED while the mate is mapped. Therefore, there is no 'fragment' size
• 0 views
•
link
written
by
Pierre Lindenbaum
Log in to answer this question.
More posts like this
-
Duplicate reads remain in bam after picard MarkDuplicates --REMOVE_DUPLICATES true
written by kalavattam •
-
No cell barcode information in BAM files.
written by bill •
-
Consensus deduplication issues with non-matching/'slippy' primers?
written by graeme.thorn
-
bowtie2 '-a' does not return all alignments
written by shim •
-
Bowtie paired-end alignment failure
written by hadasbaer •
-
Bowtie2 aligner not generating .sam file.
written by Ramana •
-
I can not see BAM file in IGV
written by Michel Edwar
-
bowtie2 output only valid alignments
written by ddzhangzz
-
Problem about Samtools Mpileup
written by wangyang703092
-
Perplexing Bowtie 2 results
written by Rob
you're formatting is unreadable, there's
=""inserted everywhere in the second read. Other than that insert size is the distance between first and second read and not encoded in any field -> see specsPlease use the formatting bar to highlight code and data examples for readablity.