Hi,
Welcome to the wild and sometimes insane world of parameter assignment
in LEaP. (No disrespect intended, it's an amazing program, but
sometimes difficult to comprehend, at least for me).
A while back, I (maybe foolishly) decided I was going to put parameter
assignment code into CPPTRAJ so that it could go from PDB to topology
just like LEaP. I was doing this during the development of modXNA
because it made building some systems easier. There is still a branch
of CPPTRAJ that can do full parameter assignment, but I haven't merged
it into the main yet because I'm super paranoid I'm still missing
something. Impropers took me a while to figure out and I'm still not
100% sure I've got it down. That said, I'll see if I can at least
point you in the right direction.
You're right that the Amber convention for impropers is usually to
have the third atom be the "central" atom, and the non-central
improper atom types sorted alphabetically (with wildcards given
precedence), but this is not always the case and does not always work.
It seems that ultimately LEaP will respect whatever the ordering is in
the parameter file itself, e.g. C -XC-N -H in parm19.dat. The biggest
hangup for me with impropers was the existence of improper wildcard
parameters, something like X-X-CW-H4 for example. For example, using
straight up backwards/forwards matching, the wildcard type X-X-CW-H4
will not match the given alphabetized type C*-H4-CW-NA. All
combinations of A1, A2, and A4 should be checked.
Also, there are a lot of improper-specific things that LEaP does
during improper parameter assignment. You need to set up a cache for
the improper parameters. When going over the list of impropers, If no
parameter is found it is not added to the list of improper dihedrals.
However, if no parameter is found and the central atom is SP2, LEaP
prints a warning. When you find an improper parameter, it is added to
the cache. When looking in the cache, if the cached improper has
wildcards LEaP looks to see if there is a more specific one in the new
improper parameters. If a more specific improper (fewer wildcards) is
found, that is what is used.
Anyway, I'm sure I'm missing some stuff (it has been a while since I
wrote that code) but hopefully that gives you some clues. I've been
wanting to merge the code that I've written in for a long time now,
but as you may have heard there have been a few difficulties and
obstacles at my current place of employment which have made it
difficult to get any real work done over the past few months. I'll try
to make an effort to get the code merged in, but if I don't I can at
least point you to where it is - maybe it will be useful to you (not
that my code is always so clear).
Good luck! Hope (at least some of) this helps!
-Dan
On Mon, Aug 11, 2025 at 6:57 PM Evan Pretti via AMBER <amber.ambermd.org> wrote:
>
> Hello,
>
> As an OpenMM developer, I'm working on improving the coverage of validation tests for our conversions of Amber force fields to OpenMM format (mostly, comparing energies of various systems with different FFs between LEaP+sander vs. OpenMM). I've traced some small differences down to ordering of the peripheral atoms in improper dihedrals. Of course this is a minor problem since the impropers will keep things planar as long as the central atom is correct, but it's annoying enough for the validation, and I'd like OpenMM to be able to reproduce the correct behavior if possible.
>
> In particular, I've found that if the peripheral atom types for an improper in a parameter file are not in sorted order, LEaP may assign the first matching improper in the order of the parameter file, and subsequent impropers in the sorted order. Reading the thread starting at <http://archive.ambermd.org/201305/0108.html>, this seems to be a LEaP bug related to how it saves torsion data in units when assigning parameters.
>
> The Amber manual (section 15.1.6) says that the peripheral atom types (first, second, and fourth) are supposed to be sorted to begin with, but some Amber force field files violate this rule. For instance, in LEaP, load leaprc.protein.fb15 and save parameters for the sequence { ACE PHE PHE NME }. The first PHE will get the improper CD1-CD2-CG-CB, and the second PHE will get the improper CB-CD1-CG-CD2. The improper type is CA-CA-CA-6F at line 1975 of frcmod.fb15. The first assigned improper follows the order in the frcmod, while subsequent ones use the sorted order 6F-CA-CA-CA. This is one example of the problem; I have found several others for other force fields and residues, though I don't have an exhaustive list.
>
> I couldn't find a consensus on the correct behavior in the above linked thread, and apparently the issue hasn't been fixed. Assuming this is a bug, what is the intended correct behavior that we should try to match? When there is a discrepancy between the parameter file and the expected sorted order, should we use the order in the parameter file, or the sorted order?
>
> Thanks,
> Evan Pretti
> _______________________________________________
> 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 Tue Aug 12 2025 - 06:30:02 PDT
