{"action":"created","issue":{"url":"https://api.github.com/repos/choderalab/openmm/issues/4","repository_url":"https://api.github.com/repos/choderalab/openmm","labels_url":"https://api.github.com/repos/choderalab/openmm/issues/4/labels{/name}","comments_url":"https://api.github.com/repos/choderalab/openmm/issues/4/comments","events_url":"https://api.github.com/repos/choderalab/openmm/issues/4/events","html_url":"https://github.com/choderalab/openmm/issues/4","id":132755019,"number":4,"title":"ff14ipq - energy validation fails due to a rogue dihedral","user":{"login":"rafwiewiora","id":12088757,"avatar_url":"https://avatars.githubusercontent.com/u/12088757?v=3","gravatar_id":"","url":"https://api.github.com/users/rafwiewiora","html_url":"https://github.com/rafwiewiora","followers_url":"https://api.github.com/users/rafwiewiora/followers","following_url":"https://api.github.com/users/rafwiewiora/following{/other_user}","gists_url":"https://api.github.com/users/rafwiewiora/gists{/gist_id}","starred_url":"https://api.github.com/users/rafwiewiora/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/rafwiewiora/subscriptions","organizations_url":"https://api.github.com/users/rafwiewiora/orgs","repos_url":"https://api.github.com/users/rafwiewiora/repos","events_url":"https://api.github.com/users/rafwiewiora/events{/privacy}","received_events_url":"https://api.github.com/users/rafwiewiora/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":1,"created_at":"2016-02-10T16:46:33Z","updated_at":"2016-02-10T17:41:20Z","closed_at":null,"body":"@jchodera @swails \r\n\r\nff14ipq has been failing my energy validation on the Propers, by around 1.3 kJ/mol, which is about 5e-3 relative difference in this case (and I'm working with 1e-5 tolerance). This was only with villin, not ala_ala_ala.\r\n\r\nI've tracked it down to just one problematic dihedral in proline. This is how I did it just to make sure this workflow didn't introduce any further bias:\r\n- converted to ffxml (ff14ipq.xml)\r\n- prepared the .crd and .top for villin in AMBER\r\n- prepared an ffxml from the AMBER params:\r\n```\r\nparm = parmed.load_file('villin.top', 'villin.crd')\r\nparm = parmed.amber.AmberParameterSet.from_structure(parm)\r\nparm = parmed.omm.OpenMMParameterSet.from_parameterset(parm)\r\nparm.write('test.xml')\r\n```\r\n- manual inspection of course was useless, so I loaded both ffxml's in `ForceField` and looped over `ff._forces[2].proper` and `ff2._forces[2].proper` looking for matching dihedrals and then asserting equality of the lists of k's. \r\n\r\nAnd I caught this: \r\n- in ff14ipq.xml (conversion with the script):\r\n``` xml\r\n <Proper type1=\"TN\" type2=\"CX\" type3=\"C\" type4=\"N\" periodicity1=\"4\" phase1=\"0.0\" k1=\"-1.10357184\" periodicity2=\"3\" phase2=\"3.14159265359\" k2=\"-1.97618688\" periodicity3=\"2\" phase3=\"3.14159265359\" k3=\"6.13868112\" periodicity4=\"1\" phase4=\"3.14159265359\" k4=\"0.2600356\"/>\r\n```\r\n\r\n- test.xml (xml written from the AMBER params):\r\n``` xml\r\n<Proper type1=\"TN\" type2=\"CX\" type3=\"C\" type4=\"N\" periodicity1=\"1\" phase1=\"3.141594\" k1=\"0.2600356\"/>\r\n```\r\n\r\nIn the parm14ipq.dat (start line 2048):\r\n```\r\nN -CX-C -TN   1     0.14302    0.0 -4.0  Branched from N -CX-C -N , Fit by mdgx , Fit by mdgx , Fit by mdgx\r\nTN-CX-C -N    1    -0.26376    0.0 -4.0  Branched from N -CX-C -N , Fit by mdgx \r\nTN-CX-C -TN   1     0.04031    0.0 -4.0  Branched from N -CX-C -N \r\nN -CX-C -TN   1     0.12378  180.0 -3.0  Branched from N -CX-C -N , Fit by mdgx , Fit by mdgx , Fit by mdgx\r\nTN-CX-C -N    1    -0.47232  180.0 -3.0  Branched from N -CX-C -N , Fit by mdgx \r\nTN-CX-C -TN   1     0.06853  180.0 -3.0  Branched from N -CX-C -N \r\nN -CX-C -TN   1     0.98860  180.0 -2.0  Branched from N -CX-C -N , Fit by mdgx , Fit by mdgx , Fit by mdgx\r\nTN-CX-C -N    1     1.46718  180.0 -2.0  Branched from N -CX-C -N , Fit by mdgx \r\nTN-CX-C -TN   1     0.19829  180.0 -2.0  Branched from N -CX-C -N \r\nN -CX-C -TN   1    -0.17826  180.0  1.0  Branched from N -CX-C -N , Fit by mdgx , Fit by mdgx , Fit by mdgx\r\nTN-CX-C -N    1     0.06215  180.0  1.0  Branched from N -CX-C -N , Fit by mdgx , Fit by mdgx , Fit by mdgx\r\nTN-CX-C -TN   1     1.46258  180.0  1.0  Branched from N -CX-C -N \r\n```\r\n\r\n* So we've got - dihedral written in both directions with different params (N - CX - C - TN, TN - C - CX - N) - what is the meaning of this?\r\n* The periodicities in the dat are not line-by-line, ParmEd catches as as it waits for a non-negative number, but it appears that AMBER only considered the very last one with periodicity one in this case:\r\n```\r\nTN-CX-C -N    1     0.06215  180.0  1.0  Branched from N -CX-C -N , Fit by mdgx , Fit by mdgx , Fit by mdgx\r\n```"},"comment":{"url":"https://api.github.com/repos/choderalab/openmm/issues/comments/182497234","html_url":"https://github.com/choderalab/openmm/issues/4#issuecomment-182497234","issue_url":"https://api.github.com/repos/choderalab/openmm/issues/4","id":182497234,"user":{"login":"rafwiewiora","id":12088757,"avatar_url":"https://avatars.githubusercontent.com/u/12088757?v=3","gravatar_id":"","url":"https://api.github.com/users/rafwiewiora","html_url":"https://github.com/rafwiewiora","followers_url":"https://api.github.com/users/rafwiewiora/followers","following_url":"https://api.github.com/users/rafwiewiora/following{/other_user}","gists_url":"https://api.github.com/users/rafwiewiora/gists{/gist_id}","starred_url":"https://api.github.com/users/rafwiewiora/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/rafwiewiora/subscriptions","organizations_url":"https://api.github.com/users/rafwiewiora/orgs","repos_url":"https://api.github.com/users/rafwiewiora/repos","events_url":"https://api.github.com/users/rafwiewiora/events{/privacy}","received_events_url":"https://api.github.com/users/rafwiewiora/received_events","type":"User","site_admin":false},"created_at":"2016-02-10T17:41:20Z","updated_at":"2016-02-10T17:41:20Z","body":"> I don't see that in the text you posted... I see N-CX-C-TN and TN-CX-C-N (note these permute types 1 and 4 but not 2 and 3). Or is the other term printed somewhere else that you didn't report?\r\n\r\nOh yes, thanks! Too much staring at this here for me clearly. Ok so this is a smaller problem, good. \r\n\r\n> I'm not sure why ff14IPQ doesn't put the terms in order like every other parameter file does. I think tleap will read these correctly, but I'm not sure. Does the tleap-generated prmtop have 4 terms for dihedral types N-CX-C-TN? Or just 1? I know the guy that makes these files, so I can complain to him if leap is bungling this up. I'm pretty sure I know what ParmEd does (it loads in each of them as 4-term torsions, even though the type definitions are not consecutive like every other file). Maybe tleap doesn't do this...\r\n\r\nCan you help me out look through the prmtop please? https://gist.github.com/rafwiewiora/388c7571f3fb12c28bee I don't quite understand the structure of it, particularly where parameters for which angle sit given this with H - without H separation. \r\n\r\nBut if I just ctrl+f it: 6.21500000E-02 (per 1) is there in force constants, but 1.46718 (per 2) is not. So looks like the other periodicities are skipped / overwritten by tleap. \r\n\r\n> know the guy that makes these files, so I can complain to him if leap is bungling this up. I'm pretty sure I know what ParmEd does (it loads in each of them as 4-term torsions, even though the type definitions are not consecutive like every other file).\r\n\r\nYeah, ParmEd waits for the positive periodicity number. So are you saying if tleap is not getting all 4 periodicities it is doing a _wrong_ thing here and hence I should just ignore the energy fail here?"}}