EPR Toolbox
•

MMM individual rotamer PDBs

This feature has been removed from the EPR toolbox as of version 12.9, due to MMM 2011.2 directly implementing this feature. This page remains for information purposes only. Feature implemented in EPRtoolbox

MMM by default saves calculated rotamers as a rotamer library PDB. This when viewed within PyMOL causes a bit of a problem as you’ve now lost the protein to which the rotamers are supposed to be attached.

Using scripts not distributed with MMM provided by Yevhen Polyhach and Gunnar Jescke, you can make instead make MMM output each rotamer as an individual PDB with the spin label attached to the protein.

WARNING: using this script will fill up your hard drive very quickly For your convenience I’ve created an installation script for the non-standard scripts, which is included in the EPRtoolbox.

This will copy the original MMM files to a backup folder (your_MMM_path/old_files) and then install the new ones. An uninstall script is also included if you wish to restore MMM back to it’s fresh install state.

Now when you select your residues in the Site Scan Window select “No Rotamer Populations” checkbox

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

[^1:] http://morganbye.net/mmm-individual-rotamer-pdbs [^2:] http://morganbye.net/eprtoolbox/mmm-individual-rotamer-pdbs) [^3:] http://morganbye.net/uncategorized/2011/04/mmm-individual-rotamer-pdbs

Older post

cw Normaliser (cwnorm)

Newer post

Peakfinder

Further reading for leaders

Explore the archive

EPR Toolbox
•

EasyRefiner

Faced with fitting well over 30 experiments at room and low temperature at multiple frequencies, as all of my experiments are spin-labelled mutants of the same protein then surely their EPR properties would be similar. I decided that there must be a …

EPR Toolbox
•

e2af

E2AF or “EPR 2 ASCII folder” is a folder version of E2A, whereby a folder of Bruker EPR files are converted to ASCII data files (readable by any operating system), by default the conversion is to *.csv files (comma separated values). …

EPR Toolbox
•

Savitzky-Golay - sgol

The Savitzky-Golay smoothing function essentially applies a local polynominal fitting routine to a series of data points to then find the smoothed data points. This has the benefit that for sharp intense peaks (common to EPR) that the line broadening …

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.