rishivk144/enzyme-diamond-knn

Leak CURBER enzyme classification: DIAMOND nearest-neighbour EC voting

Predicts one fully specified EC number per enzyme sequence for the Leak CURBER enzyme classification task. Built from the course starter; uses only train.parquet. No external data and no pretrained models.

Method

1. Index. Every unique training sequence goes into a DIAMOND protein index (weights/train.dmnd), with its recorded ECs in weights/labels.json.
2. Search. Each unique input is aligned against the index, keeping the top 25 hits. The search runs in stages (see Runtime) and ends in DIAMOND's very-sensitive mode when time allows.
3. Vote. Each hit votes for its ECs with weight (bitscore / best bitscore) ** 16, split 1/n across a hit's n ECs. That split matches the metric's 1/n credit. The highest-scoring EC is the prediction.
4. No hit. Inputs without a hit get an ultra-sensitive second search if time allows, then the most frequent training EC (2.7.7.48).

Local validation

The hidden validation inputs are at most about 55% identical to any training sequence. I measured this by searching them against the training set. A random holdout would therefore overstate accuracy, so local validation used:

• MMseqs2 clustering of the training sequences at 50% identity and 80% coverage.
• A holdout of 1,092 whole clusters (11,804 sequences), searched against the rest.
• Reweighting of holdout scores so each top-hit identity band counts as much as in the real validation inputs.

Model	L4	L3	L2	L1
Starter baseline (most frequent EC)	0.011	0.055	0.143	0.381
This model	0.818	0.930	0.942	0.972

Scores use the official 1/n credit rule.

Runtime

The search is staged so a slow machine or a small /tmp cannot leave inputs without an answer:

1. Quick pass. DIAMOND default mode over all inputs. About 40 s and 4 MiB of temporary disk for 12k inputs. Holdout L4 0.808 on its own.
2. Upgrade pass. Very-sensitive mode in batches of 3,000, replacing quick-pass hits batch by batch. It runs only while the time budget allows; a failed or skipped batch keeps its quick-pass hits.
3. Rescue pass. Ultra-sensitive mode for inputs still without hits, if time allows.

All searches stop 70 s before the 10-minute limit. Progress and any errors are logged to stderr.

Measured on the 11,804-sequence holdout with 2 CPUs and a 16 MiB file-size limit:

Condition	Time	L4
Normal speed	362 s	0.818
Half CPU speed	514 s	0.817
32 MiB /tmp (upgrade pass fails)	335 s	0.816

Queries stream to DIAMOND through stdin and stdout. Seed hits are spread over 32 temp bins, so the largest temp file stays near 6 MiB, well under the 16 MiB limit.

Each DIAMOND bin reserves 64 MiB of virtual memory and holds a file open. An earlier version used 256 bins, which reserved 16 GiB; under the evaluator's 16 GiB address-space limit, every search failed at once and all inputs fell back to the most frequent EC. 32 bins reserve 2 GiB and keep about 37 files open. If a search still fails on memory or open files, it retries with 16 and then 8 bins. The sandbox limits are logged at start-up.

To reproduce the evaluator's limits in the local Docker test, wrap the command in bash -c "ulimit -v 16777216 && ulimit -f 16384 && python /app/predict.py ...".

Files

• predict.py: inference.
• train.py: rebuilds weights/ with python train.py --train ../data/train.parquet.
• inputs.py, task.json, ec_vocabulary.json: unchanged from the starter.
• bin/diamond: DIAMOND v2.1.11 Linux release binary (GPL-3.0; source at github.com/bbuchfink/diamond).

EC vocabulary: ExPASy ENZYME release 02-Sep-2026, SIB, CC BY 4.0.