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

cannot add a vdW parameter to the default vdW handler in 0.8.1 #788

Closed
trevorgokey opened this issue Dec 11, 2020 · 4 comments · Fixed by #789
Closed

cannot add a vdW parameter to the default vdW handler in 0.8.1 #788

trevorgokey opened this issue Dec 11, 2020 · 4 comments · Fixed by #789

Comments

@trevorgokey
Copy link
Collaborator

Describe the bug

Previously, before commit 907423a#diff-4055de40d998a929690d778b556442506df263af162f482a3f47ad9dd98f1883

I was able to add a vdW parameter as follows using the following dictionary:

                param_dict = dict(
                    epsilon="0.5 * kilocalorie/mole",
                    rmin_half="1.2 * angstrom",
                    smirks="[*:1]",
                    id="n1",
                )

via the standard ph.add_parameter(param_dict). Now with the most recent version, it no longer works.

I couldn't find anywhere in the release notes that describe the intended break/change in behavior, so it seems something is off here.

To Reproduce

from openforcefield.typing.engines.smirnoff import ForceField
ff = ForceField('openff-1.3.0.offxml')
param = dict(epsilon="0.5 * kilocalorie/mole", rmin_half="1.2 * angstrom", smirks="[*:1]", id="n99")
ff.get_parameter_handler("vdW").add_parameter(param)

Output

with 0.7.2, no output (it works)

with 0.8.1:

/home/tgokey/.local/miniconda3/envs/oFF-test/lib/python3.7/site-packages/openforcefield/typing/engines/smirnoff/parameters.py in add_parameter(self, parameter_kwargs, parameter, after, before)
   2090         # If a dict was passed, construct it; if a ParameterType was passed, do nothing
   2091         if parameter_kwargs:
-> 2092             new_parameter = self._INFOTYPE(**parameter_kwargs)
   2093         elif parameter:
   2094             new_parameter = parameter

/home/tgokey/.local/miniconda3/envs/oFF-test/lib/python3.7/site-packages/openforcefield/typing/engines/smirnoff/parameters.py in __init__(self, **kwargs)
   3502                 )
   3503 
-> 3504             super().__init__(**kwargs)
   3505 
   3506             if sigma:

/home/tgokey/.local/miniconda3/envs/oFF-test/lib/python3.7/site-packages/openforcefield/typing/engines/smirnoff/parameters.py in __init__(self, smirks, allow_cosmetic_attributes, **kwargs)
   1828         # This is just to make smirks a required positional argument.
   1829         kwargs["smirks"] = smirks
-> 1830         super().__init__(allow_cosmetic_attributes=allow_cosmetic_attributes, **kwargs)
   1831 
   1832     def __repr__(self):

/home/tgokey/.local/miniconda3/envs/oFF-test/lib/python3.7/site-packages/openforcefield/typing/engines/smirnoff/parameters.py in __init__(self, allow_cosmetic_attributes, **kwargs)
    914         for key, val in smirnoff_data.items():
    915             if key in allowed_attributes:
--> 916                 setattr(self, key, val)
    917             # Handle all unknown kwargs as cosmetic so we can write them back out
    918             elif allow_cosmetic_attributes:

/home/tgokey/.local/miniconda3/envs/oFF-test/lib/python3.7/site-packages/openforcefield/typing/engines/smirnoff/parameters.py in __setattr__(self, name, value)
   3512             super().__setattr__(key=name, value=value)
   3513             if name == "rmin_half":
-> 3514                 super().__setattr__("sigma", value / 2 ** (1 / 6))
   3515                 self._extra_nb_var = "sigma"
   3516 

TypeError: unsupported operand type(s) for /: 'str' and 'float'
@mattwthompson
Copy link
Member

Thanks for the report - it does like a regression to me. In that setter, I overlooked that the values may be strings, and only tested unpacked quantities. I think the solution would be to check the type and, if it is a string, unwrap it with object_to_quantity?

@j-wags
Copy link
Member

j-wags commented Dec 11, 2020

Pretty much. Specifically I think we want to use convert_and_validate instead of object_to_quantity, though I need to look closely at the pattern of what-is-calling-what here.

@j-wags
Copy link
Member

j-wags commented Dec 11, 2020

Ah, you're right, @mattwthompson. It should be object_to_quantity.

I had just started a fix branch when you opened the PR. Doc Thompson, fastest PR in the west. Ain't nobody can best him.

@trevorgokey
Copy link
Collaborator Author

Awesome! This is really nice to see get tackled and sorted out so quickly.

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

Successfully merging a pull request may close this issue.

3 participants