Can Your Molecular Docking Study Be Re-Executed? An AutoDock Vina Reporting Checklist

A practical AutoDock Vina reporting checklist for preserving prepared inputs, software versions, search-box geometry, parameters, seeds, raw poses, failures, and the evidence needed to re-execute a docking study.

Docking results are unusually easy to summarize and unusually hard to reconstruct. The final table may contain only ligand names and affinities, while the calculation depended on receptor state, ligand chemistry, preparation software, box geometry, engine version, scoring function, search effort, and stochastic choices. Losing any one of those links can turn a precise-looking number into an uncheckable claim.

A July 2026 preprint audited 236 open-access SARS-CoV-2 main protease docking papers. Under its stated essential-field rule, 8.1% reached the level required for direct re-execution, and the search-box center appeared in 33.9% of the papers [2]. This is a recent preprint focused on one literature corpus, not a universal estimate of all docking research. Its practical warning is still useful: important execution details routinely disappear between the workstation and the paper.

Re-executability is necessary, but it is not the same as reproducibility

Four questions that should not be collapsed into one

QuestionWhat it testsWhat it does not prove
Can the run be re-executed?The recorded files and instructions are sufficient to launch the intended calculation.That the original result was scientifically valid.
Can the result be repeated?The same workflow produces the same or an expected distribution of outputs.That another method or dataset will agree.
Is the result reproducible?An independent reconstruction supports the reported conclusion within a defined tolerance.That the conclusion is experimentally true.
Is the result biologically valid?Controls, orthogonal evidence, and experiments support the interpretation.That every computational detail was reported.

These layers reinforce one another but remain distinct. A perfectly archived bad protocol is re-executable. A biologically plausible conclusion with missing files may be impossible to audit. The reporting target is therefore not a ceremonial checklist: it is a minimum executable record attached to a separately validated scientific design [1,2].

The five-layer AutoDock Vina execution record

What must remain connected

LayerMinimum evidenceCommon failure
1. IdentityTarget, receptor source, ligand identifiers, study purpose, and protocol identifier.Files with ambiguous names and no stable source.
2. Prepared inputsExact receptor and ligand PDBQT files plus the source files and preparation decisions that created them.Only a PDB ID or SMILES is reported.
3. Execution configurationEngine and version, scoring function, box, exhaustiveness, pose count, energy range, CPU policy, and seed policy.Only “docked with Vina” appears in Methods.
4. Raw outputsRun log, ranked poses, scores, warnings, failed ligands, and mapping back to each input.Only a filtered spreadsheet or screenshot survives.
5. EvaluationSelection rules, controls, scripts, thresholds, exclusions, and the exact results used in each claim.Post hoc selection cannot be reconstructed.

1. Identify the software environment precisely

Record the AutoDock Vina version and how it was obtained. Also record the preparation tools and versions because a receptor or ligand can change before Vina sees it. Include the operating system, command-line binary or Python binding, relevant dependency versions, and any custom scripts or modified weights.

If the preparation record is incomplete, use the companion protein and ligand preparation checklist to recover the missing decisions before treating the protocol as executable.

The Vina Python API exposes the scoring function, CPU count, seed, receptor, ligands, box center, box size, spacing, and related configuration through its information methods [4]. Capture that machine-readable configuration when possible instead of reconstructing it later from memory.

Environment fields to report

FieldAcceptable record
Docking engineAutoDock Vina plus exact version or immutable build identifier.
Preparation stackMeeko or other tools, exact versions, commands, and non-default options.
Execution interfaceBinary, Python API, notebook, workflow system, or application version.
PlatformOperating system and architecture; container or environment definition when used.
ChangesCustom scripts, patched code, altered scoring weights, or special parameter files.

2. Preserve source molecules and prepared molecules

A receptor PDB ID is provenance, not a docking input. Record the entry and assembly, then retain the exact downloaded structure and the final PDBQT. Document removed chains, ligands, waters, ions, cofactors, alternate locations, missing atoms or residues, protonation choices, charges, flexible residues, and any local repairs. The same principle applies to every ligand: retain its stable identifier or source representation, stereochemistry, protonation and tautomer choice, 3D-generation method, charges, rotatable-bond treatment, and final PDBQT [1,3].

For the search-space record, the grid-box and exhaustiveness guide explains why center, dimensions, and search effort must remain explicit study inputs.

Use cryptographic checksums for retained files. A checksum does not validate chemistry, but it establishes whether two people are holding the same bytes.

Input provenance checklist

ObjectRecord before preparationRecord after preparation
ReceptorPDB accession or repository URL, assembly, chain, model, retrieval date, source-file checksum.Cleanup and protonation decisions, final PDBQT checksum, preparation log.
LigandStable identifier, source URL or database release, original SDF/MOL2/SMILES, stereochemistry.Enumerated state, 3D method, charge method, final PDBQT checksum, rejection reason if excluded.
Reference ligandExperimental instance and mapping to the receptor.Extraction, preparation, alignment, and RMSD atom-matching policy.

3. Report the search box as geometry, not prose

“The box covered the active site” cannot be executed. Report the center coordinates, dimensions, and units for every receptor. If the box came from a cocrystal ligand, residue selection, cavity detector, or manual placement, record that rule as well. The official Vina basic-docking example uses an explicit configuration with center and size values, and its output repeats the grid geometry [3].

For an ensemble, do not assume one coordinate triplet describes every aligned receptor. State the alignment reference and whether the box was transformed, recalculated, or reviewed independently.

4. Freeze every parameter that can change the run

AutoDock Vina execution fields

FieldWhy it belongs in the record
Scoring functionVina, Vinardo, and AutoDock4 scores are not interchangeable [3].
ExhaustivenessIt changes search effort and can change pose recovery or consistency.
Random seedA fixed seed enables an exact rerun; a multi-seed policy characterizes stochastic sensitivity.
CPU policyRecord the explicit CPU value or the fact that all available CPUs were used.
Pose count and energy rangeThey determine which poses are retained for later review.
Flexible receptor and special modesFlexible residues, custom maps, no-refine, score-only, or local-only settings change the protocol.
Command or API callIt is the shortest executable representation of the intended configuration.

A single fixed seed is useful for forensic repetition, but it does not measure robustness. If a conclusion depends on stochastic search, predefine a multi-seed experiment and report the seed list, aggregation rule, and variability. Do not run seeds until one produces the desired pose and report only that run.

5. Keep raw outputs before building the result table

Retain the stdout or log, output PDBQT, all requested poses, warnings, return code, elapsed status, and a manifest linking each result to its receptor, ligand, and configuration. Keep failures as first-class outcomes. Removing rejected or crashed ligands from the denominator silently changes the study population.

Then record every transformation between raw output and the published table: pose extraction, deduplication, clustering, rescoring, interaction filters, manual inspection, compound selection, and exclusions. FAIR principles emphasize rich metadata, provenance, and reusable data rather than files that are merely downloadable [5].

A practical re-execution package

FolderContents
provenance/Source URLs, accessions, retrieval dates, licenses, checksums, and target-state rationale.
inputs/source/Untouched receptor and ligand source files.
inputs/prepared/Exact PDBQT inputs and preparation reports.
config/Box files, parameter files, command lines, seeds, software versions, and environment definition.
outputs/raw/Logs, poses, scores, warnings, and failures for every attempted job.
analysis/Scripts, selection rules, processed tables, figures, and validation calculations.
READMEOne clean-room execution path, expected checks, known platform differences, and citation information.

6. Perform a clean-room handoff before publication

Move the package to a clean user account, workstation, virtual machine, or colleague who did not build it. Ask that person to follow only the README. Record whether installation succeeds, checksums match, the expected number of jobs runs, and the prespecified output checks pass.

Define tolerances before testing. Byte-identical output may be unrealistic across platforms or thread schedules, while the same top pose within a declared RMSD tolerance or the same rank band may be the scientifically relevant criterion. Explain which parts must match exactly and which may vary.

This handoff complements the broader workflow-validation process: validation asks whether the protocol is fit for the question, while clean-room re-execution asks whether another person can actually recover and run it.

What buyers should inspect in docking software

Individual and organizational evaluation routes

Buyer contextCore questionEvidence to request
Individual researcherCan I recover exactly what I ran next month without rebuilding context from folders and screenshots?Visible inputs, settings, history, raw outputs, exports, and documented license scope.
Laboratory or core facilityCan another scientist review, rerun, and audit the protocol under controlled versions?Version policy, shared naming and retention rules, permission model, export completeness, failure records, and clean-room acceptance test.
Company or regulated environmentDoes the workflow fit internal governance, validation, security, procurement, and retention requirements?Deployment architecture, access controls, audit expectations, support terms, change control, and independently approved validation plan.

Where MolNexus fits in the execution record

MolNexus 0.1.1 is BioChemIntelli's local Windows desktop workspace for receptor and ligand preparation review, interaction-box definition, AutoDock Vina 1.2.7 execution with Vina or Vinardo scoring, pose inspection, local SQLite job history, and result export. Keeping those stages visible in one project reduces the number of context handoffs a researcher must reconstruct.

That integration does not make a study reproducible by itself. Researchers still need stable source provenance, a validated protocol, an external archival policy, declared tolerances, and a clean-room re-execution test. MolNexus is coming soon; purchase and download are not open. Its current commercial profile is a US$499 one-time license for one Windows PC at a time, perpetual use of the purchased version, and 12 months of updates.

MolNexus scope in this workflow

Current supportResearch policy still required
Visible receptor and ligand preparation reviewSource selection, chemical-state rationale, and independent input validation
Explicit box and core Vina or Vinardo settingsTarget-specific protocol design, control strategy, and tolerance definition
Pose review and local job historyRetention period, immutable archive, review ownership, and change control
CSV, PDB complex, and ZIP exportsRepository deposition, licensing, publication package, and clean-room test

Frequently asked questions

The practical conclusion

Design the research record before the first production run. Give every source molecule a stable identity, preserve every prepared input, export the complete Vina configuration, retain raw successes and failures, and connect each published claim to the exact outputs and analysis that support it. Then give the package to someone who did not create it.

If that person cannot launch the intended calculation without asking what you meant, the study is not ready to be called re-executable. Fixing that gap before screening is cheaper than reconstructing it after publication.

References

  1. Martis EAF, Teletchea S. Ten Quick Tips to Perform Meaningful and Reproducible Molecular Docking Calculations PLOS Computational Biology (2025) DOI: 10.1371/journal.pcbi.1013030 Peer-reviewed guidance on target knowledge, preparation, validation, reporting, and sharing docking inputs and parameters.
  2. Giap V, Wang E, Nguyen C. Measuring the Re-executability of Published Molecular Docking Claims arXiv preprint (2026) DOI: 10.48550/arXiv.2607.12117 July 2026 preprint auditing 236 open-access SARS-CoV-2 Mpro docking papers; estimates are kept specific to that corpus and reporting framework.
  3. AutoDock Vina project. Basic Docking Official AutoDock Vina Documentation (2026) Official executable example covering prepared inputs, box geometry, scoring functions, exhaustiveness, random seed, and outputs.
  4. AutoDock Vina project. AutoDock Vina Python API Reference Official AutoDock Vina Documentation (2026) Official API reference identifying configuration fields exposed by the Vina object and output controls.
  5. Wilkinson MD, Dumontier M, Aalbersberg IJJ, et al.. The FAIR Guiding Principles for Scientific Data Management and Stewardship Scientific Data (2016) DOI: 10.1038/sdata.2016.18 Original FAIR principles supporting rich metadata, provenance, accessibility, interoperability, and reuse.