Exotic ligands generated

Hi,

I basically followed the protein-conditioned CLI example using a manual install on Linux Mint 22.2. Protein: 4N1U.pdb, chain A, all waters and ions deleted, ligand saved separately as reference SDF (from PyMOL). MTH1 is a very druggable target with many cocrystal structures published.

(omtra) evehom@mjolnir:~/Data/Sandbox/omtra$ omtra --task fixed_protein_ligand_denovo_condensed   --protein_file MTH1_4N1U_noH.pdb   --ligand_file MTH1_TH588.sdf   --n_samples 50   --output_dir outputs/MTH1_4N1U_noH_TH588
/home/evehom/Programs/miniconda3/envs/omtra/lib/python3.11/site-packages/lightning_fabric/utilities/cloud_io.py:73: You are using `torch.load` with `weights_only=False` (the current default value), which uses the default pickle module implicitly. It is possible to construct malicious pickle data which will execute arbitrary code during unpickling (See https://github.com/pytorch/pytorch/blob/main/SECURITY.md#untrusted-models for more details). In a future release, the default value for `weights_only` will be flipped to `True`. This limits the functions that could be executed during unpickling. Arbitrary objects will no longer be allowed to be loaded via this mode unless they are explicitly allowlisted by the user via `torch.serialization.add_safe_globals`. We recommend you start setting `weights_only=True` for any use case where you don't have full control of the loaded file. Please open an issue on GitHub for any issues related to this experimental feature.
Warning: no wandb run found. Setting previous sample counts to 0.
WARNING: temporarily disabled loading crossdocked tuples
Saving samples to /home/evehom/Data/Sandbox/omtra/outputs/MTH1_4N1U_noH_TH588

What intrigues me is that a few ligands actually look quite good, similar to known MTH1 inhibitors, but many others I would not dare to show to a synthetic chemist (weird ring systems, too many chiral centers, featureless etc.). Below the output in smiles, where I indicated the ones that look OK as such:

OC@H[C@@h]1O
CCOc(cc(cc1N(CCC[C@H]2O)[C@@]2(C)c2nc(cccc3)c3[n]22)O)c1C2=O
NC(c(cccc1)c1O[C@]1(CCC2)Oc(cccc3)c3O[C@H]1[C@H]2O)=O
CC(C)Oc1c(N(CC@@H[C@H]3N[C@@h]2C2)[C@H]2[C@H]3[n]2c(cccc3)c3nc2)nccc1
CCCOC@@Hc1cc(O)ccc1
NC(c1nc(C2CC2)n[n]1-c(cc1)ccc1F)=O
CCOc1nc(N)nc(C2CCCCCC2)c1 # looks OK
CC@HN[C@H]1c(cc1)cc(C)c1O
CN(C)c(cc(cc1)C(/C2=C3\C(OC)=C\3/C=C[C@@h](c3c4ccc(O)c3)\C/4=C/22)=Nc([o]c3c45)c4c/2nnc5NC=C3O)c1OC
CC(C)(C)c1nc(CCCC2)c2[n]1-c1c2OCOc2ccc1
CC(C)(C)C(N(C)c1c(CCC@HOC)c2c3[o]1)=O
Cc(c(O)ccc1)c1Oc1nc(C2CNNC2)nc2c1cccc2
CC1(C)c(ccc(N(C2=O)c(cccc3)c3S(Nc3ccccc3)(=O)=O)c3[C@]2(c(cccc2)c2N+=O)O)c3-[n]2c1ccc2
CCC(c(cc(cc1)OC)c1Oc(cccc1)c1Cl)=O
OCH(C(C(C(C(F)(F)F)(F)F)(F)F)(F)F)C(C(F)(F)F)(F)F.F.F
Nc1nc(cc(cc2)Cl)c2c(-c(ccc(F)c2)c2Cl)n1
C[C@@]1([C@@h]2OCCC1)OC@(c3c1cccc3)c(c(O)c1)c2cc1O
CC1(C)Oc(c(C)c(-c(cc2)cc(OCCN(C)C)c2O)[n]2[C@@h]3NCCC[C@@h]3O)c2OC1
Nc1nc(cc(cc2)Cl)c2c(-c(cccc2)c2Cl)n1 # looks OK
FC(C(C(F)(F)F)(F)F)(C(C@(C1(F)F)F)(F)F)F
CC(C)C(C(N(Cc(cccc1)c1Cl)c(cc1)c2cc1O)=O)=C2O
CC(c(ccc(OC)c1)c1-c1cccc2c1cc[s]2)=O
C[C@@]1([C@]2(C)Oc(cc(cc3)O)c3C(C(c(cccc3)c3N(C)C)=O)=C2CCC1)O
OC@@([C@@h]2C[C@H]1C1(F)F)[C@@h]1c1c2c(cccc2)c2nc1-c1cccc2c1cccc2
COc(cc(cc1)O)c1-c1c(C2CCNCC2)c(cccc2)c2[o]1
CCNS(c1c(C)ccc(C@(OC2)OC[C@H]2O)c1)(=O)=O
CC(C)Oc(c(C(OC)=O)cc(Oc(c1c2C@(C(C)(C)C3=O)C=C1)c14)c5-c(c6c7cccc6)c-1c1c7c(ccc(OC)c6)c6nc1-c4c2C3=O)c5O
CCOc1c(C@(N2O[C@@]3(c4cc(C@@HO)c5)O[C@H]3CC2(C)C)O)c4c5cc1-c1ccccc1
FC(C(F)(F)F)(C(F)(F)F)C@@(C1(F)F)F
COc1cc(-c2cc(Cl)c[s]2)nc(N)n1 # looks OK
CCC@@HOc2c1c(-c(cccc1)c1Cl)nc(N)n2 # looks OK
CC(C)c(c(N+=O)c(C@@(C1=O)c(cc1)ccc1N+=O)cc1)c1O
CCCCC[C@@h]1NC@H[C@]2(C)Oc3c(cccc4)c4c(-c4ccccc4)[n]3[C@H]12
CC@HOC@HO[C@@h]1nc2c1c(O)ccc2
CC(C)(C)c1cc(-c2ccccc2)c(C@([C@@]2(C)O2)O)c2c1O
CCCC@@(C@@HO)c1c2O
CC@HC@@HOc2c1cccc2
OCC@([C@@h]1C1)[n]2c(ccc(O)c3)c3nc2[C@@h]1c1c[s]c2c1cccc2
C[C@@h]1C@HOC@@HOC1
CC(C)(C)c(cc1)cc(C@([C@H]2O)C2=O)c1N2c1cc(O)cc2c1cccc2
NC(c1cc(Br)cc(F)c1N1CCOCC1)=O
CCCC@HCCO
OC@@(C(C(C(C(C(C(C(F)(F)F)(F)F)(F)(F)F)(F)F)(F)F)(F)F)(F)F)C(F)(F)F.F.F
C[C@@h]1c(cc(cc2)-c3nc(cccc4)c4c4c3CC(CO)(CO)O4)c2OC1
OC[C@@h]1SC@Hc(cc2OCOc2c2)c2O1
O[C@@h]1c(cccc2)c2C(OC@@Hc(cccc2)c2Cl)=N[C@]1(C(C(F)(F)F)(F)F)C(F)(F)F
CCCCSCCC
CC(C)c1cc(C@HNC[C@@h]2O)c3c5c1
CC@HC[C@@h]1[n]1c(-c2c(C)[o]c3c2cccc3)nc2c1cccc2
CCS(c(c(O)ccc1O)c1Nc1c(-c(cc(cc2)O)c2O)c(O)c(C(C)(C)C)cc1)(=O)=O

BW/Evert

[UnixJunkie]

@Evert-Homan : you could remove ligands w/ rings never seen (or too infrequently) in ChEMBL.
Also, you could filter the generated molecules by a target property profile.

Yes, that is the easy answer. Another (and imo better) answer is that such bizarre structures should be removed before training AI models. To be honest I don't believe in these diffusion-type approaches, I think it is better to generate de novo molecules based on robust reactions and reactant catalogues, essentially sampling on-demand space. Then you can be almost certain you get reasonable molecules that you actually can make.

[Dunni3]

Hi Evert,

I would appreciate it if we could separate the discussion of this particular issue from our opinions about the field of molecular generative models writ large. I am more than happy to have that discussion; but lets not conflate a small, model-specific issue with statements about the utility and potential of an entire field of research.

Your statement "such bizarre structures should be removed before training AI models" implies the current issue is caused because the model was explicitly trained on such unusual ligands. This is an incorrect assumption and not the cause of the present issue.

The Problem

The reason some of the ligands are bizarre is, in short, because we are sampling ligands with too many or too few atoms for the given pocket. OMTRA (and essentiallly all diffusion/flow-based models) require that we pick the number of ligand atoms there will be before we sample the structure/identity of that ligand. OMTRA does not have the ability to add or remove ligands while sampling.

If the number of ligand atoms added to the system is too many or too few, the model will produce poor quality samples because we are trying to sample in a space that is by construction "out of distribution" from what the model sees at train time.

So we must manually define some method for choosing the number atoms in our designed ligands. The default behavior of the command line (which is what you were using) is to sample the marginal distribution extracted from the training data of P(N ligand atoms | N protein pocket atoms). Unfortunately, this is a rather rudimentary way of approximating the likely number of ligand atoms. We end up with a distribution that has a large variance; as a result, we end up sampling ligand atoms that are too large and too small. I've plotted the distribution of the number of ligand atoms below.

The current solution

For now, I recommend to constrain the number of ligand atoms to be very close to the reference ligand provided at the command line. This can be done via these CLI options:

• --use_gt_n_lig_atoms: a binary flag that, if set, means we will sample the number of ligand atoms from a narrow, uniform distribution centered on the number of atoms in the reference ligand
• --n_lig_atom_margin: This controls the width of the uniform distribution. If the number of atoms in the reference ligand is N, then the number of atoms in designed ligands will be sampled uniformly between (1 - n_lig_atom_margin)*N and (1+n_lig_atom_margin)*N.

Some data to support the claim

I sampled 50 ligands with the default command line behavior, and another 50 ligands with the additional arguments --use_gt_n_lig_atoms --n_lig_atom_margin=0.1

First, lets look at the distributions of the number of heavy atoms in de novo designed ligands, under these two sampling settings:

As you can see, the default CLI behavior gives ligands substantially larger and smaller than the ground-truth binder. Moreover, the particularly unusual ligands obtained via default CLI sampling are mostly from the tails of the distributions.

Below I am showing 3 collections of sampled molecules. The first two are the 10 smallest and largest molecules obtained from the default CLI sampling. The 3rd collection is 15 random molecules from the 50 that we sampled with --use_gt_n_lig_atoms --n_lig_atom_margin=0.1.

For reference, here is the ground-truth ligand:

As you can see, controlling the number of ligand atoms gives much more reasonable de novo designed ligands.

Here are some 3D examples where we can see some reproducible SAR and alingment with the ground-truth functional group arrangement:

Conclusion, Short-Term Solutions.

The current solution is to basically manually control the number of ligand atoms to make sure it is plausible for the given protein pocket being designed against. The easiest way to do this is to use the --use_gt_n_lig_atoms flag on the CLI and pass a reference ligand.

Obviously, this is less than ideal. For example, what if the user doesn't have a ligand to use as a reference? You could, in theory, try sampling with a variety of different ligand sizes, identify the sizes that give the highest quality ligands, and then perform more sampling in that narrow range. This is process is more manual and compute intensive than we would like.

I also don't think we exposed a CLI argument to just manually set the mean number of atoms. This is easy and would be useful. I can do it shortly.

Also, now that I am thinking about it, the CLI doesn't enable computing metrics that we usually use for filtering/ranking designed ligands. Its already implemented for the web application interface so it should be relatively simple to do at the CLI too.

Long-term Solutions

There are alternative solutions that aren't implemented yet / are the subject of active research. For example:

1. A generative model that can add and remove atoms as necessary to get high quality samples
   • In my previous work, FlowMol3, I demonstrated that having a removable atom type, "fake atoms", improves model performance. We implement fake atoms in OMTRA but, for reasons we have not yet determined, the model fails to actually use this feature to adjust atom count in the context of a protein pocket. (fake atoms works fine without a protein pocket).
   • There is some exciting new work in enabling insertions/deletions at the level of the generative modeling formulation, rather than our "fake atoms" method which is hacky and imperfect. It is on our to-do list to implement something like branching flows from @murrellb 's research group . But it is just one of many items on the to-do list :)
2. A simpler hold-over solution is to implement a more accurate method to approximate the number of ligand atoms without having access to a ground-truth binder.
   • I was thinking about using pocketeer to detect pocket structure/volume and feed this into a simple supervised learning model to predict the number of atoms.