{"action":"created","issue":{"url":"https://api.github.com/repos/pandegroup/openmm/issues/1344","labels_url":"https://api.github.com/repos/pandegroup/openmm/issues/1344/labels{/name}","comments_url":"https://api.github.com/repos/pandegroup/openmm/issues/1344/comments","events_url":"https://api.github.com/repos/pandegroup/openmm/issues/1344/events","html_url":"https://github.com/pandegroup/openmm/issues/1344","id":126932059,"number":1344,"title":"Allow subsequently loaded `ffxml` files to overwrite earlier types/parameters","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":37,"created_at":"2016-01-15T18:44:15Z","updated_at":"2016-02-01T21:05:59Z","closed_at":null,"body":"A specific consequence of enabling mix-and-match `ffxml` files (#1298) is that we can run into situations where later `ffxml` files might need to overwrite earlier atom types and parameter definitions.\r\n\r\nOne case where it would be useful to allow this is for the current AMBER forcefields.  If we use AMBER typenames as OpenMM type and class names to allow support for small molecules, we run into the issue that allowing mix-and-match of different water or ion models requires @rafwiewiora dissect out these parameters and residue definitions from a single set of AMBER parameter files, which could be very complex.  Instead, it would be much easier if we could simply prepare separate parameter files for these alternative water and ion models and allow alternative choices to overwrite the earlier definitions if the user adds them to the end of the list of parameter sets.\r\n\r\nCurrently, attempting to redefine types and parameters throws an exception:\r\n```\r\n>>> from simtk.openmm.app import ForceField\r\n>>> ff = ForceField('tip3p.xml', 'tip3p.xml')\r\nTraceback (most recent call last):\r\n  File \"<stdin>\", line 1, in <module>\r\n  File \"/Users/choderaj/miniconda/lib/python2.7/site-packages/simtk/openmm/app/forcefield.py\", line 117, in __init__\r\n    self.loadFile(file)\r\n  File \"/Users/choderaj/miniconda/lib/python2.7/site-packages/simtk/openmm/app/forcefield.py\", line 140, in loadFile\r\n    self.registerAtomType(type.attrib)\r\n  File \"/Users/choderaj/miniconda/lib/python2.7/site-packages/simtk/openmm/app/forcefield.py\", line 183, in registerAtomType\r\n    raise ValueError('Found multiple definitions for atom type: '+name)\r\nValueError: Found multiple definitions for atom type: tip3p-O\r\n```\r\nAre there other ramifications for allowing this kind of atom type and parameter overwriting by later `ffxml` files?"},"comment":{"url":"https://api.github.com/repos/pandegroup/openmm/issues/comments/178189950","html_url":"https://github.com/pandegroup/openmm/issues/1344#issuecomment-178189950","issue_url":"https://api.github.com/repos/pandegroup/openmm/issues/1344","id":178189950,"user":{"login":"peastman","id":4379786,"avatar_url":"https://avatars.githubusercontent.com/u/4379786?v=3","gravatar_id":"","url":"https://api.github.com/users/peastman","html_url":"https://github.com/peastman","followers_url":"https://api.github.com/users/peastman/followers","following_url":"https://api.github.com/users/peastman/following{/other_user}","gists_url":"https://api.github.com/users/peastman/gists{/gist_id}","starred_url":"https://api.github.com/users/peastman/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/peastman/subscriptions","organizations_url":"https://api.github.com/users/peastman/orgs","repos_url":"https://api.github.com/users/peastman/repos","events_url":"https://api.github.com/users/peastman/events{/privacy}","received_events_url":"https://api.github.com/users/peastman/received_events","type":"User","site_admin":false},"created_at":"2016-02-01T21:05:59Z","updated_at":"2016-02-01T21:05:59Z","body":"The big difference between those two options is that the first one asks the force field developer to make the decision, while the second one asks the user to make the decision.  Could you comment on that?  Which of those is better?"}}