Definitions of supported functional forms for simulation engines

[summeraz]

Disclaimer: I'm not 100% caught up on all the activity and discussion here and am still not very familiar with sympy, so feel free to close if this suggestion doesn't make sense.

It might be useful to keep some sort of library where we have files for each simulation engine that define the various supported functional forms for each interaction type. I'm thinking a file structure that's something like (with better names):

supported_functional_forms/
|-- gromacs/
| |-- nonbonded.txt
| |-- bond.txt
| |-- angle.txt
...

And then, e.g., nonbonded.txt would list the supported nonbonded functional forms:

4*epsilon*((sigma/r)**12 - (sigma/r)**6)
...

This way, if we have a topology with our various functional forms defined for each interaction, we can have a check that interfaces with the library when attempting to save to a certain format as to whether or not the engine supports the defined functional forms. Even better, we could have a property on the Topology that's something like supported_formats that could be queried to see which writers are available based on the defined functional forms for that topology.

There would likely be some snags with functional forms that are technically equivalent, but defined in slightly-different ways. This is where my lack of knowledge of sympy comes in, as I'm not sure how easy that would be to handle. It looks like a similar discussion is ongoing in #31 with regard to harmonic potentials with and without the 0.5 scaling.

[ahy3nz]

This could be good. We briefly mentioned that we'd need to explicitly put the supported functional forms for each engine/library.
Going a step further in the case of gromacs, I wonder if this could be like some sort of json file so we could map functional forms to the actual function index that would go in a topology file. But I don't think this json-style corresponds well to other engines/libraries, so maybe just a file of strings -> sympy expressions is the common ground

bond.json 
{'0.5 * k * (r - r_eq)**2' : 1,
 'other_gmx_bond_form': gmx_bond_form_index}

[mattwthompson]

What I had in mind is storing various "known" functional forms somewhere, and within each writer we'd check to make sure it's supported by said engine. In principle this library would grow as we become aware of other potentials (for example, some of Ilja's dihedrals apparently have strange functional forms; we'd implement those in the appropriate writers and store them in this library).

Usage would be like

from topology.somewhere import CommonBondedPotentials


common_bond_potentials = CommonBondedPotentials()

def some_writer():
    ...
    if any([a.atom_type.connection_type for a in topology.sitelist]) not in common_bond_potentials
        raise SomeError('Functional form not supported by engine x')

[mattwthompson]

I also am just a beginner with sympy but I have at least been able to come across some functionality of expression comparison. I just so happened to show this to Peter yesterday (by the way, he claims to already be a sympy user, and was pleased with what we showed him!)

The bottom half of this notebook doesn't work, but you get the idea 🤷‍♂️
storing_expressions_with_sympy.ipynb.gz

[justinGilmer]

This is great. Its actually the way I plan on implementing xtal space group support in mBuild. I plan on having a json file that stores all the necessary info for each of the 232 space groups, a class will then just parse the json doc whenever a user wants to use one, and return a Lattice with its parameters already filled in by that json file.

If we can come up with a list of items that are present in each sim engine, we can then just look in a file for these and setup our writer or whatever with the proper settings pretty easily.

[daico007]

This is currently checked in individual writer (list of supported potential forms).