Linux Pymol
•

PyMOL visualising e2 rotamers

This morning whilst writing some reports I wanted to show some rotamer populations of my spin label attached to the protein. Whilst MMM provides visualisation, and having had discussions with Jeschke I understand just how difficult it is to do, I do not consider them to be of publication standard. For this reason I needed to come up with something.

So first up do all the calculations in MMM as per normal but make sure you save your statistics.

Then load the protein PDB into PyMOL in the usual methods.

Once open load the MMM rotamers file using the File > Open menu; it should be something like rotamers__PDB-ID__CHAIN__MODEL_RESIDUE_LABEL_TEMP.pdb

Rename the rotamer object to something more useful and user friendly

1

PyMOL> set_name rotamers__PDB_ID__CHAIN__1_AA_LABEL_TEMP,rotamers

Now hide everything

1

PyMOL> hide *

Show the protein as a cartoon

1

PyMOL> show cartoon

Select the rotamer library and show it as sticks

1

PyMOL> show stick, rotamers

Now hide rotamers with an occupancy of near zero; ie less than 3%, but experiment until you get a sensible number on screen normally in the range of 1-5 %

1

PyMOL> hide stick, q <0.03

Now we make nice ball and stick models by shrinking stick radius, turning on spheres and setting their size to quite small. Remember to change the hide sphere line to match the number in the hide stick section

1
2
3
4
5

PyMOL> set stick_radius, 0.1
PyMOL> show spheres, rotamer
PyMOL> hide sphere, q <0.03
PyMOL> set sphere_scale, 0.15
PyMOL> set sphere_quality, 4

Hide the hydrogens

1

PyMOL> hide (hydro)

Add some transparency to the sticks so that all can be seen

1

PyMOL> set transparency, 0.2, rotamers

Colour the remaining rotamers according to their occupancy

1

PyMOL> spectrum q,rainbow,rotamer,0.03,0.10

This command uses: q is occupancy, rainbow is the colour palette (see built in colour bars or user generated ones), rotamer is the object to colour, and then we have minimum and maximum for range; if we leave these out then colouring is automatically set, usually between 0 and 1 which shows very little.

We still want to have the oxygen, nitrogen and sulphur coloured in their normal atom colours, so we now use

1

PyMOL> util.cnc

Don’t forget to ray your images to get all your shadows and rendering before you export your image.

Older post

Xepr license work around

Newer post

Misinterpretations

Further reading for leaders

Explore the archive

Technology Linux Backup
•

Logarithmic backups on a linux server

This is the second part of the lab server setup guide. Mainly for my own memory purposes, but if you find it useful then so much the better.

Synchronization

As previously discussed all of the machines in the lab are mounted onto the server using NFS …

Technology Linux Server
•

Lab server setup - Ubuntu 12.4

With a recent change of machines in the lab, I thought that I should update the backup server according to reflect the new machines. However, upon inspection the backup server OS hard drive had died long ago; but then what do you expect when you use …

Science Linux Pymol
•

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 …

LEADERSHIP, SCALE, AND THE HUMAN ELEMENT

Principles & Perspectives

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.