{"action":"created","issue":{"url":"https://api.github.com/repos/pandegroup/openmm/issues/1298","labels_url":"https://api.github.com/repos/pandegroup/openmm/issues/1298/labels{/name}","comments_url":"https://api.github.com/repos/pandegroup/openmm/issues/1298/comments","events_url":"https://api.github.com/repos/pandegroup/openmm/issues/1298/events","html_url":"https://github.com/pandegroup/openmm/issues/1298","id":122186450,"number":1298,"title":"Enabling better mix-and-match support in ForceField to support small molecules and standard use cases","user":{"login":"jchodera","id":3656088,"avatar_url":"https://avatars.githubusercontent.com/u/3656088?v=3","gravatar_id":"","url":"https://api.github.com/users/jchodera","html_url":"https://github.com/jchodera","followers_url":"https://api.github.com/users/jchodera/followers","following_url":"https://api.github.com/users/jchodera/following{/other_user}","gists_url":"https://api.github.com/users/jchodera/gists{/gist_id}","starred_url":"https://api.github.com/users/jchodera/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jchodera/subscriptions","organizations_url":"https://api.github.com/users/jchodera/orgs","repos_url":"https://api.github.com/users/jchodera/repos","events_url":"https://api.github.com/users/jchodera/events{/privacy}","received_events_url":"https://api.github.com/users/jchodera/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":61,"created_at":"2015-12-15T03:38:01Z","updated_at":"2015-12-23T21:58:31Z","closed_at":null,"body":"We've taken a few steps toward making `ForceField` more functional for general use cases, but we need to go a bit further to support small molecules and many standard applications.\r\n\r\nI'll start by laying out some use cases, and then make some proposals for how we can extend things to support them.  Feedback is very much welcomed!\r\n\r\n## Use cases\r\nHere are some typical use cases, and illustrations of how we might want to use `ForceField` in a manner that is simple and consistent.\r\n\r\n### Simulating a protein:ligand in explicit solvent\r\nSuppose the user wants to simulate a system containing\r\n* a protein parameterized with AMBER ff99sb-ildn\r\n* a ligand parameterized with GAFF/AM1-BCC\r\n* TIP3P water\r\n* some ions\r\n\r\nCurrently, the user would have to go through something like [this](https://github.com/choderalab/openmoltools/blob/master/openmoltools/utils.py#L141-L182) to create a single set of matched parameters and residue definitions for one or more small molecules.  This is highly undesirable, because some random strings have to be prepended to the atom types to make them unique.\r\n\r\nInstead, it would be much more useful if we could split out the small molecule parameters (originally defined in [`gaff.dat`](https://github.com/choderalab/ambermini/blob/master/share/amber/dat/leap/parm/gaff.dat)) to a separate file, and allow the user to construct a `ForceField` object using something like\r\n```python\r\nfrom simtk.openmm import app\r\nff = app.ForceField('amber99sbildn.xml', 'gaff.xml', 'ligand.xml', 'tip3p.xml', 'ions.xml')\r\nsystem = ff.createSystem(pdb.topology, nonbondedMethod=app.PME)\r\n```\r\nHere, we let presume that the protein parameters and residue definitions are encapsulated in `amber99sbildn.xml`, the small molecule parameters in `gaff.xml`, the ligand residue definition(s) in `ligand.xml`, the solvent in `tip3p.xml`, and the ions in `ions.xml`. \r\n\r\nBecause there are a multitude of ion models that have emerged in the last few years, it is desirable to split these off into a separate file.  Some of the ion models may use parameters defined in `amber99sbildn.xml`.\r\n\r\n### Simulating a protein:ligand in implicit solvent\r\nSuppose the user wants to simulate a system containing \r\n* a protein parameterized with AMBER ff99sb-ildn and GBSA\r\n* a ligand parameterized with GAFF/AM1-BCC and GBSA\r\n\r\nThere's currently no way to do this.  The existing [`amber99_obc`](https://github.com/pandegroup/openmm/blob/master/wrappers/python/simtk/openmm/app/data/amber99_obc.xml) file has GB parameters defined for each residue of each amino acid, and there is no way to do this for small molecules unless we separately assign `charge`, `radius`, and `scale` for each atom of the small molecule using separate code.  That would mean that it is very difficult to ensure the same GB model is used for all parts of the system.\r\n\r\nInstead, it would be much simpler if we could contain the GBSA parameters in a single file `obc2-gbsa.xml` that contains parameters (and rules) for assigning the GBSA parameters, allowing us to do something like this\r\n```python\r\nfrom simtk.openmm import app\r\nff = app.ForceField('amber99sbildn.xml', 'gaff.xml', 'ligand.xml', 'obc2-gbsa.xml')\r\nsystem = ff.createSystem(pdb.topology, nonbondedMethod=app.NoCutoff, implicitSolvent=app.OBC2)\r\n```\r\n\r\n## Implementation details\r\n### Separating atom type and residue definitions\r\nIt would be ideal if we could separate atom type definitions and residue definitions across separate files, so that we can convert the atom types in [`gaff.dat`](https://github.com/choderalab/ambermini/blob/master/share/amber/dat/leap/parm/gaff.dat) into `gaff.xml` and reuse the same parameters across many small molecules we create (through an external utility for now) in one or more `ffxml` files.  We also want to separate the protein parameter sets into primary parameter definition files and separate files that define amino acids, nucleic acids, and ions.  I don't believe this is currently possible.\r\n\r\n### Overrides\r\nCurrently, if the same residue is defined in separate `ffxml` files, we get an error.  We may not have the foresight to separate `ffxml` files as finely as the user would ever want.  Instead, it would be useful to have a mode where we can *override* residue definitions by appending `ffxml` files with definitions that override earlier ones.  This is not without precedent---[viparr](https://ncifrederick.cancer.gov/dsitp/files/isp/uploads/2010/07/desmond22_user_manual.pdf) operates the same way, allowing subsequent forcefield definitions to override earlier ones, much like subsequent more specific torsion definitions override earlier more general earlier ones in AMBER forcefields.\r\n\r\n### GBSA\r\nWe need to figure out how to support GBSA parameters in a more general way.  The GBSA parameter sets are actually very minimal---there are really only [~12 types](https://github.com/choderalab/gbff/blob/master/parameters/gbsa-amber-mbondi2.types#L6-L17), but these types depend on not only the current atom, but also whether the atom is bonded to another specific element type (in the case of mbondi2 types, whether a hydrogen is bonded to a nitrogen).\r\n\r\nWe could deal with this in a number of ways:\r\n* Try to figure out if we can assign atom types to specific GBSA classes; may not be a great idea, or even possible.\r\n* Extend the atom typing scheme to allow `element` (name of current element) to be used, as well as `adjacent-element` (if any element matches this element type).  Would very much simplify specification of general GBSA forcefields at the expense of some modest complexity increase, without breaking anything.\r\n* Write a complicated `<script>` entry that interrogates the `Topology` object.  I'm not quite sure how this would work."},"comment":{"url":"https://api.github.com/repos/pandegroup/openmm/issues/comments/166998774","html_url":"https://github.com/pandegroup/openmm/issues/1298#issuecomment-166998774","issue_url":"https://api.github.com/repos/pandegroup/openmm/issues/1298","id":166998774,"user":{"login":"swails","id":779022,"avatar_url":"https://avatars.githubusercontent.com/u/779022?v=3","gravatar_id":"","url":"https://api.github.com/users/swails","html_url":"https://github.com/swails","followers_url":"https://api.github.com/users/swails/followers","following_url":"https://api.github.com/users/swails/following{/other_user}","gists_url":"https://api.github.com/users/swails/gists{/gist_id}","starred_url":"https://api.github.com/users/swails/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/swails/subscriptions","organizations_url":"https://api.github.com/users/swails/orgs","repos_url":"https://api.github.com/users/swails/repos","events_url":"https://api.github.com/users/swails/events{/privacy}","received_events_url":"https://api.github.com/users/swails/received_events","type":"User","site_admin":false},"created_at":"2015-12-23T21:58:31Z","updated_at":"2015-12-23T21:58:31Z","body":"> Is this all carboxylate radii, or only those appearing in amino acids? If just in amino acids, we could use residue and name\r\n\r\nI believe the intent is all carboxylates, but it's only been tested really on amino acids to my understanding.  But even so, where do `residue` and `name` come into play here?  Where is this information made available?\r\n\r\n> but if in all carboxylates, we would have to use type. All of this sounds doable, though---isn't it?\r\n\r\nIn the Amber force field, carboxylate oxygens have the same type as ketone oxygens.  So you *could* use `type`, but you would have to come up with some unique way of identifying those types.  You'd be back to defining a set of unique atom types like what we have now with Amber types mapping to OpenMM classes, with a separate GB class used to assign GB parameters.\r\n\r\nAnd sure, it's doable, but my point is that anything that tries to directly implement Amber's logic in tleap *without* making the decision based on the `Topology` object simply won't be extensible.  It'll be a band-aid that solves mbondi3.  When other targeted tweaks are made to newer models, you'll need to add yet more tweaks to the GB classing, and then make sure you keep the classing working for the GB models that you already support (unless you want separate FF XML files like we already have, one for each GB model)."}}