More complex slot-parameter mapping about openff-interchange HOT 3 CLOSED

Thinking about this a little more, the only purpose the SMIRKS strings serve is means to point to the actual parameters/potentials/data. To enable non-1:1 mapping, this could be a dict, array, or something else. Breaking 1:1, however, makes it much more difficult for a user to get a simple answer from the slot map and take it to the potential map to get the actual parameter values.

If bonds.slot_map[(0, 1)] returned something dict-like ({'[#6X4:1]-[#6X4:2]': 0.7, '[#6:1]-[#8:2]': 0.3}) it would be more instructive, but would require a method near bonds.potentials that can gobble up that dict and return the relevant data.

I don't think hiding the mapping from the user is a good path to do down. Yes, most use cases only require filling out the system with the parametrized data. But the mapping between force field and system parameters must be transparent, and only returning data, lacking a clear source, would not be acceptable.

An in-between approach could involve storing the dict/array/etc in the PotentialHandler object and exposing some methods for the convenience of the user, i.e. as described by the bullet points above.

from openff-interchange.

Another thought: it might be inevitable that the current models' use of built-in types (dict, str, etc.) is not the eventual solution, which may include subclasses of those types with some custom behavior. Therefore, it may be worth exploring that option now.

from openff-interchange.

I think this is now handled with WrappedPotential

from openff-interchange.