-
Notifications
You must be signed in to change notification settings - Fork 53
Non-deterministic charge validation #2132
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
base: main
Are you sure you want to change the base?
Changes from 16 commits
d7dcd14
84174f3
3c76241
2874599
36784f9
251474c
ba3f47d
045954d
6c0d7d4
960b874
96b5d24
e2099ed
b8f7ecb
98152db
df24ca1
7dfdb3f
0c8e7dd
540aefa
bacb1c3
9cb4322
7b7e4ee
c43dbf0
6c32c99
4cf822d
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -22,6 +22,8 @@ | |
| SolventComponent, | ||
| ) | ||
| from gufe.components.errors import ComponentValidationError | ||
| from gufe.protocols.errors import ProtocolValidationError | ||
| from openff.toolkit import ForceField | ||
| from openff.toolkit import Molecule as OFFMol | ||
|
|
||
| logger = logging.getLogger(__name__) | ||
|
|
@@ -371,3 +373,58 @@ def validate_chemical_system(system: ChemicalSystem): | |
| except ComponentValidationError as e: | ||
| errmsg = f"Component {entry} from ChemicalSystem {system.name} failed validation: {e}" | ||
| raise ComponentValidationError(errmsg) | ||
|
|
||
|
|
||
| def validate_nondeterministic_charges(system: ChemicalSystem, small_molecule_forcefield: str): | ||
| """ | ||
| Validate that the SmallMoleculeComponents of the system will have deterministic partial charges. | ||
|
|
||
| This is determined by checking for charges on the molecules before checking what would be assigned by the force field. | ||
|
|
||
| Parameters | ||
| ---------- | ||
| system : ChemicalSystem | ||
| The ChemicalSystem to validate with SmallMoleculeComponents. | ||
| small_molecule_forcefield : str | ||
| The force field to be used for the SmallMoleculeComponents. | ||
|
|
||
| Raises | ||
| ------ | ||
| ProtocolValidationError | ||
| If any SmallMoleculeComponents in the system would have am1bcc charges generated at runtime. | ||
| """ | ||
| smcs: list[SmallMoleculeComponent] = system.get_components_of_type(SmallMoleculeComponent) | ||
| if "espaloma" in small_molecule_forcefield or "gaff" in small_molecule_forcefield: | ||
| # this will always generate charges at runtime, so raise an error for missing charges | ||
| ff = None | ||
| else: | ||
| try: | ||
| ff = ForceField(small_molecule_forcefield) | ||
| except OSError: | ||
| # try again but adding offxml to the end of the force field name if the user passed one of the installed force fields without the extension | ||
| try: | ||
| ff = ForceField(small_molecule_forcefield + ".offxml") | ||
| except OSError as e: | ||
| errmsg = f"Could not load force field {small_molecule_forcefield} or {small_molecule_forcefield}.offxml: {e}" | ||
| raise ProtocolValidationError(errmsg) | ||
|
|
||
| for smc in smcs: | ||
| offmol = smc.to_openff() | ||
| if offmol.partial_charges is not None and np.any(offmol.partial_charges): | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Would we want to support a case where the user supplies partial charges will all zeros?
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. +1 - given we have our own benchmark case where we want to do this, we probably should support it
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes good idea. Currently, this only works as a Library charge would we want to keep that as a source of protection to make sure users know what they are doing or allow it as charges on the molecule as well?
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That's a good point - I think if it's easily allowed by LibraryCharge then it might be better to keep the check in. There's too many ways someone could accidentally add partial charges. |
||
| continue | ||
|
|
||
| # check the labels assigned for an openff force field | ||
| if ff is not None: | ||
| labels = ff.label_molecules(offmol.to_topology())[0] | ||
| else: | ||
| # return a dummy label as the gaff and espaloma should always give am1bcc charges | ||
| labels = {"LibraryCharges": {}} | ||
|
|
||
| # We count library and nagl charges as deterministic | ||
| # While users could use a deterministic charge method with increments we don't currently support this | ||
| if not labels["LibraryCharges"] and "NAGLCharges" not in labels: | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is LibraryCharges always guaranteed as a key or could it KeyError?
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Good catch it could be missing, added support for it and a test. |
||
| errmsg = ( | ||
| f"{smc} from system {system.name} would have am1bcc charges generated at runtime which is non-deterministic. " | ||
| f"Please provide a molecule with pre-computed charges or use library charges instead." | ||
| ) | ||
| raise ProtocolValidationError(errmsg) | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -159,15 +159,21 @@ def test_mbar_overlap_plot(): | |
| assert isinstance(ax, matplotlib.axes.Axes) | ||
|
|
||
|
|
||
| @pytest.mark.parametrize("num", [i for i in range(1, 30)]) | ||
| def test_plot_2D_rmsd(num): | ||
| def test_plot_2D_rmsd(): | ||
|
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sneaking this in can remove if wanted, though, locally this goes from 8s to 650ms while testing more aspects of the output.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Please move it to a separate PR. |
||
| """ | ||
| Smoke test: | ||
| Loop through and test plotting fictitious 2D data | ||
| """ | ||
| num = 29 | ||
| points = num * (num - 1) // 2 | ||
| data = [[0.5 for x in range(points)] for i in range(num)] | ||
| data = [[0.5 for _ in range(points)] for _ in range(num)] | ||
|
|
||
| fig = plot_2D_rmsd(data) | ||
| # check the number of axes and their titles | ||
| assert len(fig.axes) == 32 | ||
| axis_names = [ax.get_title() for ax in fig.axes if ax.get_title()] | ||
| assert axis_names == [f"State {i}" for i in range(num)] | ||
| assert fig._suptitle.get_text() == "Protein 2D RMSD" | ||
| plt.close(fig) | ||
|
|
||
|
|
||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've been thinking more about this one - we're silently removing this, but won't users get caught out if they do use a deterministic charge method in the partial charge settings, e.g. NAGL?
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah that would be the downside, users would have to either use a ff with a NAGL handler or pre-charge them. If we keep support for NAGL and espaloma charge methods at runtime only that could work with the default setting being
forcefield. It could be confusing if users have to define the forcefield to use in two places 1) the charges setting object and 2) small molecule force field, and then what happens if these are different?Ideally I would love to keep this as simple as possible for users, we already encourage charging before running so moving to openfe will do no runtime charge generation doesn't feel like too much of a change?