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
| Question | What it tests | What 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
| Layer | Minimum evidence | Common failure |
|---|---|---|
| 1. Identity | Target, receptor source, ligand identifiers, study purpose, and protocol identifier. | Files with ambiguous names and no stable source. |
| 2. Prepared inputs | Exact 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 configuration | Engine and version, scoring function, box, exhaustiveness, pose count, energy range, CPU policy, and seed policy. | Only “docked with Vina” appears in Methods. |
| 4. Raw outputs | Run log, ranked poses, scores, warnings, failed ligands, and mapping back to each input. | Only a filtered spreadsheet or screenshot survives. |
| 5. Evaluation | Selection 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
| Field | Acceptable record |
|---|---|
| Docking engine | AutoDock Vina plus exact version or immutable build identifier. |
| Preparation stack | Meeko or other tools, exact versions, commands, and non-default options. |
| Execution interface | Binary, Python API, notebook, workflow system, or application version. |
| Platform | Operating system and architecture; container or environment definition when used. |
| Changes | Custom 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
| Object | Record before preparation | Record after preparation |
|---|---|---|
| Receptor | PDB accession or repository URL, assembly, chain, model, retrieval date, source-file checksum. | Cleanup and protonation decisions, final PDBQT checksum, preparation log. |
| Ligand | Stable 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 ligand | Experimental 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
| Field | Why it belongs in the record |
|---|---|
| Scoring function | Vina, Vinardo, and AutoDock4 scores are not interchangeable [3]. |
| Exhaustiveness | It changes search effort and can change pose recovery or consistency. |
| Random seed | A fixed seed enables an exact rerun; a multi-seed policy characterizes stochastic sensitivity. |
| CPU policy | Record the explicit CPU value or the fact that all available CPUs were used. |
| Pose count and energy range | They determine which poses are retained for later review. |
| Flexible receptor and special modes | Flexible residues, custom maps, no-refine, score-only, or local-only settings change the protocol. |
| Command or API call | It 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
| Folder | Contents |
|---|---|
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. |
README | One 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 context | Core question | Evidence to request |
|---|---|---|
| Individual researcher | Can 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 facility | Can 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 environment | Does 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 support | Research policy still required |
|---|---|
| Visible receptor and ligand preparation review | Source selection, chemical-state rationale, and independent input validation |
| Explicit box and core Vina or Vinardo settings | Target-specific protocol design, control strategy, and tolerance definition |
| Pose review and local job history | Retention period, immutable archive, review ownership, and change control |
| CSV, PDB complex, and ZIP exports | Repository 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
- 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.
- 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.
- 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.
- 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.
- 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.