Open lilyminium opened 1 year ago
This is weird. There must be some special logic that is gunking this up, since there's nothing obvious about the base class or unit.
In [8]: ParameterAttribute(unit=unit.degree)._unit
Out[8]: <Unit('degree')>
In [9]: ParameterAttribute(unit=unit.degrees)._unit
Out[9]: <Unit('degree')>
In [10]: unit.degree.is_compatible_with(unit.degrees)
Out[10]: True
In [11]: unit.degree.dimensionality, unit.degrees.dimensionality
Out[11]: (<UnitsContainer({})>, <UnitsContainer({})>)
I'm super stumped by this. I tried
VirtualSiteType.distance
, which doesn't exhibit this behaviorunit.degree
vs. unit.degrees
makes no difference, not that one would expect it to_add_default_init_kwargs
but this behavior can be reproduced without actually creating instances of VirtualSiteHandler
etc.These keywords aren't even hit often in other places in the code, so I'm worried there's something spooky happening deeper in the ParameterAttribute
logic. These classes are hard for me to understand top-to-bottom, and I worry that changing anything will break everything, so I didn't explore that much.
Describe the bug
Despite the code appearing to do otherwise, both
VirtualSiteType.inPlaneAngle._unit
andVirtualSiteType.outOfPlaneAngle._unit
isNone
. Other unit-ed attributes, likeVirtualSiteType.distance
, don't have this issue. I'm not sure if this is actually a bug but I am a bit surprised. Relevant to #1637Code here: https://github.com/openforcefield/openff-toolkit/blob/a53a7e1b29d6ec134114da517b17d19b34908602/openff/toolkit/typing/engines/smirnoff/parameters.py#L3368-L3370
To Reproduce
Output
Computing environment (please complete the following information):
conda list
Additional context