{"action":"created","issue":{"url":"https://api.github.com/repos/charite/Q/issues/5","labels_url":"https://api.github.com/repos/charite/Q/issues/5/labels{/name}","comments_url":"https://api.github.com/repos/charite/Q/issues/5/comments","events_url":"https://api.github.com/repos/charite/Q/issues/5/events","html_url":"https://github.com/charite/Q/issues/5","id":106715906,"number":5,"title":"Find no enriched regions","user":{"login":"MosheOlshansky","id":11751374,"avatar_url":"https://avatars.githubusercontent.com/u/11751374?v=3","gravatar_id":"","url":"https://api.github.com/users/MosheOlshansky","html_url":"https://github.com/MosheOlshansky","followers_url":"https://api.github.com/users/MosheOlshansky/followers","following_url":"https://api.github.com/users/MosheOlshansky/following{/other_user}","gists_url":"https://api.github.com/users/MosheOlshansky/gists{/gist_id}","starred_url":"https://api.github.com/users/MosheOlshansky/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/MosheOlshansky/subscriptions","organizations_url":"https://api.github.com/users/MosheOlshansky/orgs","repos_url":"https://api.github.com/users/MosheOlshansky/repos","events_url":"https://api.github.com/users/MosheOlshansky/events{/privacy}","received_events_url":"https://api.github.com/users/MosheOlshansky/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":2,"created_at":"2015-09-16T07:30:28Z","updated_at":"2015-09-17T08:16:02Z","closed_at":null,"body":"Hi,\r\n\r\nI ran Q on two data sets. For one of them I got results which may be reasonable (I need to look at the details) but for the other one (which is actually a much better quality data) I got no peaks at all. If I run Q with default options it estimates the average fragment length to be 1 (it prints 2^32+1)  but even when I provided the average fragment length it still has not found a single peak (even though there are hundreds of very reliable ones). The original data was paired ends and I thought that this could have created the problem (even though I do not know why) so I kept only the first mate in every pair (and so the strand is random) but it did not help.\r\nAny idea why this happens (and is there any way to avoid this)? I can upload my file (and control - it makes no difference).\r\n\r\nThank you in advance,\r\nMoshe."},"comment":{"url":"https://api.github.com/repos/charite/Q/issues/comments/141000128","html_url":"https://github.com/charite/Q/issues/5#issuecomment-141000128","issue_url":"https://api.github.com/repos/charite/Q/issues/5","id":141000128,"user":{"login":"hansenp","id":10495485,"avatar_url":"https://avatars.githubusercontent.com/u/10495485?v=3","gravatar_id":"","url":"https://api.github.com/users/hansenp","html_url":"https://github.com/hansenp","followers_url":"https://api.github.com/users/hansenp/followers","following_url":"https://api.github.com/users/hansenp/following{/other_user}","gists_url":"https://api.github.com/users/hansenp/gists{/gist_id}","starred_url":"https://api.github.com/users/hansenp/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/hansenp/subscriptions","organizations_url":"https://api.github.com/users/hansenp/orgs","repos_url":"https://api.github.com/users/hansenp/repos","events_url":"https://api.github.com/users/hansenp/events{/privacy}","received_events_url":"https://api.github.com/users/hansenp/received_events","type":"User","site_admin":false},"created_at":"2015-09-17T08:16:02Z","updated_at":"2015-09-17T08:16:02Z","body":"\"Q works both when I keep only the first mate in each pair or both mates. To me it looks like it works better when I keep both mates - I am getting fewer significant peaks and this better fits the biology.\"\r\n\r\nI think this is because you have twice the data if you keep both mates. There is no reason to discard the second mate and I would keep both.\r\n\r\n\"I also ran it with and without -k option. Once again, in my particular case it looks like I get better results with -k option. To be honest I do not understand the meaning of this option: if your statistic is based on the number of occupied positions, why does it matter if the duplicates are kept or not?\"\r\n\r\nThe '--keep-duplicate' option should not directly affect the evaluation of predicted binding sites, but indirectly. If you keep the duplicates the qfrags coverage profile will be different and therefore the positions of the predicted binding positions may be different to some extend and also the number of saturated positions in the immediate vicinity. \r\n\r\n\"My other question is about the reasonable cutoff, i.e. what would be the reasonable cutoff after which the peaks are not considered reliable and should it be based on p/q - value or saturation score or both?\"\r\n\r\np- and q-values depend on the different null models they are based on (and on how the background of the particular datasets fit the null model). Null models are different for different peak callers and a predefined cutoff will always be kind of arbitrary. A generally accepted solotion to adress this issue is the framwork of the Irreproducible Discovery Rate (IDR) which was/is extensively used during the ENCODE project and is also discussed in the Q paper.\r\n\r\n\"Finally, when Q knows to accept paired end data, one obvious thing would be to use actual fragments lengths to estimate mean length and variation.\"\r\n\r\nAn automatically generated plot showing the real distribution of fragment length derived from the propper mapped pair would be really a nice feature and I will try to add it as soon as I can.\r\n\r\n\"But my question is whether you can do more, i.e. instead of extending each 3' position by the average fragment length you can extend it by it's exact length which you know. How would you define qfrags in such case? You can also try to compute your statistic based on the number of distinct fragments (and not 3' positions). It may be harder than the simple occupancy model but I think that it is doable. You definitely can estimate the distribution of fragments length and approximate it by some convenient distribution if needed. What do you think?\"\r\n\r\nMinor correction: 5' ends are extended towards 3' direction. I also think that the paired-end information could be exploited for prediction and evaluation of peaks, but this would be a different interesting project. I do not have a quick answer on the question if qfrags would be useful for an approach specially designed for paire-end data.\r\n\r\nThank you for your interest and interesting suggestions.\r\n\r\nBest,\r\nPeter"}}