{"action":"created","issue":{"url":"https://api.github.com/repos/broadinstitute/picard/issues/103","labels_url":"https://api.github.com/repos/broadinstitute/picard/issues/103/labels{/name}","comments_url":"https://api.github.com/repos/broadinstitute/picard/issues/103/comments","events_url":"https://api.github.com/repos/broadinstitute/picard/issues/103/events","html_url":"https://github.com/broadinstitute/picard/issues/103","id":47521501,"number":103,"title":"CollectInsertSizeMetrics infers incorrect PairOrientation","user":{"login":"d-cameron","id":6036536,"avatar_url":"https://avatars.githubusercontent.com/u/6036536?v=3","gravatar_id":"","url":"https://api.github.com/users/d-cameron","html_url":"https://github.com/d-cameron","followers_url":"https://api.github.com/users/d-cameron/followers","following_url":"https://api.github.com/users/d-cameron/following{/other_user}","gists_url":"https://api.github.com/users/d-cameron/gists{/gist_id}","starred_url":"https://api.github.com/users/d-cameron/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/d-cameron/subscriptions","organizations_url":"https://api.github.com/users/d-cameron/orgs","repos_url":"https://api.github.com/users/d-cameron/repos","events_url":"https://api.github.com/users/d-cameron/events{/privacy}","received_events_url":"https://api.github.com/users/d-cameron/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/broadinstitute/picard/labels/1%20-%20Ready","name":"1 - Ready","color":"CCCCCC"},{"url":"https://api.github.com/repos/broadinstitute/picard/labels/secon","name":"secon","color":"bfe5bf"},{"url":"https://api.github.com/repos/broadinstitute/picard/labels/user","name":"user","color":"009800"}],"state":"open","locked":false,"assignee":{"login":"yfarjoun","id":2745554,"avatar_url":"https://avatars.githubusercontent.com/u/2745554?v=3","gravatar_id":"","url":"https://api.github.com/users/yfarjoun","html_url":"https://github.com/yfarjoun","followers_url":"https://api.github.com/users/yfarjoun/followers","following_url":"https://api.github.com/users/yfarjoun/following{/other_user}","gists_url":"https://api.github.com/users/yfarjoun/gists{/gist_id}","starred_url":"https://api.github.com/users/yfarjoun/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/yfarjoun/subscriptions","organizations_url":"https://api.github.com/users/yfarjoun/orgs","repos_url":"https://api.github.com/users/yfarjoun/repos","events_url":"https://api.github.com/users/yfarjoun/events{/privacy}","received_events_url":"https://api.github.com/users/yfarjoun/received_events","type":"User","site_admin":false},"milestone":null,"comments":16,"created_at":"2014-11-01T23:52:42Z","updated_at":"2015-07-17T18:35:31Z","closed_at":null,"body":"CollectInsertSizeMetrics infers incorrect the PairOrientation (RF, should be FR) of a library when the average fragment size of is less than read length, local alignment is used, and adapter sequences are not removed. The majority of reads map to the same position, with a significant number mapping in what appears to the RF orientation due to reference and adapter microhomology at the aligned position.\r\n\r\nThe pair orientation returned by CollectInsertSizeMetrics should reflect the FR orientation of the library prep and sequencing.\r\n\r\n<!---\r\n@huboard:{\"order\":122.0,\"milestone_order\":103,\"custom_state\":\"\"}\n-->\r\n"},"comment":{"url":"https://api.github.com/repos/broadinstitute/picard/issues/comments/122368539","html_url":"https://github.com/broadinstitute/picard/issues/103#issuecomment-122368539","issue_url":"https://api.github.com/repos/broadinstitute/picard/issues/103","id":122368539,"user":{"login":"nenewell","id":11997929,"avatar_url":"https://avatars.githubusercontent.com/u/11997929?v=3","gravatar_id":"","url":"https://api.github.com/users/nenewell","html_url":"https://github.com/nenewell","followers_url":"https://api.github.com/users/nenewell/followers","following_url":"https://api.github.com/users/nenewell/following{/other_user}","gists_url":"https://api.github.com/users/nenewell/gists{/gist_id}","starred_url":"https://api.github.com/users/nenewell/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/nenewell/subscriptions","organizations_url":"https://api.github.com/users/nenewell/orgs","repos_url":"https://api.github.com/users/nenewell/repos","events_url":"https://api.github.com/users/nenewell/events{/privacy}","received_events_url":"https://api.github.com/users/nenewell/received_events","type":"User","site_admin":false},"created_at":"2015-07-17T18:35:31Z","updated_at":"2015-07-17T18:35:31Z","body":"After a quick reboot on this, this is the situation as I recall it: these reads are indeed unambiguously FR by the FR/RF definition based on the relative positions of the 5' ends. The problem is that the pair orientation caller calls many of these reads as RF. This happens because the caller routine relies on the FLAG and TLEN, and the sign of TLEN is ambiguous in the SAM spec for reads that completely overlap each other, because it is determined based on which of the reads is \"leftmost\" and which is \"rightmost\", instead of the relative 5' positions. \r\n\r\nThe changes I'm suggesting remove the dependence of pair orientation calling on TLEN in CollectInsertSizeMetrics, because if the reverse read of every pair is chosen during pair evaluation instead of the second read, then TLEN is not needed to determine orientation, since the 5' position of the reverse read is immediately available as getAlignmentEnd(), and the 5' position of the mate (the forward read) is immediately available as getMateAlignmentStart(). So the code in GetPairOrientation(), which currently does a computation relying on TLEN,  is simplified and the 5' end-based definition of FR/RF is strictly enforced regardless of TLEN."}}