ProDy models protein dynamics in Python, from elastic networks to co-evolution

What the package actually models

ProDy is described as a free and open-source Python package for protein structure, dynamics, and sequence analysis, and it allows for comparative analysis and modeling of protein structural dynamics and sequence co-evolution.

The lineage is specific and it matters for judging the tool. The README cites three papers: the original ProDy paper in Bioinformatics in 2011, a 2014 paper on Evol and ProDy for bridging sequence evolution and structural dynamics, and a 2021 paper titled ProDy 2.0: Increased Scale and Scope after 10 Years of Protein Dynamics Modelling with Python. The authors are Bakan, Meireles, Bahar and others, and the homepage sits in the Bahar group at Pitt, whose field is the mechanics of biological macromolecules.

So the core idea is inference of dynamics rather than simulation of it. Instead of running a molecular dynamics trajectory and hoping to observe a rare transition, an elastic network model treats a protein as a graph of residues connected by springs and derives its soft modes from the topology of that graph. The slow collective motions of the protein are the low frequency modes of the network. That is a fast, coarse picture, and it is exactly what makes it useful for comparative work across many structures.

The package is aimed at two audiences at once, which the synopsis states as the API being designed for interactive usage as well as application development. Interactive means you load a structure in a notebook or the bundled GUI and look at something. Application development means you write a pipeline that does the same analysis across a set of proteins.

The repository is also a mature research project rather than a weekend library: it has a code of conduct, a contributing guide, a readthedocs configuration, a docs/ directory, an environment.yml, a Makefile with developer targets and both a setup.py and a pyproject.toml, and the pyproject classifiers mark it as Development Status :: 5 - Production/Stable.

The subpackage layout maps onto the science

ProDy's module list is the clearest statement of what it covers, and the subpackages are named after the physical concepts rather than after file formats.

prody.atomic handles the Atomic objects, including AtomGroup and Selection. That is the data model layer, and everything else in the package operates on those objects.

prody.dynamics is the core. It provides normal mode analysis with the various elastic network models, principal component analysis, SignDy under prody.dynamics.signature, hybrid methods under prody.dynamics.clustenm, allosteric signal propagation under prody.dynamics.perturb with the PRS method, and calcHitTime for Markovian hitting time. The signal propagation part is the one that goes beyond mechanics into something that reads like a network: perturbing one residue and asking which other residues are affected first.

prody.proteins covers parsing. It handles PDB, mmCIF, MMTF and maps, along with tools to align and compare structures. The analysis of interactions within and between proteins lives in prody.proteins.interactions as InSty, and finding water bridges is prody.proteins.waterbridges as WatFinder.

prody.ensemble builds heterogeneous structural ensembles for exploring dynamics from experiments and simulations. prody.sequence holds the sequence alignment and evolutionary analysis tools of Evol, which is the package ProDy absorbed, and the 2014 paper explains the pairing: sequence evolution and structural dynamics as two views of the same constraint landscape.

The smaller subpackages fill in the edges. prody.chromatin is specific to chromatin dynamics as ChromDy, with prody.chromatin.hic and prody.chromatin.cluster. prody.compounds parses small molecule compounds and ligands from the PDB and related databases. prody.domain_decomposition does dynamical domain decomposition as Spectrus. prody.trajectory handles trajectories in DCD format. prody.utilities holds the shared helpers, and prody.database interfaces with CATH, DALI, UniProt and Pfam.

For a user, this layout tells you the shape of the work: pick the physical question, use the matching subpackage, and let prody.atomic carry the structures between them.

Installing: conda-forge first, Git clone when you want the fixes

The README recommends downloading and installing the Anaconda package manager to handle dependencies in controlled environments, and the command for that is:

conda install -c conda-forge ProDy

The reason for preferring conda over pip is visible in the dependency list in pyproject.toml. The runtime dependencies are numpy>=1.10, biopython, pyparsing<=3.1.1 and scipy, and the upper pin on pyparsing is the kind of constraint that is much easier to satisfy inside a managed environment than in a shared system interpreter.

For the most recent fixes the README says to install from the source on GitHub. The clone is:

git clone https://github.com/prody/ProDy.git

And then, from inside the ProDy directory, the build and install commands as the README writes them:

cd ProDy  
python setup.py build\_ext \--inplace \--force  
pip install \-Ue .

There is more detail at the download and development manual pages the README links, under bahargroup.org/prody.

Two constraints are worth stating before you start. The pyproject requires-python field says >=3.10, with a comment that it is based on the logic in setup.py, so an older interpreter is out. And the build compiles C extensions, so a C toolchain is required, which the README's note on the hpb module confirms by calling for a C++ and Fortran compiler.

The Makefile gives you the same build in a shortcut form, with a build target and a separate build3 target for a Python 3 interpreter:

build:
	python setup.py build_ext --inplace --force

build3:
	python3 setup.py build_ext --inplace --force

There is also a test target that clones the repository into a temporary directory, builds the extensions there and runs the test suite against that copy, so the tests run against a fresh build rather than against whatever is installed in your environment.

The hpb module is a precompiled binary, and the setup script admits it

ProDy's hydrophobic interaction, solvent accessible surface area and volume calculations use geometric methods based on the atom information in the molecule. The README explains that the methods were programmed in C++ and compiled as a Python module named hpb.so, which ProDy then uses.

The source for that compilation lives in prody/proteins/hpbmodule and needs both a C++ and a Fortran compiler. The README also mentions precompiled versions for Python 2.7, 3.8, 3.9 and 3.10, and says the compiled hpb.so can be stored either in the prody/proteins folder inside ProDy or in the local directory used for the calculations.

That last part is where the setup.py becomes worth reading closely, because the build script does something unusual. It computes a platform-specific directory name from the running interpreter, hpb_Python followed by the major and minor version, looks for a precompiled hpb.so inside that directory under prody/proteins/hpbmodule, and copies it into the prody/proteins folder if it is not already there. A missing precompiled file is tolerated, with a comment saying it is okay if the precompiled file does not exist for this platform.

The setup.py itself carries a comment that is worth quoting for its candour: distributing pre-compiled binaries like this is not standard practice, it would be better to compile this from source as part of the build, however this preserves the original behavior of your script.

That is a fair summary of the trade. You get a working hydrophobic interaction calculation on a platform the project happened to build for, without a compiler, at the cost of shipping a binary that your Python did not compile and that you did not build. If you are installing from source and you have a compiler available, compiling it yourself is the cleaner path, and the Makefile build target does exactly that.

The rest of the extension set is compiled normally from C sources, with numpy's include directory supplied: prody.dynamics.rtbtools and prody.dynamics.smtools for the dynamics routines, and prody.sequence.msatools, prody.sequence.msaio and prody.sequence.seqtools for the sequence tools.

Bundled dependencies and the licence picture

The LICENSE section in the README is not a single line, and the reason is that ProDy ships third party code inside its own tree.

ProDy itself is MIT licensed, with LICENSE.txt for details, and the pyproject records it as license = { text = "MIT License" } with the OSI approved classifier. That is a permissive grant with no copyleft obligation on code you build with it, which is a licensing note rather than legal advice.

The bundled components each keep their own terms. The KDTree and TreeConstruction modules come from Biopython and carry the Biopython licence. The pyparsing module is distributed with ProDy under the MIT licence. The CEalign module was originally developed by Shindyalov and Bourne, and the Python version ProDy uses was developed by Jason Vertrees under the New BSD licence.

That is a well handled situation rather than a problem, and it is worth noting how it is handled. Vendored code with its own licence and attribution is the normal pattern for scientific packages that need a KD tree or a parser, and the alternative, a hard dependency on Biopython for two modules, would be worse for users.

The repository listing classifies the licence as a custom one that GitHub cannot classify, with a note to see the LICENSE file. The top level entries include LICENSE.rst, and the README points to LICENSE.txt, so the terms are in the repository under two names. That is a small inconsistency, and it is the kind of thing worth confirming by reading the file rather than assuming which one governs.

The dependency pin on pyparsing at 3.1.1 or earlier is the other detail in this area. The remove target in the Makefile deletes prody/atomic/pyparsing*.py alongside the other contributed modules, which suggests the vendored copy is kept in step with the pinned version rather than being an independent fork.

Where ProDy is the wrong tool

The first limit is what it does not do. ProDy reads and analyses structures; it does not run molecular dynamics. If your question is what a particular protein does over a microsecond, you need a simulation package and ProDy is not a substitute, though the README's ensemble module notes that ensembles can be built from simulations, so the two sit side by side rather than in competition.

The second limit is the resolution of the model. An elastic network model replaces each residue with a single node, so side chain detail is gone and the model captures the soft, collective motions of the backbone rather than local chemistry. That coarseness is the point, and it is also the boundary: questions about specific contacts, catalytic residues or protonation states are not what these models answer.

The third is the precompiled binary discussed above. For an institution that audits every binary in its environment, a setup script that copies a prebuilt shared object into the installed package is a review item. It is disclosed in the source, which is better than a hidden download, but it is still a binary you did not compile.

The fourth is the documentation split across several hosts. The homepage, tutorials, reference manual, applications guide, NMWiz GUI page and release notes all live under bahargroup.org, with a separate ProDy-website repository linked for the latest versions, plus readthedocs. Anyone building a reproducible analysis pipeline should capture the version it ran against, because the release notes page is the only changelog.

The alternative to weigh is Biopython, which ProDy already depends on for its KD tree. Biopython is the general purpose sequence and structure toolkit, with its own parsers and its own structure alignment, and it is the right choice if your work is sequences and structures rather than dynamics. The difference in approach is that Biopython treats a structure as data to be manipulated, while ProDy treats it as a mechanical system whose soft modes can be computed. If you want normal mode analysis, Gaussian network models, signal propagation or the Evol co-evolution tools, ProDy is where those live and Biopython will not get you there.

Editorial conclusion

Adopt ProDy if your research involves elastic network models, Gaussian network models, PCA of conformational ensembles or sequence co-evolution and you want those analyses in Python rather than in a separate tool. Do not adopt it for general molecular modelling or MD simulation, since it reads and analyses structures rather than simulating trajectories, and treat the hpb.so binary carefully, because setup.py ships a precompiled shared object instead of compiling it on your machine. Verify first that your Python is 3.10 or newer, that the hpb precompiled file matches your interpreter, and that the C and Fortran compilers are present if you intend to build the extension from source.

Frequently asked questions

Official sources

1. Issues
2. prody/ProDy on GitHub
3. Project website
4. README
5. Releases