10000 Templates stored within Polymer · Issue #293 · forlilab/Meeko · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Templates stored within Polymer #293

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 &ld 8000 quo;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

Open
rwxayheee opened this issue Dec 24, 2024 · 6 comments
Open

Templates stored within Polymer #293

rwxayheee opened this issue Dec 24, 2024 · 6 comments

Comments

@rwxayheee
Copy link
Contributor

residue_chem_templates (ResidueChemTemplates) is an attribute of Polymer. The residue chem templates can be read from and written to JSON. Currently it includes a full set of available templates that has been loaded during the construction.

For each Monomer, there is also a template attribute but it is not a JSON-bound property (not exported to JSON or imported from JSON of a polymer).

Based on discussion we had today, we might want to re-evaluate whether we want and which templates to store with polymer. For templates generated during construction, this attribute serves as a useful cache. For templates that didn't match, retaining them may not be necessary.

@rwxayheee
Copy link
Contributor Author

Closing as no change is needed and current behavior does provide useful information. The full set of templates makes it easy to re-run monomer matching.
For class Monomer, template and link_labels will stay as exceptions (#338) and not getting JSON serialized (?). Currently, they're only used during the building of padder_mol and can be re-computed as long as full set of templates is provided

@diogomart
Copy link
Contributor

I think we should implement this, the serialized polymers take a lot of space and the meeko distribution contains the default templates anyway.

@diogomart diogomart reopened this Apr 15, 2025
@rwxayheee
Copy link
Contributor Author

@diogomart Can you implement this? I’ve thought about this, but I don’t know which attr will be used and how. I understand both are useful. If you can explain how you want this to be done (which one to keep, which one to remove) I can do the work

@rwxayheee
Copy link
Contributor Author

Do you want polymer to have the set of templates it was prepared with? This might be different from the default, and might be useful to replicate the preparation for a new polymer or for the edited polymer

@diogomart
Copy link
Contributor

That's a great point that the polymer might have been prepared with non-defaults. The monomer.rdkit_mol attributes are copies of the exact templates that matched (I think all info in the templates is preserved). Are you thinking of something more elaborate like preserving the templates that were associated in the ambiguous dictionary? For example, for a "HIE" residue, we'd keep also "HID", "HIP", "NHIE", ... , and so on.

Can you implement this?

Yes, I'll work on this, don't worry about it. It's low priority. But please still post your concerns about functionality we might be missing by implementing this.

@rwxayheee
Copy link
Contributor Author

Hi @diogomart

Are you thinking of something more elaborate like preserving the templates that were associated in the ambiguous dictionary? For example, for a "HIE" residue, we'd keep also "HID", "HIP", "NHIE", ... , and so on.

Yes, I thought the full set would be useful if we want to re-parameterize this polymer, or to parameterize another polymer with the same exact set of templates, but I don't know if that's important and I agree that the object might be too big and not worth saving.

But please still post your concerns about functionality we might be missing by implementing this.

Not at the moment. I don't have a very clear visibility into where these attributes might be used outside of the library functions, so I’ll leave them as-is for now.

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
0