Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactor setup unit to work with protein mutation protocol #77

Open
IAlibay opened this issue Sep 16, 2024 · 2 comments
Open

Refactor setup unit to work with protein mutation protocol #77

IAlibay opened this issue Sep 16, 2024 · 2 comments
Assignees

Comments

@IAlibay
Copy link
Member

IAlibay commented Sep 16, 2024

Currently this will only work for small molecules.

@ijpulidos ijpulidos self-assigned this Oct 31, 2024
@ijpulidos
Copy link
Contributor

Some thoughts after going through the SetupUnit code. We should probably rename this issue accordingly, more in terms of refactoring the SetupUnit to work for different protocols.

Ideally we would benefit from having reusable units and components in the protocols that can be shared between protocols that have some kind of similarity. It should be possible for the protein mutation protocol to share the setup unit with the current nonequilibrium cycling protocol. This involves a set of changes, from a first look at the code:

  • Rewrite logic such that protein components can be alchemical components now. Right now it is hardcoded that the small molecule components are the alchemical ones.
  • Related to the previous issue. Infer alchemical components from mapping. I believe it should be possible to get the alchemical components from the mapping objects, without having to know if we want to transform a specific type of component, I think the mapping already has that information.
  • Create a mapping object for protein. Namely, some kind of ProteinMapping instead of relying onLigandAtomMapping. Alternatively, maybe we should consider using a more general mapping for both?
  • Do we need to add/change settings that would be specific for the protein mutation protocol?
  • Creating OpenMM modeller objects need to be refactored such that it can handle multiple protein components (protein-protein interactions or monomers in different components, for example).
  • Generalization would probably mean having empty lists for some objects in one protocol vs another, for example having empty lists for alchemical small mols for protein mutation, or similarly. Currently the way we are creating systems with openmmforcefields objects doesn't really support this. I don't think we can afford changing openmmforcefields API. So we would probably need to write some utility functionality to deal with this.
  • I think we need a way to somehow map between resids in topology with components, such that it is easy to extract resids from alchemical components and/or mappings.

@ijpulidos ijpulidos changed the title Rewwrite combine_topology to work for protein mutations Refactor setup unit to work with protein mutation protocol Nov 7, 2024
@ijpulidos
Copy link
Contributor

After discussion with @IAlibay , some things are clearer now.

* Related to the previous issue. Infer alchemical components from mapping. I believe it should be possible to get the alchemical components from the mapping objects, without having to know if we want to transform a specific type of component, I think the mapping already has that information.

This was done this way to support the absolute FE protocol, which wouldn't have mappings at all. We should use the readily available get_alchemical_components from the openfe system creation module.

* I think we need a way to somehow map between resids in topology with components, such that it is easy to extract resids from alchemical components and/or mappings.

This was an oversight on my part, we already have that from the comp_resids dictionary in the current setup unit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants