Grover / GroveFold — Technical Protocol & Benchmark Report
Paper-faithful Grover-search peptide folding (Khatami et al. 2023). Three energy models (SP / MR / MR-MP), a Draper-QFT arithmetic oracle, full reproduction protocol + fusion4 CPU/GPU benchmark results.
DOI 10.1371/journal.pcbi.1011033 · PLOS Computational Biology (2023)
Contents
1. Executive summary
Grover search treats folding as unstructured search: build an oracle that flips the phase of any conformation whose energy is below a threshold Eth, then amplify those marked states with ⌊π/4·√(N/M)⌋ Grover iterations. Unlike VQE (which optimizes), Grover provably concentrates probability on the answer set and gives a quadratic speedup over classical enumeration.
- Answer states reproduce the paper exactly. Every classical validation case (SP s=2/3/6) matches the paper's answer-state tables.
- The quantum circuit concentrates as predicted. P(answer) reaches 97.9–100% at the optimal iteration count k_opt across SP, MR and MR-MP — amplifications up to 256× over the random baseline.
- GPU pays off here (unlike VQE) because Grover circuits are deep and wide (16–33 qubits): the heaviest run (MR-MP s=3, 24q) was 3.6× faster on GPU.
2. Problem encoding & the three models
Each residue's turn is one of several categories (Neg, Pos, H1, Pol1, Pol2). A chain of s turns is encoded in n = 3s data qubits; the search space is N = 2ⁿ. The oracle marks the M states whose energy ≤ Eth. The three models differ only in the energy function:
| Model | Energy | Arithmetic | Use |
|---|---|---|---|
| SP | Simplified-Potential — small integer pair energies, no distance dependence. | Integer accumulator | Baseline / answer-state validation |
| MR | More-Realistic — pair energies weighted by inter-residue distance reciprocals. | Fixed-point, precision p=5 | Distance-aware folding |
| MR-MP | MR, More-Precision — same physics, higher fixed-point precision. | Fixed-point, precision p=10 | High-fidelity MR |
Answer states are reported as category strings, e.g. SP s=2 → ['Neg-Pos', 'Pos-Neg']; SP s=3 → ['Neg-Pos-Neg', 'Pos-Neg-Pos'] — these match Khatami Tables S1/S2/S3 exactly.
3. Grover search & k_opt
|ψ0> = H^n |0> # uniform superposition over N conformations
repeat k times:
|ψ> = Oracle |ψ> # phase-flip states with energy <= E_th (the M answers)
|ψ> = Diffuser |ψ> # inversion about the mean (amplitude amplification)
measure # collapses onto an answer with high probability
k_opt = floor( (pi/4) * sqrt(N / M) ) # SP: closed form
k_opt = argmax_K sin^2( (2K+1) * arcsin(sqrt(M/N)) ) # MR: exact enumeration (k_opt_mr)
amplification = P(answer at k_opt) / (M / N) # vs random baselineOver- or under-shooting k_opt reduces P(answer) (amplitude over-rotates), so the sweep R = 0…2·k_opt+1 is run and the peak is confirmed to land at k_opt (peak_matches_kopt).
4. Oracle construction (Draper-QFT arithmetic, Fig 1B)
The oracle is a genuine gate-level arithmetic circuit, not a lookup. It computes each conformation's energy into an accumulator register, compares it to Eth, kicks back a phase if below threshold, then uncomputes:
1. ACCUMULATE for each contact pair, add its (fixed-point) energy into an
accumulator via Draper QFT addition (QFT → phase rotations → IQFT)
2. COMPARE compare accumulator to E_th (subtract, inspect sign qubit)
3. KICKBACK phase-flip when energy <= E_th (marks the answer states)
4. UNCOMPUTE reverse steps 2–1 to restore work qubits (Bennett uncompute)Implemented in grove_adapter._build_grover_circuit (SP) and oracle_mr.build_grover_mr(MR / MR-MP). MR uses uniform_distance_matrix for the distance weights and k_opt_mr for the exact optimal iteration count. Compact-accumulator design: the project reuses one accumulator register sequentially (high depth, few qubits) rather than the paper's unrolled parallel work qubits — see §10.
5. Code map
| Path | Role |
|---|---|
| backend/services/quantum/khatami_energy.py | SP energy landscape: build_h_diag, decode_state, default_contacts |
| backend/services/quantum/grove_adapter.py | _build_grover_circuit — SP arithmetic oracle + diffuser |
| backend/services/quantum/oracle_mr.py | build_grover_mr, uniform_distance_matrix, k_opt_mr (exact) |
| backend/services/quantum/algorithms/grover_khatami2023.py | Algorithm wrapper (registry entry) |
| run_grover_strict.py | SP driver — classical answer-state validation + quantum sweep (s=2/3/6, multiple E_th) |
| run_grover_mr.py | MR / MR-MP driver (QFTGate compat shim for qiskit 1.1.1) |
| run_grover_qiskit.py | Original canonical-case SP driver (s=2 reference) |
6. Reproduction environment (fusion4)
| Host | fusion4.blr.cdac.in, user ketan |
| Python env | /home/ketan/anaconda3/envs/quantum_env — qiskit 1.1.1, qiskit-aer (GPU) |
| Working dir | /home/ketan/Raja/grover/ (vendored services/ + infra stubs) |
| Backend select | statevector ≤ 26 qubits, else matrix-product-state (MPS) |
| QFTGate shim | qiskit 1.1.1 lacks QFTGate; shimmed via QFT(n).to_gate() before importing oracle_mr |
| Resource caps | --max-threads 85 (≈66% of 128 cores) |
7. Exact reproduction commands
# SP — classical answer-state validation (all s, all E_th)
python run_grover_strict.py --validate
# SP — quantum sweep (single case), capped
python run_grover_strict.py --single --s 3 --i 2 --eth -7 --rmax 25 --device GPU --max-threads 85
# MR (p=5) and MR-MP (p=10)
python run_grover_mr.py --s 3 --device GPU --precision 5 # MR
python run_grover_mr.py --s 3 --device GPU --precision 10 # MR-MP
# MR circuit validation (qubit count vs Table 1)
python run_grover_mr.py --s 2 --validate8. Benchmark results (fusion4)
8.1 Classical answer-state validation (vs paper Tables S1–S3)
| Model | s / i | E_th | n / total_q | M | Answer states | Paper match |
|---|---|---|---|---|---|---|
| SP | 2 / 1 | −3 | 6 / 15 | 2 | Neg-Pos, Pos-Neg | ✅ |
| SP | 2 / 1 | −2 | 6 / 15 | 5 | H1-H1, Neg-Pos, Pol1-Pol1, Pol2-Pol2, Pos-Neg | ✅ |
| SP | 3 / 2 | −7 | 9 / 20 | 2 | Neg-Pos-Neg, Pos-Neg-Pos | ✅ |
| SP | 3 / 2 | −5 | 9 / 20 | 5 | +H1/Pol1/Pol2 triples | ✅ |
| SP | 6 / 3,4,5 | −19…−10 | 18 / 31–33 | 2–44 | derived contact graphs | ✅ (qubit counts match Table 1) |
8.2 SP quantum runs (Grover amplification)
| Case | q | N / M | k_opt | P(answer) | Amplif | Peak@k_opt |
|---|---|---|---|---|---|---|
| s=2 E_th=−3 | 15 | 64 / 2 | 4 | 99.95% | 31.98× | ✅ |
| s=2 E_th=−2 | 15 | 64 / 5 | 2 | 97.85% | 12.53× | ✅ |
| s=3 E_th=−7 | 20 | 512 / 2 | 12 | 99.98% | 255.94× | ✅ |
| s=3 E_th=−5 | 20 | 512 / 5 | 7 | 99.32% | 101.7× | ✅ |
8.3 MR / MR-MP quantum runs (distance-weighted)
| Model | s | total_q | k_opt | P(answer) CPU / GPU | Amplif | Answer states |
|---|---|---|---|---|---|---|
| MR (p=5) | 2 | 16 | 4 | 99.93% / 99.93% | 31.98× | Neg-Pos, Pos-Neg |
| MR-MP (p=10) | 2 | 21 | 4 | 99.93% / 99.90% | 31.97× | Neg-Pos, Pos-Neg |
| MR (p=5) | 3 | 19 | 12 | 100% / 100% | 256× | Neg-Pos-Neg, Pos-Neg-Pos |
| MR-MP (p=10) | 3 | 24 | 12 | 100% / 99.98% | 256× | Neg-Pos-Neg, Pos-Neg-Pos |
Reading these: every quantum run peaks exactly at k_opt and reaches 97.9–100% P(answer) — the oracle marks the right states and amplitude amplification works as the theory predicts. Higher s (more turns) gives larger amplification because the search space N grows faster than the answer set M.
9. Resource utilization (time, CPU & memory)
Instrumented per run by a MemMonitor thread (psutil RSS), time.process_time() (CPU-seconds), and nvidia-smi memory.used. Unlike VQE, Grover circuits are deep and wide, so both time and memory grow sharply with qubit count.
| Run | q | Wall CPU / GPU | GPU speedup | Peak host RAM | CPU-time |
|---|---|---|---|---|---|
| SP s=3 E_th=−5 | 20 | — / — | ~1.6× | 4,419 / 4,138 MB | 4,914 s |
| MR s=2 | 16 | 4,070 s / 1,763 s | 2.3× | 2,199 / 2,769 MB | 346,222 s |
| MR-MP s=2 | 21 | 1,481 s / 1,030 s | 1.4× | 3,255 / 3,332 MB | 41,905 s |
| MR s=3 | 19 | 6,783 s / 6,265 s | 1.1× | 7,164 / 7,259 MB | 57,185 s |
| MR-MP s=3 (heaviest) | 24 | 39,069 s / 10,816 s | 3.6× | 12,014 / 12,391 MB | 2,210,583 s |
Memory grows with qubits and precision: ~2 GB at 16q (MR s=2) up to ~12 GB at 24q (MR-MP s=3). CPU-time ≫ wall (e.g. 2.21M CPU-seconds for MR-MP s=3 on CPU → ~57 effective cores under the 85-thread cap). GPU wins decisively at depth: the 24-qubit MR-MP s=3 run was 10.8 h on CPU vs 3 h on GPU (3.6×) — the opposite of VQE's tiny circuits, where GPU was slower.
GPU VRAM caveat (same as VQE): the stored gpu_mem_used_mb ≈ 41,500 MB is the whole-device nvidia-smi total at sample time (shared with the QAOA job), not Grover's own footprint. Grover's actual statevector at 24 qubits is 2²⁴·16 B = 256 MB (+ CUDA context); the host RSS figures (2–12 GB) are the reliable memory measurement.
10. Known deviations & next steps
- Compact oracle vs paper Table 1 qubit counts. The project's MR oracle reuses one accumulator register sequentially, so s=2 MR uses 16 qubits (vs the paper's unrolled 151). Same physics, same answer states (verified vs Tables S2/S3) — a deliberate depth-for-qubit-count tradeoff, not a fidelity loss.
- SP s=6 i=5 — 33 qubits, MPS, partial probe. This case auto-runs on a matrix-product-state backend (statevector would be 2³³·16 B ≈ 137 GB). Its optimal iteration count is k_opt = 284 (N=262,144, M=2), so the
--rmax 4sweep is a deliberate feasibility probe (R=0–4), not the full amplification curve. It was first launched on CPU-MPS where the deep QFT-arithmetic oracle drives the MPS bond dimension up and a single oracle application is extremely slow (no iteration completed in ~45 h, output block-buffered). It is now re-running on GPU-MPS, unbuffered: R=0 returns in 0.3 s; each subsequent iteration applies the full 33-qubit oracle (the cost driver). The ≤26-qubit results in §8 are all complete and validated; the s=6 amplification peak at R≈284 is beyond practical exact-simulation reach. - QFTGate shim is required on qiskit 1.1.1 (no native
QFTGate); it maps toQFT(n).to_gate()and is behaviorally identical. - IBM hardware runs were out of scope — all results are exact statevector / MPS simulation.
- Next: finish SP s=6 i=5 (or switch it to MPS to bound memory); add MR variants for s≥4 if a deeper distance-aware sweep is wanted.