What Is the PDBQT Format? Charges, Atom Types, and Torsions in AutoDock Vina

A PDBQT file can look almost identical to a PDB file in a text editor. That similarity is useful for coordinates, but it can hide the decisions that matter most for docking. The final columns carry parameters used by the scoring function, while ligand records are reordered into a tree that tells the search which fragments may rotate [1].

This makes PDBQT the boundary between chemical preparation and docking execution. If the boundary is wrong, a perfectly completed Vina run can still answer a question about the wrong molecular representation.

The Q and T in PDBQT refer to partial charge and atom type. The AutoDock 4.2 guide specifies their positions in ATOM and HETATM records and separately defines the ligand flexibility keywords [1]. Current Vina documentation uses prepared receptor and ligand PDBQT files for a standard rigid-receptor workflow [2].

An AutoDock atom type describes interaction behavior. For example, aromatic carbon and aliphatic carbon can have different types even though both atoms are carbon. A file therefore should not be audited by element count alone.

The ROOT block is the rigid base of the ligand. Each BRANCH record identifies a rotatable connection and opens a child fragment; ENDBRANCH closes it. Branches can be nested, so the order of atom records follows the torsion tree rather than merely reproducing the input atom order [1].

Inspect the model visually as well as textually. A bond that should be rigid but appears as a branch can expand the search unnecessarily. A genuinely rotatable bond that was frozen can prevent relevant conformations from being explored. Ring bonds, amide-like bonds, terminal groups, and macrocycles deserve deliberate review rather than a rotatable-bond count alone.

PDBQT does not reliably preserve bond orders or formal charges as a general chemical exchange format. Meeko's export documentation explains that reconstructing those properties from PDBQT alone can be impossible for some molecules [4]. Its workflow addresses this by writing a SMILES string and atom-index mapping into ligand remarks, then using that metadata when exporting Vina results to SDF.

This is why the official Vina tutorial recommends a chemically explicit ligand source such as SDF and warns against using PDB as the starting format for small molecules, because PDB does not contain bond connectivity information [2]. Meeko parameterizes an RDKit molecule with 3D coordinates and explicit hydrogens into atom types, partial charges, and rotatable bonds [3,5].

Standard Vina docking treats the receptor as rigid and the ligand as flexible. When selected receptor sidechains are flexible, current Meeko documentation places them in a separate flexible PDBQT representation and omits those movable atoms from the rigid receptor file. That is a different protocol, not an automatic property of every receptor PDBQT.

Run this inspection after the broader protein and ligand preparation workflow and before defining a production screen. If a ligand fails during conversion, use the SDF and ligand preflight guide to diagnose chemistry before repeatedly changing file converters.

The difficult part is not adding a file extension. It is keeping preparation decisions visible from input review to docking output. MolNexus 0.1.1 connects standard receptor and ligand preparation review, interaction-box setup, AutoDock Vina 1.2.7 execution with Vina or Vinardo, pose inspection, local history, and exports in one Windows workspace.

It does not replace chemical judgment or prove that a PDBQT representation is scientifically correct. Its value is making the standard workflow easier to inspect and retain when that documented scope matches the project.