I am too far from this now to validate what you have done, though it
sounds like you have a grasp of it. I leave it to the current Amber crew
to validate and apply to the other cases you mention.
It would be interesting to generate prmtops both ways and see the
effects. I'm not sure that they would have a significant effect on the
Hamiltonian.
Bill
On 5/9/2013 12:21 AM, Reinis Danne wrote:
> 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
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Sat May 11 2013 - 12:00:02 PDT
