Compute: which backend for which piece of phase-2 work, and the one constraint that matters for each
also called compute plan · backend matching · where to run it
The lab has several places to run computations: a university supercomputer, pay-as-you-go cloud GPUs, Boltz credits, and free notebooks that shut themselves off when idle. Each suits a different kind of job, and picking wrong usually means a long run dies halfway through.
The same thing, for a scientist
Almost none of the phase-2 work in this beat needs a GPU, and saying so is the useful finding. The dataset pulls, the ChEMBL and gnomAD censuses, the DepMap re-derivations, the cohort arithmetic and the breakpoint coverage calculation all run on a laptop in minutes. Three things need real compute: local AlphaFold-class prediction of KMT2A fragments (because the public database has no model), Boltz co-folding campaigns (credits, not cluster time), and any de novo binder design against the LEDGF IBD if it is ever approved. The governing constraint is not throughput, it is **session length**: hosted notebooks have idle and maximum-runtime limits that kill long jobs, which is why anything running more than an hour belongs on Slurm or Modal.
The matching table
| Work | Backend | The constraint that matters |
|---|---|---|
| DepMap, GTEx, HPA, cBioPortal, ChEMBL, gnomAD, RCSB pulls | Laptop | Network flakiness and polite rate-limiting, not compute. Every script needs retry with backoff, as the existing analyses/ scripts already do. |
| Co-dependency and lineage-conditioned re-derivations | Laptop | None. These already run in minutes on 1,250 lines. |
| Cohort arithmetic, hazard fitting, breakpoint coverage | Laptop | None. The binding constraint is data access, not compute. |
| Boltz co-folding campaigns 1-5 | Boltz credits | Credits refresh monthly; campaigns 1-5 are small. Run the positive controls in the first days of a credit month so a failure leaves time to recover. |
| Boltz design triage (campaign 6) | Boltz credits | This is the only campaign that can exhaust a month's credits. Gate it behind the LEDGF G2 experimental result. |
| Local KMT2A fragment structure prediction | Explorer Slurm GPU | Request the GPU through the scheduler, never run on the login node. KMT2A is 3,969 aa; fragment-wise jobs are short but MSA generation is the slow step and is CPU-bound. |
| De novo binder design, if approved | Explorer Slurm GPU | Long, multi-hour, restartable. This is the one job class that genuinely needs a cluster allocation. |
| Anything interactive or exploratory with a GPU | Colab Pro+ or molab | Idle and maximum-runtime limits. molab offers an RTX 6000 for up to 12 hours with a 90-minute idle timeout. Never run an unattended multi-hour job here. |
| Embarrassingly parallel batch scoring | Modal | Serverless, credits refresh monthly. Good when the work is many small independent jobs rather than one long one. |
Storage, which is a real constraint on this machine
The working disk is near-full. Three rules follow, and they are not optional for anything that downloads bulk data:
- Hot and scratch data to the local fast disk - temporary files, intermediate results, anything with heavy or random I/O.
- Cold and archival data to the mounted cloud drive - completed runs, large input datasets read occasionally, backups. It is network-backed and slow, so nothing in a compute loop should live there.
- Nothing large in the repository. The graph is JSON text. A DepMap bulk CSV or a SKEMPI download belongs in scratch, with its provenance recorded in the node rather than the file committed.
The SKEMPI file is 1.6 MB and the DepMap manifest is small, but a full DepMap Omics release is tens of gigabytes and would fill the disk.
The resource-safety rule this project already operates under
Probe CPU and memory before launching agents or scripts, and keep at least ten per cent of each free. This is a standing instruction in the project and it exists because a saturated machine kills the very agent that saturated it, losing the work in progress. It applies as much to a parallel data pull with forty concurrent requests as to a subagent fan-out.
| resource safety rule | probe CPU and memory before launching agents or scripts and keep at least 10% of each free |
|---|---|
| headline finding | Almost none of the phase-2 work in this beat needs a GPU. The binding constraints are data access and session length, not FLOPs. |
| status | planned |
backends
[
{
"name": "Laptop / local",
"use": [
"all dataset pulls",
"DepMap re-derivations",
"cohort arithmetic",
"ChEMBL and gnomAD censuses",
"breakpoint coverage calculation"
],
"constraint": "network reliability and polite rate limiting; every script needs retry with backoff"
},
{
"name": "Boltz credits",
"use": [
"co-folding campaigns 1-5",
"design triage campaign 6"
],
"constraint": "credits refresh monthly; run positive controls early in the credit month; campaign 6 is the only one that can exhaust a month"
},
{
"name": "Explorer Slurm GPU cluster",
"use": [
"local KMT2A fragment structure prediction",
"de novo binder design if approved"
],
"constraint": "request GPUs through the scheduler, never the login node; MSA generation is CPU-bound and is often the slow step"
},
{
"name": "Modal",
"use": [
"embarrassingly parallel batch scoring"
],
"constraint": "serverless, credits refresh monthly; suits many small jobs, not one long one"
},
{
"name": "Hosted notebooks (Colab Pro+, molab, Kaggle)",
"use": [
"interactive exploration with a GPU"
],
"constraint": "idle and maximum-runtime limits; molab offers an RTX 6000 up to 12 hours with a 90-minute idle timeout; never run unattended multi-hour jobs here"
}
]storage rules
[ "hot and scratch data on fast local disk", "cold and archival data on the mounted cloud drive, never inside a compute loop", "no large data files in the repository; record provenance in the node instead" ]
- Running an unattended multi-hour job on a hosted notebook is the commonest way this kind of work is lost; the idle timeout kills it silently and the result looks like a failed run rather than a policy problem.
- Choosing a GPU backend for work that does not need one costs a queue wait and produces the same answer a laptop would have produced while waiting.
- A near-full working disk turns a large bulk download into a machine-wide failure, not just a failed script.
- What is the actual Boltz credit cost of a single menin-peptide co-fold, so the campaign budget can be planned rather than guessed?
- Does the Explorer cluster have an AlphaFold or Boltz module already installed, or would a container need building - and how long does that take?
- Is MSA generation for KMT2A fragments the rate-limiting step, and can a precomputed MSA be reused across fragments to avoid recomputing it?
- E1strong confidence 4 of 5: Replicated in peer-reviewed work by more than one group.dataset
The compute-intensive part of this beat is small: the executed DepMap analyses in this project query roughly 1,250 cell lines across dozens of genes through a public GraphQL API using only the Python standard library, with retry and backoff, and run on a laptop.
Oncofusion KG analysis scripts (analyses/depmap-codependency/run.py, analyses/depmap-lineage-conditioned/run.py) against the Open Targets Platform GraphQL API · Iqbal Lab Oncofusion Knowledge Graph 2026What this evidence cannot show
This holds for the analyses scoped in this beat. A genuinely large machine-learning effort - for example training a ddG model from scratch on structural features - would change the picture, though even that is a single-GPU, sub-hour job on 7,085 examples.
Evidence that argues against this (1)
- Cheap to run is not the same as reproducible. The Open Targets GraphQL route does not state which DepMap release its gene-effect values come from, and Chronos scores change between releases as models and screens are added; Dempster et al. document that the method's copy-number and screen-quality bias is reduced rather than eliminated. A laptop-scale analysis that cannot name its input version cannot be re-run to the same answer, which is a bigger problem for this project than compute cost. Dempster JM et al. 2021
- E2moderate confidence 3 of 5: One strong study, or several smaller consistent ones.preprint
Boltz-2 is distributed as an open-source package with a current public release of v2.2.1, and its affinity predictions run orders of magnitude faster than free-energy simulation, which is what makes credit-based rather than cluster-based execution appropriate for the campaigns planned here.
Boltz-2: Towards Accurate and Efficient Binding Affinity Prediction · Passaro S, Corso G, Wohlwend J, et al. · bioRxiv 2025What this evidence cannot show
Speed claims are relative to free-energy perturbation on the authors' benchmark; wall-clock cost for this project's specific complexes is unmeasured, and MSA generation can dominate runtime for large chains. **Source is a bioRxiv PREPRINT (10.1101/2025.06.14.659707) and has not been peer reviewed.** Added 2026-09-20 by the preprint-exposure audit: every other preprint-sourced item in this graph discloses its status in the caveat, and this one did not.
Evidence that argues against this (1)
- Speed is not accuracy, and the accuracy claim is the one that matters for a credit-metered campaign. Kapoor and Narayanan's survey of ML-based science documents how routinely reported performance collapses once leakage is corrected - in their own reproduction, complex models stopped outperforming decades-old logistic regression. An affinity predictor's reported benchmark numbers should be treated as an upper bound until this project has run its own held-out, target-disjoint evaluation on the menin/KMT2A-pathway chemistry it actually cares about. Kapoor S et al. 2023
- E3strong confidence 4 of 5: Replicated in peer-reviewed work by more than one group.database
Local structure prediction is required for KMT2A because the public AlphaFold database returns HTTP 404 for UniProt Q03164, the protein being 3,969 residues and beyond the bulk-prediction length cut-off.
AlphaFold Protein Structure Database prediction API, Q03164 · EMBL-EBI 2026What this evidence cannot show
Fragment-wise prediction is the practical route, but fragment boundaries are a modelling choice that can create or destroy an apparent pocket.
Evidence that argues against this (1)
- The prescription - compute KMT2A fragments locally - inherits a limitation the absence of a public model conceals. Ruff and Pappu show AlphaFold's low-confidence regions overlap intrinsically disordered regions and warn against inferring IDR structure and interactomes from them. KMT2A outside its small folded modules is largely disordered, so most of what a local run returns will be high-resolution-looking coordinates with no structural content, and choosing fragment boundaries on domain annotation is a way of limiting that damage rather than escaping it. Ruff KM et al. 2021
- related to →Dataset: PDB and AlphaFold - the structural census, including the two absences that shape every plan
Shared counter-evidence: local AlphaFold/Boltz runs on KMT2A fragments return confident-looking coordinates for disordered regions (Ruff & Pappu, PMID 34418423), so the compute plan does not close the structural gap it was written to close.
Reproducibility counter-evidence: the laptop-scale DepMap route does not report a release version, and Chronos values differ between releases with residual copy-number bias (PMID 34930405).
matches the co-folding campaigns to Boltz credits rather than cluster time
the executed DepMap analyses run on a laptop; compute is not the constraint
each ranked item is costed against the backend it would run on
THE ONE DISCLOSURE GAP: it cited a bioRxiv preprint at moderate with a caveat that never said the source was unreviewed. Corrected 2026-09-20.