You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We're currently evaluating an update from version 0.9.9 to 0.9.10. However, we're seeing some increased noise among the ratios and resulting in an increased rate of false positives. Specifically, looking at the IQRs:
We've traced it back to this commit; I noticed that the window fraction now defaults to a limit of 0.01 (from the flat 0.1). Could this be under-correcting the log2 ratios during the fix step?
It could be under-correcting for GC and repeats overall. My aim in that commit was to improve performance on bins with extreme GC, where e.g. Picard showed there was still a correlation between GC content and coverage depth, by using a smaller window where there were enough data points. You have better benchmarking datasets on hand than I do at this point, so if you're seeing a deterioration, then I hope your PR gets you back to where you need to be.
I'm also curious if you find the original 10% was optimal or another window size is even better on today's data.
We're currently evaluating an update from version 0.9.9 to 0.9.10. However, we're seeing some increased noise among the ratios and resulting in an increased rate of false positives. Specifically, looking at the IQRs:
We've traced it back to this commit; I noticed that the window fraction now defaults to a limit of 0.01 (from the flat 0.1). Could this be under-correcting the log2 ratios during the
fix
step?I've opened up a PR to allow manual tuning of this parameter during the
fix
step: #860The text was updated successfully, but these errors were encountered: