Do not forgive extra bonds by default (#347) - make it optional instead

[diogomart]

[rwxayheee]

After careful consideration, I still don't believe this can be addressed by simply adding an on/off option to forgive clashes at the template matching stage.
Handling of structures with clashes properly should require users to explicitly specify (manually or through an automated process) which bonds to forgive, or to directly assign the appropriate templates.
When clashes occur at link atoms, there is intrinsic ambiguity: whether to match the linked or unlinked form. Processing distorted or unprotonated structures directly is outside the current design scope. Doing this in applied projects is irresponsible.
Enabling more advanced bond correction & template matching might require bigger changes to the codebase. Therefore, I suggest listing this as a future enhancement or agreeing on a small, temporary fix if needed.

[diogomart]

Processing unprotonated receptor structures was one of the major goals, and still is.

This change would make what is currently default behavior, introduced very recently in #347, and make it optional so users can use it at their own risk, similarly to --allow_bad_res. It's one of the "use at your own risk" options that enables reckless progress.

[rwxayheee]

Processing unprotonated receptor structures was one of the major goals, and still is.

Distorted, unprotonated structures can't be parsed with our current design. Without further specification, users who do this will get arbitrary (linked or not linked) residues and any protomers. I would be deeply concerned if I am batch processing structures like these. Templates need to be assigned, or bonds need to be forgiven with certain rules (not just on/off).

[rwxayheee]

It can't be just an on/off switch. Turning a flag on to unconditionally forgive excess bonds for all residues, all structures in a batch will only cause more problems down the line. Either the structures or the bonds/templates need specific handling. Reckless processing (and for the convenience of doing so in batches) sounds like a very bad practice.

[diogomart]

Are you also concerned about unprotonated structures that are not distorted? This would be most structures downloaded directly from the PDB. Or are you concerned specifically about the combination of distorted and unprotonated?

[rwxayheee]

Are you also concerned about unprotonated structures that are not distorted?

A little, but it seems like a mutual consent that users only wants any protomer as the outcome. Currently for residue processing we support single output only, which is actually not true if we are seriously taking care of the protonation of receptor. This is not just a matter of protonation states, but also protomer states. For example, carboxylic acid can be protonated at four distinct positions. I think people always need to preprocess, and protonate receptor. Direct processing gives a single, arbitrary output.

you concerned specifically about the combination of distorted and unprotonated?

Yes, because this violates the validity of the input and how the residues are processed:

coordinate input -> distance -> input topology -> comparing with template topology -> assign chemical information.

If there's a problem with the input, the correction needs to be made as early as possible, and the handling needs to be specific. As I have suggested many times, this can be (1) direct assignment of template, no matching or (2) a set of rules for which bonds to forgive.

I don't plan to work on these features. My honest recommendations at this point would be to not directly process, in batch, potentially dirstorted and unprotonated receptors.

[diogomart]

Thanks for clarifying.

users only wants any protomer as the outcome.

That's the current paradigm: default to protonated ASP/GLU, HIE, etc. But you are right that it's far from ideal.

if we are seriously taking care of the protonation of receptor.

You are right, we are not. That would involve constant-pH simulation and then the information could be passed to meeko either with the --set_template option or by providing a fully protonated input with the desired protonation state.

I have a couple questions:

Would the direct assignment of template that you describe differ from the current --set_template option?

Could you can create an example PDB that would lead to incorrect assignment of templates? I'm also concerned, but I still can't imagine a system that would lead to incorrect template assignment. If you can devise one it would be very helpful.

[diogomart]

Could you can create an example PDB that would lead to incorrect assignment of templates? I'm also concerned, but I still can't imagine a system that would lead to incorrect template assignment. If you can devise one it would be very helpful.

Nevermind, I know one: K35 in 9mxw

[rwxayheee]

Would the direct assignment of template that you describe differ from the current --set_template option?

No, I meant to skip the entire template matching process and assign the final template-to-use directly. If we're not correcting bonds, then --force_template is needed to choose from a regular CYS with excess bonds, or a disulfide forming CYX.

I will take a look at 9MXW tomorrow!

[diogomart]

Not sure I like --force_template because we still want all of the template matching machinery. Extra bonds is only one of multiple checks, and missing heavy atoms, for example, is never acceptable. I don't think we want to drop any of the other checks because what we are really trying to do here is allowing the user to process a clashed structure. It is the responsibility of the user to choose to do so and whether or not that makes sense is up to the user to decide. For example, it could allow to process structures fixed by openmm's pdbfixer. Maybe fixing the structure requires preparing it first: clashed sidechains could be fixed by a flexible sidechain docking.

In any case, and just to clarify, the goal of this issue is to make this forgiving optional. Currently it is forgiving all the time as that has been merged to develop.

[rwxayheee]

Not sure I like --force_template because we still want all of the template matching machinery.

This will be applied only residue-wise. Given the current code structure, this is required, otherwise, we need to parse atom names because the information (malformed CYS vs CYX, LYS vs LYN) is actually lost in PDB coordinates.

In any case, and just to clarify, the goal of this issue is to make this forgiving optional.

This should not be made optional by an on/off switch in the CLI script (which will be applied polymer-wise, or in a batch).

Currently it is forgiving all the time as that has been merged to develop.

It should be reverted (but this is just my opinion.. it's up to you) and users who work with malformed structures should either (1) put in some efforts to make the structure parsable or (2) suggest a correction they want to make so we can implement it as an extra point in the parsing, without forgiving anything in the template matching.

[rwxayheee]

I think to ensure the reliable parsing of malformed residue, the template of choice needs to come from user or user needs to give hints (what corrections to make?). The problem is not as simple as forgiving bonds.

I understand that we are not implementing --force_template. Maybe there's an alternate approach.

It's helpful to know that we want the implementation to be in a different direction than I thought, I won't submit another PR on this issue, but I can work on something else.

[diogomart]

we need to parse atom names

We stopped doing this 1.5y ago, it was nearly unusable beyond standard amino acids with Amber names. Keeping up with different naming schemes from different software was just too much work.

I think to ensure the reliable parsing of malformed residue, the template of choice needs to come from user or user needs to give hints (what corrections to make?). The problem is not as simple as forgiving bonds.

It's an unsafe option. Meeko delegates responsibility to the user, and raises warnings. I think this is acceptable. Metaphorically, cars still run if the seat belts aren't fastened, they just turn on warning lights and sounds.

[rwxayheee]

I’m not talking about parsing atom names. I’m trying to explain what the consequences are, and on what level the correction should be made. But again, this is all up to you. I don’t have a strong opinion on what to do. In the end, users who work with difficult systems need to be responsible for their work