Understanding 9th field of Bam file - insert size?

Question

[a.rex]

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?

[Carambakaracho]

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 specs

[ATpoint]

Please use the formatting bar to highlight code and data examples for readablity.

Answer 1

[Pierre Lindenbaum]

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