GPU docking with AutoDock-GPU and Vina-based engines

GPU molecular docking requires validated inputs, an identified engine and a reproducible task list. This guide describes checks for preparing and distributing a screen, then measuring successful results and cost. It does not provide an interchangeable launcher for AutoDock-GPU and Vina-based engines.

What we’ll cover

• Choosing a compatible container image and installing the selected docking engine
• Preparing reproducible receptor and ligand inputs
• A batch plan with explicit success, failure and output checks
• A measurement checklist and cost calculations
• VRAM, file I/O, and common error traps

Prepare and validate your GPU workload

Check the available configuration and software compatibility before launching. Measure results against a reference and keep an independent backup of your inputs and outputs.

Try Compute now

1) Choose your image

For a container-based deployment, assess these two configuration options:

A) Use a compatible CUDA template and add docking tools

• Select an image compatible with the chosen engine build, driver and GPU. Record the image digest and software versions; a CUDA label alone is insufficient.
• Use the installation instructions for the selected engine and version. Do not mix AutoDock-GPU arguments with Vina-family command lines.

B) Build a reusable image

• Build a private image that contains your docking tools + Python stack for prep.
• Add env vars:
  • NVIDIA_VISIBLE_DEVICES=all
  • NVIDIA_DRIVER_CAPABILITIES=compute,utility
• Have the entry script report versions and verify its working directory, inputs and output permissions before starting tasks.

Follow the provider’s container-runtime instructions. Nested Docker is not a prerequisite for the workflow described here; GPU access depends on the host runtime and assigned devices.

2) Minimal input prep that’s reproducible

Directory layout

Keep receptor files, grid data, ligand inputs and outputs in separate directories. Assign each ligand a stable unique identifier and create a new output directory for each run; do not reuse an earlier result as evidence of success.

Receptor

• For AutoDock-GPU, use the engine’s documented grid-map and ligand inputs. The maintainer documentation describes its batch interface. Other engines require their own preparation and scoring settings.
• Keep a README with center/size and any protonation choices.

Ligands

• Convert to PDBQT in a separate prep step (SMILES/SDF → PDBQT). Keep a deterministic script that sets protonation, tautomers, and charges the same way every time.
• Validate by docking a tiny panel first (10–20 ligands) and reviewing poses/scores.

3) Validate a single-GPU batch

Select one engine and pin its version before building a launcher. First run a small reference set using that engine’s own example. Check poses, scores, exit status and expected result files.

Use a manifest mapping each task to its ligand, receptor, settings and unique result path. A launcher must call the real engine, wait for every task, capture failures and check expected outputs before reporting success. A placeholder function that returns without docking cannot validate a batch. Prefer the engine’s documented batch facility when it meets these requirements.

Choosing concurrency

• Start with one validated task stream. Increase concurrency only when measured throughput improves without exceeding memory limits or changing result quality. No fixed process count or utilization target fits every engine.
• Watch nvidia-smi for memory and utilization.

4) Partition work across GPUs

Partition the manifest into disjoint task sets. GPU selection and input partitioning are separate steps: changing the visible GPU does not change which ligands a command reads.

Before launch, check that the union of all partitions equals the intended task list and that their intersections are empty, unless replicas are intentional and separately identified. Give each worker its own partition and output directory. Verify device numbering for the engine and visible-device configuration in use.

Reconcile the completed task identifiers against the manifest. Treat missing, duplicate and failed outputs separately; output-directory separation alone does not prevent duplicated work.

5) Self‑benchmark & cost math

Record only what matters:

Record engine/version, input manifest, preparation choices, search settings, seeds, hardware and elapsed time. Count attempted tasks, successful validated tasks, failures and intentional replicas separately.

Cost per 10k ligands

For a nonzero number of validated tasks: normalized cost per 10,000 = total measured run cost × 10,000 / validated task count. State whether tasks represent unique ligands or replicas, and include the billed cost of failed attempts.

Report aggregate throughput and cost with the GPU count and task definition. If reporting per-GPU figures, explain the allocation instead of mixing total-instance pricing with a single-GPU denominator.

6) Practical knobs that move throughput

• Search settings: use the parameters documented for the chosen engine. Any reduction in search effort requires repeating your quality checks.
• Concurrency: measure memory and completed-task throughput before increasing the number of workers.
• I/O: retain the logs and outputs required to audit success, failures and scientific results. Reduce unnecessary output only after defining those requirements.
• Random seeds: record the seeds for every run and use a defined replication plan when assessing variability.

7) Troubleshooting

GPU memory exhausted
Reduce concurrent tasks or choose adequate memory. Do not silently reduce search effort or change the scientific settings to make the job fit.

All jobs fail quickly
Check the grid inputs and engine-specific options. Rerun one ligand with detailed logs and compare against a validated reference using equivalent settings.

Weird scores or poses
Input prep differences (protonation/tautomers/charges). Normalize your prep and test on a small curated set.

GPU underused
Profile preparation, docking and output stages before adding workers. Confirm that the selected engine is actually running and producing validated results.

Methods record

Keep the immutable input manifest, image digest, engine version, command arguments, device assignments, seeds, output paths, timings and validation results together. This is a recording checklist, not a runnable configuration.

Related reading

• Scientific modeling on cloud GPUs — what works, what doesn’t

Try Compute today

Use custom templates to reuse a tested container configuration. Check software compatibility and available capacity separately. Back up data outside the instance and check the current restart and retention conditions before stopping it.

‍