{"action":"closed","issue":{"url":"https://api.github.com/repos/pandegroup/openmm/issues/1168","labels_url":"https://api.github.com/repos/pandegroup/openmm/issues/1168/labels{/name}","comments_url":"https://api.github.com/repos/pandegroup/openmm/issues/1168/comments","events_url":"https://api.github.com/repos/pandegroup/openmm/issues/1168/events","html_url":"https://github.com/pandegroup/openmm/issues/1168","id":109897702,"number":1168,"title":"Extending ffxml to separate charge and Lennard-Jones parameter assignment","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":"closed","locked":false,"assignee":null,"milestone":null,"comments":37,"created_at":"2015-10-05T22:14:54Z","updated_at":"2015-10-13T21:40:49Z","closed_at":"2015-10-13T21:40:49Z","body":"We have been thinking about ways we can make the `ffxml` format for `simtk.openmm.app.ForceField` a bit friendlier both for users (who often want to \"mix and match\", such as combining AMBER forcefields with standard or multisite ion parameters) and for tools that need to use small molecules (such as YANK).  \r\n\r\nWhile the `type` and `class` mechansim of the `ffxml` format is very powerful, one of the main sources of complexity right now is the definition of a new atom `type` for each atom appearing in each residue template.  Forcefields like AMBER define a very limited set of atom types (e.g. [`parm96.dat` defines 54 atom types](https://github.com/choderalab/ambermini/blob/master/share/amber/dat/leap/parm/parm96.dat#L2-L55)), and even fewer Lennard-Jones parameters ([`parm96.dat` defines 35 LJ types](https://github.com/choderalab/ambermini/blob/master/share/amber/dat/leap/parm/parm96.dat#L2-L55)).\r\n\r\nIf we had a mechanism by which the `NonbondedForce` section of the `ffxml` file could also specify a `charge` attribute for each object, and use this to assign charges, the complexity of the resulting `ffxml` files could be considerably simplified, and we could additionally mix-and-match things like the [`gaff.xml`](https://github.com/choderalab/ambermini/blob/master/share/amber/dat/leap/parm/gaff.dat) small molecule forcefield that specifies parameters for small molecules because no name collisions would occur (provided we also permit parameters to be specified in a separate `ffxml` file from residue templates).\r\n\r\nThis change would allow us to extend the `<Atom>` element tag to permit an additional `charge attribute.  For alanine, for example, this would change from\r\n```XML\r\n  <Residue name=\"ALA\">\r\n   <Atom name=\"N\" type=\"0\"/>\r\n   <Atom name=\"H\" type=\"1\"/>\r\n```\r\nto\r\n```XML\r\n  <Residue name=\"ALA\">\r\n   <Atom name=\"N\" type=\"0\" charge=\"-0.41570\"/>\r\n   <Atom name=\"H\" type=\"1\" charge=\"0.27190\"/>\r\n```\r\nThe atom types and classes would be redefined to match the AMBER atom type names and LJ classes, changing from:\r\n```XML\r\n <AtomTypes>\r\n  <Type name=\"0\" class=\"N\" element=\"N\" mass=\"14.00672\"/>\r\n  <Type name=\"1\" class=\"H\" element=\"H\" mass=\"1.007947\"/>\r\n  <Type name=\"2\" class=\"CT\" element=\"C\" mass=\"12.01078\"/>\r\n  <Type name=\"3\" class=\"H1\" element=\"H\" mass=\"1.007947\"/>\r\n```\r\nto\r\n```XML\r\n <AtomTypes>\r\n  <Type name=\"N\" class=\"N\" element=\"N\" mass=\"14.00672\"/>\r\n  <Type name=\"H\" class=\"H\" element=\"H\" mass=\"1.007947\"/>\r\n  <Type name=\"CT\" class=\"C\" element=\"C\" mass=\"12.01078\"/>\r\n  <Type name=\"H1\" class=\"H1\" element=\"H\" mass=\"1.007947\"/>\r\n```\r\nThe `<NonbondedForce>` section of the `ffxml` would then be simplified by utilizing the smaller number of LJ atom classes, and either omit the charge altogether:\r\n```XML\r\n<NonbondedForce coulomb14scale=\"0.833333\" lj14scale=\"0.5\">\r\n  <Atom class=\"N\" sigma=\"0.324999852378\" epsilon=\"0.71128\"/>\r\n  <Atom class=\"H\" sigma=\"0.106907846177\" epsilon=\"0.0656888\"/>\r\n  <Atom class=\"C\" sigma=\"0.339966950842\" epsilon=\"0.4577296\"/>\r\n  <Atom class=\"H1\" sigma=\"0.247135304412\" epsilon=\"0.0656888\"/>\r\n```\r\nor specify a keyword that says the charge should be obtained from the `charge` attribute of the `<Atom>` tag:\r\n```XML\r\n<NonbondedForce coulomb14scale=\"0.833333\" lj14scale=\"0.5\">\r\n  <Atom class=\"N\" charge=\"atom@charge\" sigma=\"0.324999852378\" epsilon=\"0.71128\"/>\r\n  <Atom class=\"H\" charge=\"atom@charge\" sigma=\"0.106907846177\" epsilon=\"0.0656888\"/>\r\n  <Atom class=\"C\" charge=\"atom@charge\" sigma=\"0.339966950842\" epsilon=\"0.4577296\"/>\r\n  <Atom class=\"H1\" charge=\"atom@charge\" sigma=\"0.247135304412\" epsilon=\"0.0656888\"/>\r\n```\r\nOther syntax could be used to denote the attribute of interest, such as XPath syntax (is this `Atom/@charge`?) that could let us extend the `<Atom>` tag in the future with additional atom-specific information (such as AMOEBA multipole parameters).\r\n\r\nQuestions for the implementation:\r\n* Can this simply be a backwards-compatible extension to the `ffxml` format, rather than a new non-backwards-compatible revision?  \r\n* Even if this is not a revision, should we start adding an attribute that specifies the version of the `ffxml` spec we are using, such as\r\n```XML\r\n<ForceField version=\"1.0\">\r\n```\r\nin order to better handle revisions in the future?\r\n* Should we modify `NonbondedGenerator` to handle these extensions, or is this better handled by adding a custom `<Script>` section to the `<NonbondedForce>` sections of the `ffxml` files?  If a `Script`, how would we access the `<Atom>` `charge` attribute?\r\n * Can we easily change the behavior to allow residue templates to be specified in a different file from the parameters to facilitate mix-and-match use without causing problems?  We would still want an `Exception` to be thrown on atom type or class name collisions.\r\n* Are there other opportunities for generalization we can exploit along the same lines?\r\n\r\n"}}