Decommission AlphaFold 2, replace with ESMFold2 — deferred, review 2026-11-13

[wilke]

Decision

Retire AlphaFold 2 from PredictStructureApp and replace it with ESMFold2 as
the non-diffusion protein-folding option.

Rationale: https://www.nature.com/articles/d41586-026-01686-3

AlphaFold 2 is the most expensive tool we carry and the least well-behaved on
current hardware. It needs ~2 TB of genetic databases, runs 2-8h because it
builds its MSA from local DBs, is the only JAX tool in an otherwise PyTorch
stack, and has open hardware defects we chose not to fix (#8 amber relax fails
on H200, #11 GoWe serialization). Both were closed citing this deprecation —
this issue is the work those closures implied but never tracked.

Blocked by #75

ESMFold2 must actually work before AlphaFold 2 can be removed. #75 (ESMFold2
listed in UI tool selector but not yet functional) is a hard prerequisite —
removing AF2 first would leave a gap rather than a replacement.

Current footprint

Area	Files mentioning alphafold	Notes
predict_structure/	10	adapter, CLI subcommand + 4 --af2-* options, auto priority
app_specs/	10	tool enum, af2_* params
service-scripts/	1	App-PredictStructure.pl param mapping
cwl/	9	tool + workflow definitions
container/	15	/opt/conda-alphafold env, reqts-alphafold.def
tests/	15	adapter tests, matrix cases A01/A02/N05
docs/	30	CLAUDE.md tables, testing guides, resource tables

Also: AF2_DEFAULT_DATA_DIR (~2 TB of genetic DBs) and the alphafold entry in
the auto priority order (cli.py:156, cli.py:210), where it currently sits
last as the fallback for protein-only jobs with no MSA source.

Proposed scope

• Land Verify ESMFold2 end-to-end on BV-BRC (works locally; scheduling + VRAM fixed in #92) #75 so ESMFold2 is functional and selectable
• Remove alphafold from the auto priority order; confirm ESMFold2 covers
  the protein-only / no-MSA case AF2 was the fallback for
• Remove alphafold from the tool enum in app_specs/PredictStructure.json
• Remove the UI tool-selector entry
• Remove the CLI subcommand and the --af2-* options
• Remove AlphaFoldAdapter and its tests
• Remove matrix cases A01/A02/N05; verify nothing else depends on them
• Drop /opt/conda-alphafold and reqts-alphafold.def from the container
  build (a large image-size win)
• Reclaim the ~2 TB genetic-database volume
• Update CLAUDE.md, README, and the docs resource/tool tables
• Decide the CWL story — remove the AF2 tool/workflow definitions or leave
  them unwired

Open questions

1. Grace period. Do we reject tool: alphafold immediately with a message
   pointing at ESMFold2, or keep accepting it for a release and warn? A hard
   rejection is cleaner but breaks any saved job spec or script that names it.
2. Order of operations. Remove from the UI/app_spec first (stops new jobs)
   and strip the container later, or do both in one release?
3. Database reclamation. Is the ~2 TB shared with anything else on the GPU
   hosts, or safe to delete outright once the container stops shipping AF2?
4. CWL definitions. Still used by GoWe experiments, or removable?

Related

• Verify ESMFold2 end-to-end on BV-BRC (works locally; scheduling + VRAM fixed in #92) #75 — ESMFold2 not yet functional (prerequisite)
• AlphaFold amber relax fails on H200 GPU (OpenMM CUDA platform) #8, GoWe: Directory/File serialization and newline injection block AlphaFold workflows #11 — closed citing this deprecation
• Validate tool/entity compatibility in preflight so invalid jobs fail at submit, not after GPU allocation #84 — preflight entity validation; the "use these tools instead" suggestions
  are generated from the adapter registry, so they stop naming AlphaFold 2
  automatically once the adapter is gone

[wilke]

Scope refined: #90 now covers the staged first step — remove AlphaFold 2 from auto selection and the BV-BRC UI while keeping it runnable via API and CLI.

That subset can ship independently because it does not depend on ESMFold2 being ready, so it is not blocked by #75 the way this issue is. Once #90 lands, AlphaFold is no longer reachable by a user who has not explicitly asked for it, which removes most of the urgency here.

This issue remains the eventual full removal — adapter, CLI subcommand, app-spec enum entry, container env (/opt/conda-alphafold, reqts-alphafold.def), and the ~2 TB of genetic databases — and stays blocked on #75.

[wilke]

Deferred — review 2026-11-13

Superseded in urgency by #90, which shipped the part that actually mattered:

• auto no longer selects AlphaFold 2 (PR Fix #90: retire AlphaFold 2 from auto selection, keep API/CLI access #91, 56b1e5a)
• Removed from the BV-BRC UI tool selector (PredictStructure: remove AlphaFold 2 from the tool selector BV-BRC/BV-BRC-Web#1397, against alpha)

So no new user can land on AlphaFold 2 by accident. What remains here is removal, not retirement: deleting the adapter, CLI subcommand, app-spec enum entry, CWL definitions, the /opt/conda-alphafold env, reqts-alphafold.def, and reclaiming the ~2 TB of genetic databases.

That has real upside — AlphaFold is the largest single contributor to container size and the only JAX tool in an otherwise PyTorch stack — but no urgency, and it stays blocked on #75 (ESMFold2 proven end-to-end on BV-BRC) since ESMFold2 is the intended replacement.

What to weigh on 2026-11-13

1. Has anyone run AlphaFold explicitly since Retire AlphaFold 2: remove from auto mode and the UI, keep API/CLI access #90 merged (2026-08-13)? That is the deciding datum. If usage is zero over three months, removal is uncontroversial; if not, we have found the users who need it and can ask what for.
2. Is ESMFold2 carrying the load? It needs to be routinely exercised through BV-BRC, not just locally — see Verify ESMFold2 end-to-end on BV-BRC (works locally; scheduling + VRAM fixed in #92) #75.
3. Is the 2 TB reclaim still worth the churn? Depends on disk pressure at the time.

Also worth knowing then

A01/A02/R01 remain excluded from every API matrix run (the --include-alphafold flag is off by default), so AlphaFold has not been exercised since the 260622 container. If we keep it, that gap should be closed; if we remove it, the cases go with it. Either way the current state — shipped but untested — should not persist past this review.

Nothing here is blocking. Re-evaluate on the date rather than carrying it as active work.