Date: Thu, 9 May 2013 10:21:05 +0300
On Wed, May 08, 2013 at 05:34:52PM -0700, Bill Ross wrote:
> This sounds like a bug in my code from long ago, but I don't remember
> enough to comment in detail. One thing to make sure of is that
> impropers aren't being overlooked because of bad comparisons between
> molecule and FF atom types. It may be that it's just an issue with
> ordering the atoms in the prmtop, which would be less serious than
> missing terms.
>
> Bill
Thanks for the tip, but it seems that the comparison is not the
issue here. Although iParmSetFindImproperTerms() never returns
PARM_FOUND_EXACT so every time it loops all loaded parameter
libraries and I guess it ends up with what matched last.
The issue as I understand it now is that when saving parameters
leap puts them in unit (molecule) for each improper type, but it
does not pass sOrder from parameter lib to unit, so the sOrder
in unit is different (it is sorted there). Since improper type
in unit is written after reordering atoms, the firs improper
gets atom order from parameter lib while the subsequent ones get
it from the improper type in unit (so they will be sorted and
that may or may not be the same order as in original parameter
file).
For clarity attached a picture with call graph. The issue is
that both codepaths are calling iParmSetAddImproperTerm with
different atom type order.
Also attached a proof of concept patch which fixes the issue for
my test case. It needs similar treatment in other conditionals
within that function to cover all cases. And it might be
possible to do it without duplication of ParmSetTORSIONTerm(),
but that would require adjusting all its callers and I didn't
want to touch other parts of the code.
Reinis
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
(image/png attachment: leap_cg.png)
- text/x-diff attachment: leap_improper_atom_order.patch
