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

unique_molecules argument should not be optional #1485

Open
Yoshanuikabundi opened this issue Dec 8, 2022 · 3 comments · May be fixed by #1742
Open

unique_molecules argument should not be optional #1485

Yoshanuikabundi opened this issue Dec 8, 2022 · 3 comments · May be fixed by #1742

Comments

@Yoshanuikabundi
Copy link
Collaborator

The Topology.from_openmm() and Topology.from_mdtraj() methods' unique_molecules argument is currently optional, but if None is supplied we manually raise a custom error. It should be a regular positional argument. This would make it more obvious to users that it is, in fact, required. Unfortunately this is a breaking change. We should make this change the next time we make a breaking release.

@mattwthompson
Copy link
Member

Is this really a breaking change? I can't imagine any code using Topology.from_openmm(openmm_topology, unique_molecule=None) currently works

@jchodera
Copy link
Member

jchodera commented Dec 8, 2022

The OpenMM Topology object currently supports bond orders and there is an issue to add formal charges. If these are present, unique molecules can be perceived from the Topology directly without the need to manually specify them. This was supposed to happen much sooner, and can be accelerated if needed.

I'd argue that we don't need to change the behavior, but we should try to get OpenMM to prioritize adding formal charges and bond orders (compatible with OpenFF) where possible.

@j-wags
Copy link
Member

j-wags commented Dec 8, 2022

@mattwthompson If it were a higher-value change I'd overlook the fact that it's at the benign end of the "breaking" scale. But it might still technically break someone's Topology subclass, or do something that we haven't anticipated. And since the gain is so marginal I'd rather have this wait until an API breaking release is scheduled.

@mattwthompson mattwthompson linked a pull request Oct 13, 2023 that will close this issue
7 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants