> On Jul 27, 2018, at 11:20 PM, Matias Machado <mmachado.pasteur.edu.uy> wrote:
>
> Dear Amber experts,
>
> I found some issues while using the command addLJType of Parmed (AmberTools 16-18).
>
> To exemplify the problem let assume a system with just 2 atom-types (named I and J in the force field) with the same LJ parameters.
>
> When generating the topology, Leap will merge these two atom-types into a so called unique vdW-type "[1]".
>
> The issues arise when executing the following commands in Parmed to edit the topology:
>
> addLJType .%I ;# This is OK, atom-type I is assigned to a new vdW-type "[2]", the problems come with the next commands...
> addLJType @%J ;# Because I and J already belong to different vdW-types ([1] and [2]), a new vdW-type "[3]" is created for a non-existing atom-type " "
>
> addLJType .%K ;# Also creates a new vdW-type "[4]" for a non-existing atom-type " "
>
> In both cases a new vdW-type is created and linked to a ghost atom-type, which is impossible to edit or trace...
>
> After saving the modified topology new LJ pointers as well as A and B coefficients are written to the file, however they remain as "orphan parameters" in the topology...
>
> I don't know if this is a harmless bug or it does affect the simulation, but the desired behavior for addLJType would be do nothing if the mask points to a non-existing atom-type or if the selection in the mask is irreducible.
It’s harmless. If no atom types point to those parameters, they will never be used. It may use a few bytes of extra memory, but it’ll have no effect on the correctness of the topology file. Sometimes the easiest thing to do is to leave the orphan parameters there if they get orphaned by removing the last atom of a particular type (removing a type will require that *all* of the pointers get recalculated and regenerated, and it will become a bookkeeping nightmare).
However, it would be sensible to avoid creating parameters that are *always* orphaned when it’s so easily avoided.
>
> That would be particularly helpful for applying general fixes/modifications to LJ parameters of any topology without the need to be sure about the presence of all the involved atom-types
I’m not sure what the problem is here. If the atom type does not exist, no parameters get changed. If it does exist but references no atoms, the only terms that get changed are terms that are never referenced or used. The net result is the same.
In summary: this behavior never leads to incorrect or unexpected simulation results.
Thanks,
Jason
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Wed Aug 01 2018 - 14:30:04 PDT
