PyMOL visualising binding interfaces

Today I’ve been trying to come up with a nice way of visualising the binding interface between protein-protein or protein-DNA complexes. What follows is a quick little walk-through mostly for my own purposes so that I can remember what I’ve done in the future.

Download PDB file from pdb.org, here XXXX will be your PDB accession code.

Point a terminal window at the download directory

1
cd ~/Downloads

Run CCP4:

1
2
3
4
5
6
7
ncont XYZIN XXXX.pdb >> XXXX.ncont << eof

source A              [or whatever your protein chain is]

target E,F             [or whatever the DNA chains are]

eof

This will give us a file XXXX.ncont in the Downloads folder which contains all the information about the binding interface

Download the PyMOL script for converting CCP4 (*.cont) files: ccp4_ncont.py

Now in PyMOL, load the CCP4 interuptation script

1
run ~/Downloads/ccp4_ncont.py

Load the file using File -> or:

1
load ~/Downloads/XXXX.pdb

Manipulate the file to something presentable

In command line type:

1
ccp4_ncont ~/Downloads/XXXX.ncont, selName1=prot, selName2=DNA

This gives us all of the atoms and residues involved in binding as useful objects (right hand side of the Viewer Window)

Now we can visualise things a bit better.

1
select dsDNA, chain E+F

This selects chains E and F and creates an object called dsDNA. On this object, hide everything, they we can set about visualising the thing better:

1
2
3
4
show_as cartoon, dsDNA
set cartoon_ring_mode, 3
set cartoon_ring_finder, 1
color green, dsDNA and elem C

For other styles see the Pymol wiki

Now we can work on the protein and show the residues at the binding interface

1
2
show sticks, prot_res
color gray60, plot_res

Or select the object and click C (for Color) then “by element”

And then adjust the Carbon colour to the desired using

1
color gray60, elem C

Replacing gray60 with your chosen colour

Currently we have a pretty good stick diagram, but a delicate ball and stick model looks more professional

1
2
3
set stick_radius, 0.1
show spheres, prot_res
set sphere_scale, 0.15

So our balls of the ball and stick are now present, but to make these more presentable we need to improve their quality when we render

1
2
set sphere_quality, 4
set stick_quality, 16

As the figure grows in complexity it maybe required to turn ray shadows off

1
set ray_shadow, off

I’ve also recoloured the DNA bases using

1
color green, dsDNA+ elem C

Now we can add Van der Waal radii of the key atoms to emphasize the binding interface.

1
2
show dots, prot_atom
show dots, dna_atom

Optimise the viewing angle using:

1
orient dsDNA

And then use the mouse-wheel to move the transparency of the background, so that the emphasis is in what want to see and the background does not distort it

Finally, to show the co-factor (here it is Mg, in light green) I show it as a Sphere but as we’ve changed the spheres for the ball and stick model we need to:

1
2
alter elem mg, vdw=10.0
rebuild

And dont forget to ray for pretty pictures


This page previously appeared on morganbye.net[^1][^2][^3]

[^1:] http://morganbye.net/pymol-visualising-binding-interfaces [^2:] http://morganbye.net/2012/02/pymol-visualising-binding-interfaces) [^3:] http://morganbye.net/uncategorized/2012/02/pymol-visualising-binding-interfaces/

How do you define successful engineering leadership?

The Philosophy

Many view technical leadership as being the “smartest architect in the room.” I see it as the opposite. My job is to build a room where I don’t have to be the smartest person because the systems, culture, and communication are so robust that the team can out-innovate me.

The Strategy

  • Alignment: Does every engineer understand how their sprint task impacts the company’s bottom line?
  • Velocity vs. Stability: We aren’t just “shipping fast”; we are building a predictable, repeatable engine that doesn’t collapse under its own weight at the next order of magnitude.
  • The Human Growth Curve: Success is when the engineering team’s capability evolves faster than the product’s complexity. If the team feels stagnant, the tech stack will soon follow.

What is your approach to scaling technical organizations?

The Philosophy

Scaling isn’t just “hiring more people” - that’s often how you slow down. Scaling is about moving from Individual Heroics to Organizational Systems.

The Strategy

  • The 3-Continent Perspective: Having managed global teams, I focus on “High-Signal Communication.” As you grow, the cost of a meeting triples. I implement “Asynchronous-First” cultures that protect deep-work time while ensuring no one is blocked by a timezone.

  • Modular Autonomy: I advocate for breaking down monolithic teams into autonomous units with clear ownership. This reduces the “communication tax” and allows us to scale the headcount without scaling the bureaucracy.

  • Automation as Infrastructure: At petabyte scale, manual intervention is a failure. I treat the developer experience (CI/CD, observability, self-service infra) as a first-class product to keep the “path to production” frictionless.

How do you balance high-growth velocity with technical stability?

The Philosophy

Technical debt isn’t a “bad thing” to be avoided; it’s a set of historical decisions that no longer serve you. Like any loan, leverage can accelerate growth when investments payoff. But if velocity and returns are slowing you need a payment plan before the interest kills you.

The Strategy

  • The ROI Filter: I don’t refactor for the sake of “clean code.” I don’t refactor a micro-service with no users. I refactor when the pain on that debt - measured in bugs, downtime, or developer frustration - starts to exceed the cost of the fix.

  • Zero-Downtime Culture: Especially at scale, stability is a feature. I implement “Guardrail Engineering” where the system is designed to fail gracefully, ensuring that a Series B growth spike becomes a success story rather than a post-mortem.

  • The 70/20/10 Rule: I typically aim to dedicate 70% of resources to new features, 20% to infrastructure/debt, and 10% to R&D. This ensures we never stop innovating, but we never stop fortifying either.