Oncofusion

start / graph / absence-gse210480-processed-tracks-are-1-kb-binned

Analysisestablished confidence 5 of 5: Multiple independent lines of evidence; treated as settled in the field.Q108-h3k9me3-at-the-bcr

The resolution floor: every deposited H3K9 track in GSE210480 is 1,000 bp binned, so the 147 bp exon-11 question cannot be answered from the processed files - and the planned analysis that asked for 500 bp windows was asking for something that is not there

also called the 1 kb floor · why a 147 bp query returns a 1 kb answer · GSE210480's resolution, measured

The public files for this experiment average the signal over 1,000-base blocks. The piece of DNA the whole argument is about is 147 bases long. So the files can tell you about the neighbourhood but not the address, and the finer version of the question needs the raw sequencing reads instead.

The same thing, for a scientist

Every H3K9me1, H3K9me2 and H3K9me3 bigWig in GSE210480 has a **modal and median run length of exactly 1,000 bp**, measured by run-length encoding a 20 kb window in seven independent files [E1]. The CTCF bigWigs are **200 bp** [E1]. Three consequences, all of which bite on entries this graph already holds. **(1)** A query over Ensembl canonical exon 11 (147 bp) and a query over the CTCF summit +/- 250 bp (501 bp) return **byte-identical values** in every histone track, because both fall inside one bin - so no histone statement in this beat is finer than 1-2 kb, and the 147 bp figure in any such statement is decorative. **(2)** `ana-gse210480-h3k9me3-at-the-kmt2a-bcr` specifies *"the 8.3 kb KMT2A BCR in ~500 bp windows"* and *"read-level resolution over the locus, not the paper's 10 kb genome-wide bins"*. The 500 bp windows are **not obtainable** from the deposited files; the deposits sit at 1 kb, between the 500 bp that was wanted and the 10 kb that was feared. That entry's design is correct about what is needed and wrong about what is available. **(3)** The raw reads exist - every sample carries an SRA experiment accession (e.g. GSM6430988 -> SRX16821935) [E2] - so the finer analysis is possible but is an **alignment job**, not an interval-query job, which is a different cost tier from the one this graph has costed twice.

Go deeper
The measurement, and what it is a bound on

Run-length encoding of per-base values over hg19 chr11:118,350,000-118,370,000 (20 kb spanning the KMT2A BCR and its flanks) 1:

tracksamplemodal runmedian run
H3K9me1, main seriesGSM64309961,000 bp1,000
H3K9me2, main seriesGSM64309871,000 bp1,000
H3K9me3, main series, controlGSM64309881,000 bp1,000
H3K9me3, main series, siKDM3BGSM64310061,000 bp1,000
H3K9me1, exp1 seriesGSM75946901,000 bp1,000
CTCF, main seriesGSM6431023200 bp200
CTCF, exp1 seriesGSM7594700200 bp200

What this is a bound on, precisely. It bounds the deposited processed files, not the experiment. The submitters plainly had finer data - they deposited CTCF at 200 bp from the same pipeline - and the reads are in SRA. So this is a deposition limit, and it is the third distinct kind of limit this one dataset has presented to this graph: cycle 57 hit a tooling limit (pyBigWig would not build), cycle 58 removed it, and cycle 59 finds a resolution limit underneath that nobody had looked for.

Why it was not noticed until a number was computed. A 1 kb-binned track answers a 147 bp query without complaint. pybigtools returns 147 values, they are all real numbers, and their mean is a plausible fold-enrichment. Nothing errors. The only symptom is that two intervals of different widths return the same number - which is visible only if you query both, which happened here by accident because the design listed exon 11 and the summit window separately. Had the design listed only one of them, the 1 kb floor would have gone unrecorded and a 147 bp claim would have been published.

A related depth caveat from the same records. The library protocol states that 1 ng of DNA was the starting material and libraries were amplified with 14 PCR cycles 2. That is heavy amplification of a small input, so library complexity is a real concern for a broad-domain mark like H3K9me3 - and because the deposits are input-ratio tracks, neither read depth nor duplicate rate nor FRiP is recoverable from them. The only coverage proxy available is the NaN fraction, which is 0.0000 at the element in all 24 histone samples.

What closes the finer question, costed

Not compute-only, and not free. The route is: pull the 24 H3K9 ChIP runs plus their 8 inputs from SRA, align to hg38 (or hg19 and lift), and generate 100-200 bp coverage. That is 32 ChIP-seq libraries - tens of gigabytes of reads, an aligner, and a reference index. On this Windows host that is the wrong environment; on the Explorer cluster it is a single Slurm array job.

And it is worth asking whether it is worth doing. The question the finer resolution would answer is whether the H3K9me3 null at the element holds at 200 bp. Three considerations argue it is low priority. (a) H3K9me3 is a broad-domain mark; a 1 kb bin is close to its natural feature size, and a 200 bp readout of H3K9me3 buys much less than a 200 bp readout of a transcription-factor footprint would. (b) The null at the element is already 1% of the me1 response in log terms, and a resolution change would have to convert a 1.01x ratio into something large to matter. (c) The cell type is the binding constraint, not the resolution. Everything in this series is RPE. A 200 bp H3K9me3 track in retinal pigment epithelium still says nothing about a leukaemic blast, so spending the compute on resolution rather than on a haematopoietic cell would be optimising the wrong axis. This is therefore recorded as a bounded absence with the route named, not as a task.

Facts and figures
absence classmeasured-not-analysed
what is absentany sub-kilobase H3K9me1/2/3 readout at the KMT2A locus from the deposited processed files of GSE210480 - and therefore any histone claim in this graph that quotes a 147 bp or 500 bp interval as if it were resolved
what closes italign the 24 H3K9 ChIP runs plus 8 inputs from SRA to hg38 and generate 100-200 bp coverage. This is an ALIGNMENT job (32 libraries, an aligner, a reference index), not an interval-query job - a different cost tier from the 'compute only' and 'interval query' costings this graph has recorded in two previous cycles.
cost tiermed
recommended priorityLOW, and the reason is stated rather than implied: the binding constraint on this question is the cell type, not the resolution. Every sample in GSE210480 is RPE. A 200 bp H3K9me3 track in retinal pigment epithelium still licenses no statement about a leukaemic blast, so compute spent on resolution here would be optimising the wrong axis while the cell-type gap stays open.
archive check runtrue
archive queriedNCBI GEO per-sample records (acc.cgi form=text) for supplementary file inventory and SRA relations; the bigWig headers themselves for resolution
generalisable lessonA binned coverage track answers a finer query than it supports WITHOUT ERROR: it returns the right number of values, all real, with a plausible mean. The only cheap symptom is that two intervals of different widths return the same value, which is visible only if you query both. So: query a narrow interval AND a wide one containing it, or run-length encode a window, BEFORE quoting any interval narrower than a few kilobases from a processed track. Neither of this graph's two previous costings of this dataset checked the resolution, and both specified window sizes the files cannot deliver.
localizationchromatin; the bound concerns genomic resolution of a coverage file and not any cellular compartment
subnuclear localizationnot applicable - a file-format bound has no subnuclear coordinate, and none is claimed
cell typehTERT-immortalised human retinal pigment epithelial (RPE) cells - the only cell type in GSE210480, which is itself the reason this resolution gap is low priority
cell stateasynchronous proliferating culture 72 h after siRNA transfection
epigenetic readoutH3K9me1/2/3 and CTCF ChIP-over-input coverage; the finding is that the histone marks are deposited at 1 kb and CTCF at 200 bp
shown for fusionNot shown for any fusion. The dataset contains no fusion-bearing cell, and this entry concerns the resolution of its files rather than any biological claim about a fusion.
absence class noteMIGRATED 2026-09-23. This field previously held the whole verdict as free text: 'measured-not-analysed, with a newly measured RESOLUTION bound on what the processed deposit can answer'. That string was out of the controlled vocabulary, so a checker could not read it - but it said more than any token can, and it has been kept here rather than deleted. The original free text began with this token itself and then added 'with a newly measured RESOLUTION bound on what the processed deposit can answer' - a 1,000 bp bin against a 147 bp question. The bound is the part the vocabulary cannot carry.
what exists
{
  "histone_track_bin_bp": 1000,
  "ctcf_track_bin_bp": 200,
  "files_measured": 7,
  "window_measured": "hg19 chr11:118,350,000-118,370,000",
  "raw_reads": "in SRA; every sample is !Sample_type = SRA with an SRX accession (GSM6430988 -> SRX16821935)",
  "inputs_as_bigwig": "NONE - all eight Input samples have no supplementary file; the deposited tracks are already ChIP-over-input ratios"
}
How this could bite us back
  • This entry makes a null look better bounded than it is. Establishing that the resolution is 1 kb does not establish that a 1 kb readout is adequate; it establishes what was measured. A reader could take 'the floor is 1 kb and me3 is flat at 1 kb' as 'me3 is flat', when the honest statement is 'no me3 change is detectable at 1 kb with n = 2 in this cell type'.
  • Recommending LOW priority for the finer analysis is a judgement that could be wrong in one specific way: if the H3K9me3 change at this element were sharply localised to a few hundred base pairs at the CTCF motif itself, a 1 kb bin would average it into invisibility and the null published by this beat would be an artefact of the bin. That is exactly the scenario the low-priority recommendation declines to test.
Still open
  1. Does the H3K9me3 null at the KMT2A CTCF element survive at 200 bp? Answerable from SRA by alignment, at medium cost, and deliberately not recommended as a priority while every sample in the series is epithelial.
  2. How many other processed-track re-analyses in this corpus quote an interval narrower than the file's bin size? Nothing in this project has ever measured a deposited track's resolution before quoting a number from it, and the check is one run-length encoding per file.
  3. Would 14 PCR cycles on 1 ng of input support a 200 bp H3K9me3 readout even from the raw reads? Library complexity metrics are recoverable from the SRA runs and were not retrieved; if they are poor, the resolution ceiling belongs to the libraries rather than to the deposit.
Every source behind this entry (2)
  1. E1established confidence 5 of 5: Multiple independent lines of evidence; treated as settled in the field.dataset

    Run-length encoding of per-base values over a 20 kb window of hg19 chr11 gives a modal and median run of exactly 1,000 bp in five independently chosen H3K9me1/2/3 bigWigs from GSE210480 (main and exp1 series) and exactly 200 bp in two CTCF bigWigs from the same series; consequently a 147 bp query over Ensembl canonical exon 11 and a 501 bp query over the CTCF summit window return identical values in every histone track.

    GEO GSE210480 bigWigs run-length encoded over hg19 chr11:118,350,000-118,370,000 with pybigtools 0.3.0, 2026-09-22; code and output at analyses/q108-gse210480-h3k9me3-kmt2a-bcr/followups.py and results_followups.json · Gray ZH, Chakraborty D, Duttweiler RR, Alekbaeva GD, Murphy SE, Chetal K, Ji F, Ferman BI, Honer MA, Wang Z, Myers C, Sun R, Kaniskan HU, Toma MM, Bondarenko EA, Santoro JN, Miranda C, Dillingham ME, Tang R, Gozani O, Jin J, Skorski T, Duy C, Lee H, Sadreyev RI, Whetstine JR · NCBI GEO (data accompanying Cell 186:4528-4545.e18) 2023
    PMID 37788669DOI
    What this evidence cannot show

    Measured in one 20 kb window on chr11 in seven files, not genome-wide and not in all 40 tracks. A track could in principle be binned differently in other regions - deepTools does not do that, but it was not checked. The run-length method also cannot distinguish 'binned at 1 kb' from 'per-base values that happen to be constant across 1 kb', although the exact and repeated 1,000 and 200 values across independent files leave little doubt which it is. The identical-value consequence WAS observed directly and is not an inference: exon11_canonical and ctcf_summit_pm250 return the same fold value in all 24 histone samples in results.json.

    Evidence that argues against this (1)
    • A 1 kb bin may be the appropriate resolution for these marks rather than a defect. H3K9me3 in particular forms domains of tens to hundreds of kilobases, so 1 kb binning loses little biologically meaningful signal for me3 and the deposit may reflect a considered choice. The criticism lands hardest not on the depositors but on any re-analysis - including this graph's own planned one - that specifies a window size finer than the files support without checking. Iqbal Lab oncofusion knowledge graph 2026
  2. E2established confidence 5 of 5: Multiple independent lines of evidence; treated as settled in the field.dataset

    Every GSE210480 sample is !Sample_type = SRA with an SRA experiment accession and a BioSample (GSM6430988 -> SRX16821935, SAMN30127972), so the raw reads exist and a finer-resolution analysis is possible as an alignment job; the library protocol used 1 ng of starting DNA with 14 PCR amplification cycles on a NextSeq 500, and the eight Input samples carry no supplementary file at all.

    What this evidence cannot show

    The presence of an SRA accession establishes that a submission was made, not that the runs are complete, of adequate depth, or downloadable today. This project has previously found a well-formed, correctly named and EMPTY supplementary archive, and a SuperSeries that denied having raw data in three different ways, all three wrong - so the existence of SRX16821935 is a strong prior on feasibility and not a guarantee. Read counts per run were not retrieved.

    Evidence that argues against this (1)
    • 1 ng of input DNA with 14 cycles of PCR is heavy amplification, and for a broad-domain mark the resulting library complexity may not support a 200 bp readout even from the raw reads. So the alignment job could be run and still return 'the data cannot answer this at 200 bp' - which means the resolution limit recorded here might not be a deposition choice at all but the honest limit of the libraries. NCBI Gene Expression Omnibus 2026
Connected to