[WIP] `transformations` by JenkeScheen · Pull Request #26 · omsf/openplaceholder

JenkeScheen · 2026-07-01T09:57:46Z

Given selected Structures (one per ligand query), do the following transformations:

pick a reference protein conformation to be used from here on (best practices: largest ligand volume)
prepare protein (fix missing residues, heavy atoms, loops etc)
protonate protein and ligand (propka and dimorphite-DL, resp.)

side-track: also adding the full n=16 TYK2 set from the OFE industry benchmarks

JenkeScheen · 2026-07-02T13:24:30Z

another side-track (sorry): while running TYK2 through the pipeline again, I ran into a pose that RDKit could not restore bond orders for because the connectivity was too wonky. I added a validator that catches this in a7324a3

JenkeScheen · 2026-07-02T13:25:36Z

@ianmkenney ready for a first look, in the meantime I'm just running TYK2 with this newest pipeline to see if it all works out.

JenkeScheen · 2026-07-02T13:30:02Z

note that given a ligand series, there might be multiple net charges. Traditionally you would solve this by:

split the ligand series into a group per net charge
run an AlchemicalNetwork for each group
estimate DDGs for each group
run MLE for each group
merge group DGs back together

But this is a bit finnicky to set up robustly. OFE supports charge-changing transformations now, so we should just allow these for now -- it saves us from having to do the split/merge. We will need to 1) warn the user 2) make sure that in mapper there are enough edges between different charge state sections of the resulting network.

ianmkenney · 2026-07-02T15:14:52Z

+    forcefield: str = "AMBER"


 class MaxVolumeSiteTransformation(Transformation):


There is a lot going on in this transformation. I would intuitively expect that this only alters the structures based on ligand volumes but it also alters charge state. We are able to stack transformations.

addressed by the split + explicit single-Structure helpers in ef4f9f5

ianmkenney · 2026-07-02T15:21:55Z

+            out = Path(tmp) / "merged.pdb"
+            merged.atoms.write(str(out))
+            data = base64.b64encode(out.read_bytes()).decode()
+        return Structure(


enforces that the structure is always PDB after transformation even if the original structure was something else.

addressed in ef4f9f5

ianmkenney · 2026-07-02T16:15:15Z

    def _setup(self) -> None:
        pass

    def _transform(self, structures: list[Structure]) -> list[Structure]:


Tracing the execution path here is tricky and make futures maintainability difficult. The function names don't capture their actual behavior and they share too much responsibility.

Specifically, _prepare and _protonate silently rely on the correct ordering of the input sequence, and _prepare only operates on a single structure despite accepting a list.

We should rewrite this to be more explicit and decoupled. Something like this would be cleaner:

def _transform(self, structures) -> list[Structure]: chosen_complex = self._select_complex(structures) other_structures = [s for s in structures if s != chosen_complex] fixed_protein = self._fix_protein_heavy_atoms(chosen_complex) protonated_protein = self._protonate_protein_context(fixed_protein) ...

Additionally, we should try to minimize when we write to disk. Aside from performance benefits, using the io module will narrow the classes of exceptions we might run into, like running out of space in /tmp/. I think the only place we fully need disk IO would be with pdb2pqr.

addressed in ef4f9f5

ianmkenney · 2026-07-02T16:20:41Z

+    )
+
+
+class TestMaxVolumeSiteTransformation(TestCase):


Good start but will need more

added some more in ef4f9f5

…stead.

JenkeScheen · 2026-07-09T09:12:16Z

propka turns out not to be a suitable direction because it only predicts pkas and there is no turnkey solution to actually using those predictions to protonate the whole complex in one go. Instead we'll go with what's been built in protonate-utils and leave the separate protein and ligand protonation methods as interchangeable modules. This does present a new problem though, because these are separate protonators there may be 'clashes' in the form of e.g. hbond donor-donor interactions between the ligand and the protein. We'll use prolif and some internal heuristics to find and fix them.

JenkeScheen · 2026-07-09T14:17:58Z

@ianmkenney can you have another look? this PR has become too inflated at this point imo

…ucture class

ianmkenney

I think we need to look again at how these transformations fit into the overall pipeline and how they should be stacked.

Given a pre-validated set of structures, we first apply MaxVolumeSiteSubstitutionTransformation (or whatever we would call it), where the "canonical structure" is immediately substituted into all other structures. From there we can apply the ProteinPreparationTransformation. By caching, we can avoid redoing the extra N-1 calculations. We then apply the ComplexProtonationTransformation. This completely removes the need to keep track of an implicit structure ordering dependency.

ianmkenney · 2026-07-09T14:58:36Z

+            structures
+        )
+
+        self.assertEqual(len(structures), 1)


I'm not sure how much this is adding over individual transformation tests. You could remove the MaxVolumeSiteSelectionTransformation.transform call everything would still pass. Both of your final asserts are targeted to a single transformation but the way it's written doesn't attribute the change to either of the function calls.

ianmkenney · 2026-07-09T15:02:07Z

+
+        selected = transformation.transform([small, large])
+
+        self.assertEqual(selected[0].ligand_name, "large")


why do we expect a reordering of structures after a transformation?

oh I see now...

ianmkenney · 2026-07-09T16:13:21Z

+                        atom.name,
+                    )
+                    continue
+                clashing_h = min(p_hs, key=lambda i: float(np.linalg.norm(p_xyz[i] - l_xyz[l_heavy])))


It seems to me that this could strip a neutral lysine down to a single hydrogen by mistake.

ianmkenney · 2026-07-09T16:22:31Z

These should probably be in the ComplexProtonationTransformation class as methods instead of individual classes.

ianmkenney · 2026-07-09T16:24:24Z

I'd say hold off on doing this type of abstraction until we know we need it. As some of the other comments go over, most of this behavior should probably be packaged into the ComplexProtonationTransformation class. There may come a day when we add more implementations and something like this will be helpful.

ianmkenney · 2026-07-09T16:33:15Z

As stated in other comments, not sure this subpackage is needed.

ianmkenney · 2026-07-09T16:34:14Z

I feel like this should all be part of the ComplexProtonationTransformation class.

ianmkenney · 2026-07-09T16:35:01Z

Let's go over some of the logic here in our next sync

ianmkenney · 2026-07-09T16:40:57Z

+logger = logging.getLogger(__name__)
+
+
+def _perceive_ligand(structure: Structure) -> Chem.Mol | None:


This is called in multiple validators. In a new PR I'll have this called in the parent class and cache the results.

ianmkenney · 2026-07-09T17:09:08Z

+opt into only the stages they want -- e.g. prepare without protonating, or
+protonate a set that was selected elsewhere.
+
+Ordering contract: **index 0 is the canonical protein context.** The selection


We should not use order dependence here.

ianmkenney · 2026-07-13T13:21:18Z

+            out_file = pdb_io.PDBFile()
+            out_file.set_structure(structure)
+            out_pdb = Path(tmp) / "protein_h.pdb"
+            out_file.write(str(out_pdb))


Can this be done in-memory?

ianmkenney · 2026-07-13T13:28:52Z

Don't do ordering, stick to duplication of effort. We can handle it in a later PR with caching.

…ection

…t does it correctly.

JenkeScheen added 2 commits July 1, 2026 13:27

protein prep and protonation and volume selection

f760ba6

ligand protonation with dimorphite-DL instead of RDKit

4d23e35

JenkeScheen force-pushed the feat/transformations-first-steps branch from 03f8080 to 4d23e35 Compare July 1, 2026 11:36

JenkeScheen added 2 commits July 1, 2026 13:54

add full tyk2 set of n=16

0126538

add rdkit perceive validator

a7324a3

JenkeScheen requested a review from ianmkenney July 2, 2026 13:25

ianmkenney requested changes Jul 2, 2026

View reviewed changes

Merge branch 'main' into feat/transformations-first-steps

cbe4c16

JenkeScheen mentioned this pull request Jul 7, 2026

[DNM] Tyk2 trailblazing 2 #34

Open

propka is not going to cut it -- build with hydrite and dimorphite in…

940ff6c

…stead.

JenkeScheen added 2 commits July 9, 2026 11:21

reconcile possible hbond faults

c8c8b88

handle review comments

ef4f9f5

refactor a bit, move Structure operations mostly to in/around the Str…

725b7bf

…ucture class

ianmkenney requested changes Jul 9, 2026

View reviewed changes

ianmkenney reviewed Jul 13, 2026

View reviewed changes

Comment thread src/openplaceholder/impl/protonation/reconcile.py Outdated

ianmkenney reviewed Jul 13, 2026

View reviewed changes

JenkeScheen added 8 commits July 14, 2026 14:38

break out reconciler -- too complicated

412548c

protonate across the array -- will cache this later

82a4dab

migrate all protonation code to transformations

ed22b4e

keep in memory instead

4c261f7

move vendored code

643550f

improve testing

84c28ea

force rdkit to write LIG as resname; do role-based default ligand sel…

abc6932

…ection

add test for the previous commit

7ed98bd

JenkeScheen added 4 commits July 14, 2026 17:02

fix CI

740f6e8

be quiet

f74da15

handle protonated structures more delicately - don't assume that rdki…

4dca655

…t does it correctly.

keep hydrogens post-generation if present (theyre not atm)

4db9506

		forcefield: str = "AMBER"


		class MaxVolumeSiteTransformation(Transformation):


		selected = transformation.transform([small, large])

		self.assertEqual(selected[0].ligand_name, "large")

		logger = logging.getLogger(__name__)


		def _perceive_ligand(structure: Structure) -> Chem.Mol \| None:

Uh oh!

Conversation

JenkeScheen commented Jul 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

JenkeScheen commented Jul 2, 2026

Uh oh!

JenkeScheen commented Jul 2, 2026

Uh oh!

JenkeScheen commented Jul 2, 2026

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

JenkeScheen commented Jul 9, 2026

Uh oh!

JenkeScheen commented Jul 9, 2026

Uh oh!

ianmkenney left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

JenkeScheen commented Jul 1, 2026 •

edited

Loading

ianmkenney left a comment •

edited

Loading