I took a look at the directionality output, and spotted a CRE (chr10_100185675_100186176_+) which had ~200 negative strand reads and ~25 positive strand reads. Intrigued, I delved into the various intermediate files to investigate. Apparently two filtered clusters (chr10_100185889_100186059_- and chr10_100186073_100186094_+) fall within the annotated CRE's range, but rather than get merged they translate to separate, overlapping CREs (the other one becomes chr10_100185928_100186429_-).
My best guess as to why the two weren't merged is that all the .-oriented CREs in the output have a typeStr of unanno_tss and a gene_promoter of none or unannotated. Meanwhile chr10_100185928_100186429_- is gene_tss and annotated respectively. chr10_100185675_100186176_+ is unanno_tss and none, but I presume the strandedness conflict is keeping it unmerged. I see instances of gene_tsses and unanno_tsses merged, but the standedness agrees.
Nevertheless, the end result is a pair of overlapping CREs that then cause confusion in directionality. Would it make sense to somehow refine annotate coordinate extension to avoid these sort of situations from occurring? Or does the solution lie elsewhere?
Some other musings that may be useful to whoever's reading:
- I had a ton of CREs with very small scores as a result of the default directionality performed in the 10X workflow. Passing the filtered cluster file as
--ctss_scope_bed_path made unidirectional a lot more prevalent. This obviously did nothing in the case discussed above, but still felt worth noting.
- The
count function explicitly uses the +/-/. strandedness stored within the name (and BED) of the CRE. This whole thing was brought on by me thinking if there's a way to propagate the directionality information to a per-cell level, filtering the CB.ctss.bed to +/- respectively, running individual count calls, and then finding the overlap in features captured to be the . CREs exclusively. As is, count and directionality tell you different things.
I took a look at the directionality output, and spotted a CRE (
chr10_100185675_100186176_+) which had ~200 negative strand reads and ~25 positive strand reads. Intrigued, I delved into the various intermediate files to investigate. Apparently two filtered clusters (chr10_100185889_100186059_-andchr10_100186073_100186094_+) fall within the annotated CRE's range, but rather than get merged they translate to separate, overlapping CREs (the other one becomeschr10_100185928_100186429_-).My best guess as to why the two weren't merged is that all the
.-oriented CREs in the output have atypeStrofunanno_tssand agene_promoterofnoneorunannotated. Meanwhilechr10_100185928_100186429_-isgene_tssandannotatedrespectively.chr10_100185675_100186176_+isunanno_tssandnone, but I presume the strandedness conflict is keeping it unmerged. I see instances ofgene_tsses andunanno_tsses merged, but the standedness agrees.Nevertheless, the end result is a pair of overlapping CREs that then cause confusion in
directionality. Would it make sense to somehow refineannotatecoordinate extension to avoid these sort of situations from occurring? Or does the solution lie elsewhere?Some other musings that may be useful to whoever's reading:
--ctss_scope_bed_pathmade unidirectional a lot more prevalent. This obviously did nothing in the case discussed above, but still felt worth noting.countfunction explicitly uses the+/-/.strandedness stored within the name (and BED) of the CRE. This whole thing was brought on by me thinking if there's a way to propagate the directionality information to a per-cell level, filtering theCB.ctss.bedto+/-respectively, running individualcountcalls, and then finding the overlap in features captured to be the.CREs exclusively. As is,countanddirectionalitytell you different things.