## Foyer Handlers (PR #114)
Few questions at this point:
- Should foyer directly operate in off's `Topology` for now? This can be achieved with some additions to foyer's `run_atomtyping` function IMO. Might open up manageable can of worms.
- >Regarding the above comment, we have managed to [decouple parmed](https://github.com/mosdef-hub/foyer/pull/389) from the `atomtyping` step. For atomtyping to work, you would need a generic Topology Graph that subclasses a networkx Graph. Would you guys be interested in providing a conversion from an OFF Topology to a foyer topology [graph](https://github.com/mosdef-hub/foyer/blob/d2187efd1aaf557e3763ae02f2d44eeb20cd17c0/foyer/topology_graph.py#L96-L120)?
- UT -- Could also accept inputs like NetworkX. This is how things work under the hood, but there are no API points to handle NX graphs specifically.
- MT -- This sounds like a good idea. One thought would be to have Foyer have its primary functionality be on something like a networkX graph, and have some automatically-called converters that take whatever input it normally takes (mBuild, ParmEd, etc) and convert that to a networkX graph.
- UT -- Agree. We'll try to decouple internal representation from the variety of inputs it can use.
- UT -- On PR 114, there was a suggestion to not use ParmEd as an intermediatry. MT had made the recommendation not to do that. Could I have more detail on this?
- MT -- My proposal would be that Foyer would be simpler if they always operate on a NX graph, but users could still provide a ParmEd topology, and it would get automatically converted to a NX graph.
- JW -- OpenFF will _eventually_ provide a first-class "atom-typed Topology" which can be used in place of its current "bond order Topology" for interfacting with atom typed ecosystems. This won't be in a stable build for a while, so my recommendation for now is, whenever you need to populate a molecule in an OpenFF topology starting from Foyer/mBuild, just pretend everything's a single bond.
- UT -- What is the scope of `store_matches` in the OpenFF System? Is it relevant to Foyer-typed systems?
- MT -- Those functions are largely relevant to SMIRNOFF systems. The actual Foyer logic of _doing_ the typing is out of scope. The _results_ of doing the typing are what should be stored.
- UT -- I was thinking about "What happens during a mismatch/when there's no parameter for a slot?" Should it fail when the assignment is happening, or will some machinery later raise the error?
- MT + JW -- We'd recommend raising an error immediately during typing, but that's just an arbitrary decision that OpenFF has made inits own typing tools.
- UT -- I was thinking about use cases where someone might want to look at the intermediate result.

- What would a successful testing regime for this foyer handlers look like?
- > Not much progress has been made in this front, foyer should be released this week (latest). This will open up doors to test systems parameterized with foyer. Also, since parmed will no longer be required, tinkering with the off toolkit Topology should be helpful as well.

- What the molecule type should be

- At a minimum, run an energy evaluation at the end and don't get a crash or NaN
- Preferably, look at energies in each different potential terms (parameterize to OpenMM, ensure that the same bond, angle, torsion, nonbonded energies come out of each system), and ensure they match a reference
- This will inevitably require testing two different ways of parameterizing the same molecule. No simulation ecosystem a dataset of molecules with reference energies
- Could have some "intuitive" sanity checks like ensuring that methane doesn't have torsion energy or that a system with no partial charges doesn't have electrostatic energy
- Unfortunately, it'll be hard to find a pathway to get reference energies for OPLS (maybe could do something with LigParGen or BOSS)
- Could you also explain the TopologyKey and PotentialKey that was recently added? I see that it is a hash based abstraction for `dict_key`. I wanted to know the use cases if I the question is not clear.
- > This support has been added

- What is the scope of OpenMM forces support you would want. Currently, I have implemented the following (most common use cases for us) for us:
* NonBondedForce
* HarmonicBondForce
* HarmonicAngleForce
* PeriodicTorsionForce
* RBTorsionForce

* If time remains, any basic info for bond order inference?
* Do you know of any groups having issues with windows after migrating from omnia. Only our windows builds are failing for `foyer` after we removed `omnia`.

## Next Steps:
1. Test [mosdef-hub/foyer#382](https://github.com/mosdef-hub/foyer/pull/382) and release foyer
- MT -- I would encourage you not to re-implement smirnoff.py. It's an effort to separate the complexity of SMIRNOFF-centric typing from the more general aspects of the object. The important thing is the object that gets... eg. When an exporter writes out angles, it needs to know i,j,k for each angle, and then it uses the slot map to look up the "key" for each parameter (which for SMIRNOFF happens to be a SMARTS, but for foyer could be something else)... (I couldn't follow the notes)
- (Alternate explanation) MT -- Potentialhandlers have two important data members -- `slot_map` and `potentials`.
- `slot_map` is a dictionary, where the keys are atom indices (or tuples of atom indices). The values are "potential keys", which are currently pydantic-based models, which effectively just store a unique ID for the parameter that's applied.
- `potentials` is a dictionary with keys of `potential_keys`, refered to above. The values are the actual parameters (eg, for a bond, the length and k).
- UT -- So there are some standard keys that one might want to use. Is there some type-matching on the dependent and independent variables?
- UT -- Also, will the handlers be called in a particular order? The Foyer handlers sometimes require the output of a previous handler to, for example, pre-populate the slot map.
- MT -- You can pick the order that handlers are called. In other areas of OpenFF, handlers can list their dependencies (other handlers), and they're guaranteed to respect those dependencies. But this is somewhat complex and I'm not sure that we like that decision.
- UT -- Can the slots from one handler's output be fed into other handlers?
- MT -- I'd encourage you to write the order that the handlers are called. I do it here: https://github.com/openforcefield/openff-system/blob/9f6b1737fd953a0f50e59a675013dc41d2726e6e/openff/system/stubs.py#L30 and monkey-patch it here: https://github.com/openforcefield/openff-system/blob/9f6b1737fd953a0f50e59a675013dc41d2726e6e/openff/system/stubs.py#L271
- UT -- Where do we envision the `create_openff_system` living in the long run?
- > If atomtyping with `off-topology` works, then its pretty obvious that it should live in OFF side.
- MT -- I'm not sure, we don't have a recommendation on this.
- UT -- I think I understand. I will try to build and test this. It would be good to have a workflow for testing this so I know once we have it. It's presumably energy tests, but I'd like to have some code or reference data to test this.
- MT -- I can provide some advice on this, and some code for testing
3. Input needed from OFF team here...