mimakaev
commented
4 years ago Hi,
I brief, we don't do fragment-based analyses anymore, as they are potentially misleading (more than just within-fragment reads need to be removed), and ill defined (fragments are not well-defined).
- As the field moves to shorter and shorter fragments (4-base cutters, combinations of 4-base cutters, microC), within-fragment reads become trickier to deal with.
- Fragments are often skipped in real life due to inefficient restriction. Especially with shorter fragments, it creates a lot of ambiguity: for many reads, one side of a read would frequently cross through an unrestricted restriction site. This in part pushed us to move away from fragments when inSitu Hi-C came out in 2014.
- We learned that often reads up to a few average fragment sizes need to be removed. We often end up removing reads up to 1-2kB for microC and up to 10-20kb for Hi-C. This is usually done at the analyses level. Most analyses in cooltools have an option to remove the first few diagonals, and this usually ends up being enough.
- Balancing by default removes first 2 diagonals. At 1kb base resolution, this ends up being 2kb, which is reasonable for micoC. At 10kb+ it is reasonable for 6-base-cutter Hi-C. Analyzing Hi-C done with a 6-base cutter at <10kb resolution is pointless anyways. So we always end up with the first couple diagonals removed from balancing. I note that they are outputted by cooler.matrix(); just they were omitted from the calculation of balancing weights. It is up to the user to omit them from downstream analyses. .
shenscore
Hi, I wonder how this pipeline deals with those mapped reads. Like, how this pipeline removes intra-fragment interactions without an enzyme option?