Why AutoDock Vina Gives Different Results Every Time (Exhaustiveness, Seed and Reproducible Docking)

AutoDock Vina gives different results each run because its search is non-deterministic: every run starts from random perturbations, so repeated jobs explore different parts of the conformational space. Fix the run with --seed, raise --exhaustiveness from its default of 8 to reduce the variation, and report both values in your methods.

You dock a ligand, get -8.4 kcal/mol, rerun the identical command an hour later and get -8.1. Nothing changed on disk. This is the moment most students conclude they have broken something. They have not. The variation is a documented property of the algorithm, and the useful question is not how to eliminate it but how to control it, measure it, and describe it correctly in a dissertation. This guide covers what exhaustiveness actually does, how to make a run reproducible, how many repeats you need before a number means anything, and the exact wording to use in your methods section. Written by the StemSkills Lab team, from 10+ years in sequence and structural bioinformatics, drug discovery and design, and multiscale molecular modeling.

Why does AutoDock Vina give a different score every time?

Because the algorithm is stochastic by design. The official AutoDock Vina FAQ puts it plainly: “The docking algorithm is non-deterministic. Even though with this receptor-ligand pair, the minimum of the scoring function corresponds to the correct conformation, the docking algorithm sometimes fails to find it.”

Mechanically, a Vina job is not one search. It is a set of independent runs, and each run is a chain of steps in which “each step involves a random perturbation of the conformation followed by a local optimization”. The number of steps in a run is chosen heuristically from the size and flexibility of your ligand and any flexible side chains. The results are then, in the documentation’s words, “merged, refined, clustered and sorted automatically to produce the final result”.

Two consequences follow directly, and both matter for how you interpret your output:

• The reported affinity is the best value the search happened to find, not a computed property of the complex. A different draw of random numbers can find a slightly better or slightly worse minimum.
• Variation between repeat runs is information. A pose that reappears with a stable score across independent runs is a converged result. A pose that appears once is a lucky sample.

This randomness is the price of the speed that made Vina standard. The original paper by Trott and Olson, AutoDock Vina: improving the speed and accuracy of docking with a new scoring function, efficient optimization, and multithreading (Journal of Computational Chemistry, 2010, vol. 31, pp. 455 to 461), reports approximately a two orders of magnitude speed-up over AutoDock 4 along with improved binding-mode accuracy on the AutoDock 4 training set. If you are new to the workflow around this step, start with our pillar guide to molecular docking.

What does exhaustiveness actually control?

It controls how many independent runs Vina performs, which is why it is the main lever on run-to-run consistency. The FAQ states that “the number of runs is set by the exhaustiveness parameter”, and adds a detail worth knowing on a shared machine: “Since the individual runs are executed in parallel, where appropriate, exhaustiveness also limits the parallelism.” Setting exhaustiveness to 4 on a 16 core node will not use 16 cores.

The relationship between effort and reliability is documented rather than folklore. The AutoDock Vina manual states that increasing the exhaustiveness level “should increase the time linearly and decrease the probability of not finding the minimum exponentially”. Linear cost, exponential benefit, is an unusually good trade, and it is the reason the default is worth changing.

The AutoDock Vina basic docking tutorial gives the concrete recommendation: “The default exhaustiveness value is 8; increasing this to 32 will give a more consistent docking result.”

The cost column follows directly from the manual’s own statement that time increases linearly with exhaustiveness. Measure it on your own system rather than trusting any published timing, since wall time depends on your box size, ligand flexibility and core count.

How do you make an AutoDock Vina run reproducible?

Set the seed. The manual is unambiguous, and it comes with a condition students routinely miss: “Exact reproducibility can be assured by supplying the same random seed to both calculations, but only if all other inputs and parameters are the same as well.”

A fully specified, reproducible command looks like this:

vina --receptor receptor.pdbqt \
     --ligand ligand.pdbqt \
     --center_x 11.0 --center_y 90.5 --center_z 57.8 \
     --size_x 20 --size_y 20 --size_z 20 \
     --exhaustiveness 32 \
     --num_modes 9 \
     --seed 42 \
     --cpu 8 \
     --out ligand_out.pdbqt > ligand.log

Read the condition carefully. “All other inputs and parameters” includes the receptor and ligand PDBQT files, the box centre and size, the exhaustiveness, and the CPU count, because the number of parallel workers changes how the independent runs are distributed. Change any one of those and the same seed no longer reproduces the same answer. This is why a seed alone is not a methods section.

The cleanest way to satisfy the condition is to stop typing the command. Put everything in a config file and version-control it:

receptor = receptor.pdbqt
center_x = 11.0
center_y = 90.5
center_z = 57.8
size_x = 20
size_y = 20
size_z = 20
exhaustiveness = 32
num_modes = 9
seed = 42

Then run vina --config conf.txt --ligand ligand.pdbqt --out ligand_out.pdbqt. The box definition is now a file you can attach to your thesis rather than a number you half remember.

Should you fix the seed, or run repeats?

Both, for different purposes, and confusing them is a real methodological error.

• A fixed seed gives reproducibility. Your examiner can rerun your command and get your exact number. It does not make the number more reliable. Reporting a single seeded run as your result quietly hides how much that number moves.
• Repeat runs with different seeds give convergence evidence. This is what tells you whether -8.4 is a stable answer or one sample from a spread.

The defensible protocol is to do both: run a set of independent repeats to characterise the spread, then publish one fixed seed so the work can be reproduced exactly. A simple convergence test:

for i in $(seq 1 10); do
  vina --config conf.txt --ligand ligand.pdbqt \
       --seed ${i} --out out_rep${i}.pdbqt > rep${i}.log
done

awk '/^ *1 /{print FILENAME, $2}' rep*.log

That prints the top-mode affinity from each repeat. Judge it on two things, not one. First, the spread of the best affinity across repeats. Second, and more important, whether the top pose is the same binding mode each time. Load the ten output files into PyMOL and look. A spread of 0.2 kcal/mol around one consistent pose is a converged result. The same score arrived at through three different poses in different corners of the box is not, and no increase in exhaustiveness will fix a box that is too large or centred on the wrong site.

What do num_modes, energy_range and cpu do?

These are the three options students most often leave at default without knowing what they are defaulting to.

Note the interaction between the last two. Because --cpu is one of the “other parameters” the reproducibility condition depends on, letting Vina auto-detect the core count means the same seed on a different machine can give a different answer. Pin it.

How should you report docking settings in a dissertation?

Give a reader everything they need to rerun you. A methods sentence that passes review looks like this:

“Docking was performed with AutoDock Vina [version] (Eberhardt et al., 2021) using a 20 x 20 x 20 A search box centred on (11.0, 90.5, 57.8), exhaustiveness 32 and num_modes 9. Ten independent runs were performed with seeds 1 to 10; the reported affinity is the mean of the top-ranked mode across runs, with the standard deviation given. The configuration file is provided in the supplementary material.”

Substitute your own real version number, coordinates and values. Four elements make it defensible: the software version, the box definition, the search settings, and evidence that you checked convergence rather than reporting a single draw. Cite the version you actually ran. For Vina 1.2.x that is AutoDock Vina 1.2.0: New Docking Methods, Expanded Force Field, and Python Bindings (Journal of Chemical Information and Modeling, 2021, vol. 61, pp. 3891 to 3898), alongside the 2010 Trott and Olson paper.

Troubleshooting: variation that is not normal randomness

• Scores swing by more than about 1 kcal/mol between repeats. Usually the search box is too large or badly centred, so different runs are finding entirely different sites. Tighten the box around the known pocket before touching exhaustiveness.
• The same seed gives different answers on two machines. Something in “all other inputs and parameters” differs. Check the Vina version first, then the CPU count, then confirm the PDBQT files are byte-identical.
• Every pose is at the edge of the box or partly outside it. The box does not contain the pocket. Recentre it on the co-crystallised ligand or a validated pocket prediction, then redock.
• Only one or two modes are returned when you asked for nine. --energy_range filtered the rest out because nothing else scored within 3 kcal/mol of the best mode. Widen it if you want to see them.
• Affinities look implausibly strong across the whole library. Check protonation and charges in the receptor preparation. Vina scores are comparable within one carefully prepared system and are not absolute binding free energies.
• Raising exhaustiveness changes nothing. That is a good sign, not a failure. It means the search had already converged at the lower setting, so keep the lower one for your screen and note it.

Frequently asked questions

Is it wrong to report a single docking run in a thesis?

It is weak rather than wrong. Because the algorithm is non-deterministic, one run is one sample. Reporting the mean and standard deviation over repeat runs with different seeds, and stating that the top pose was consistent, is far more defensible and takes only a few extra minutes of compute.

Does a higher exhaustiveness give a better binding affinity?

It gives a more thorough search, not a better compound. Higher exhaustiveness reduces the chance of missing the scoring function’s minimum, which sometimes means a slightly more negative score. It cannot improve the accuracy of the scoring function itself.

What exhaustiveness should I use for virtual screening of thousands of compounds?

Two stages work better than one compromise setting. Screen the full library at or near the default of 8 to rank it, then redock the top few hundred at 32 with repeats. You get throughput where you need it and reliability where the result matters.

Can I compare Vina scores between two different proteins?

Not reliably. Vina affinities are best used to rank ligands against a single, consistently prepared receptor. Comparing across targets mixes in differences in pocket size, preparation and protonation that the score was never designed to separate.

Why does my docking still fail to reproduce a known crystal pose?

Redocking the co-crystallised ligand and measuring RMSD to the crystal pose is the standard validation step, and the FAQ is candid that “the predictive accuracy varies a lot depending on the target”. If redocking fails, the problem is usually receptor preparation, missing structural waters, or a pocket that needs side-chain flexibility, rather than the search settings.

Docking is one step in a longer chain, and the order you learn the pieces in matters. Our computational biology skills roadmap sets that sequence, and the molecular docking pillar guide covers receptor preparation, box definition and pose validation around this article.