It can't have any effect on production in this case, because the only time
one parameter overwrites another is when I am doing fitting exercises.
That's what's going to change. No parameter overwrites any other when
reading a topology--they are all stored, verbatim.
On Fri, Mar 25, 2016 at 12:04 PM, Jason Swails <jason.swails.gmail.com>
wrote:
> On Fri, Mar 25, 2016 at 11:07 AM, David Cerutti <dscerutti.gmail.com>
> wrote:
>
> > Yes, I agree--in the mdgx topology data structures, for executing the
> > energy function, the propers and impropers are all in a list, but each
> has
> > a flag. For parameter development, there is again one long list of
> > "dihedral" data structures read from the parm.dat files, and again each o
> > them has a flag 0 or 1 to indicate proper or improper.
>
>
> This is important for preventing an improper type being assigned to a
> proper type and vice-versa, but unless I'm misunderstanding you it's not
> enough to ensure that you don't "lose" a parameter if proper and improper
> torsions share the same type sequence.
>
> The moral here is to use separate lists to store improper and proper
> torsion parameters with separate sets of 4-type keys identifying the atom
> types involved in each parameter. That they appear in the same list in the
> prmtop file is an artifact of convenience. Remember that parameter
> assignment was already done inside tleap from two separate lists (one for
> propers and one for impropers) *before* they were combined into the same
> list in the prmtop. So if a system has both an improper and a proper
> torsion containing the same atom type sequence, it wouldn't matter.
>
> Simply put, if mdgx can't store both
>
> IMPROPER ca-nh-ca-c
> PROPER ca-nh-ca-c
>
> then you are risking not being able to faithfully store and/or represent
> the Amber force field in the general sense.
>
> It may never affect anything in production or it might. It may be a
> simple error that causes a crash (due to an unidentified parameter), or it
> might not. It's impossible to tell. But it opens up the possibility for a
> subtle issue that can have profound importance, but is incredibly difficult
> to even detect. I simply don't know...
>
> As a reference, have a look at how ParmEd handles this:
> https://github.com/ParmEd/ParmEd/blob/master/parmed/parameters.py#L87-L89
>
> Separate sets of keys for proper, improper (and periodic improper, which
> is the functional type Amber uses).
>
> All the best,
> Jason
>
> --
> Jason M. Swails
> _______________________________________________
> 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 Fri Mar 25 2016 - 09:30:05 PDT
