[MMTK] Re: Several questions

Konrad Hinsen hinsen@cnrs-orleans.fr
20 Nov 2001 19:56:50 +0100

Berit Hinnemann <Berit.Hinnemann@fysik.dtu.dk> writes:

> What do you mean by higher-level object definition? Is is the charge
> in the definition file or the individually defined charge defined by
> "atom.amber_charge"? Wouldn't it be logical, if the individual

The basic idea is that atom properties from the database are fixed and
are not changed dynamically. There is currently no provision for this
at all. The charge is defined by the force field, period. I am not
saying that it has to remain so, but currently, that's what it is.
There are several parts of MMTK that assume atom properties to be
constant, so changing this is not trivial.

Starting from this fact, "atom.amber_charge" would normally not be an
attribute that has been assigned to an individual atom, but the value
of the "amber_charge" property defined in the atom type. There are no
charges defined in the atom type definitions (because there is no
need), but you can do that: add "amber_charge = 0." to the definition
file for carbon, create a carbon atom, and print "atom.amber_charge",
it will return 0.

When the energy evaluator compiles a table of all charges (which is
done only once, so again there is the assumption that charges don't
change), it starts at the highest-level chemical object of which an
atom is part. For example, if your atom is part of a peptide group
within a residue within a peptide chain within a protein, then the
energy evaluator will start looking for the charge at the protein
level. If there is no entry, it looks at the peptide chain level, and
so on. The atom level is looked at last.

This arrangement makes sense from the point of view of keeping the
database simple. For example, the atoms in a peptide group would
normally always have the same charges, but if in one particular
residue type it requires different charges, the residue type
definition can override the definitions made at the peptide group

Actually, I am wondering why you want to change individual atom
charges. Changing any single charge without changing all others will
in general produce an inconsistent charge set. I know a few
applications in which charges are not constant (e.g. a force field
with charge equilibration), but then the charges would not be force
field parameters at all, and not be written into the database.
So could you tell me a bit more about your application?

> default value out of the definition file is used. At the moment, you
> would have to create a new definition file without charges in order
> to assign individual charges.

Exactly. At least for the Amber force field. The parameter lookup
procedure is part of the force field definition, so you could in
principle implement a force field that does it as you would like. That
is not even very complicated, you would only need to override the
method collectCharges (defined in class
ForceFields.MMForceField.MMAtomParameters) by another one that gives
priority to the atom-level attributes.

> I have another question concerning the output into a PDB file. In which
> order are the atoms within a residue/molecule written out? I noticed

The order is in general undefined, or rather unpredictable. Which
shouldn't matter as the names are unique within one residue. I know
that some programs have difficulties reading files that do not use a
particular order, but since the PDB standard does not specify an
order, I see no way to satisfy everybody.

> that the PDB output has the same order as the atoms are listed in
> "res.pdbmap", where "res" is an amino acid residue. Is it indeed
> determined by that and where? I could only understand that the attribute

Yes and no. To write out all atoms, the code iterates over the
elements of the dictionary in the pdbmap. Python does not define the
order of such an iteration, it could change every time you run a

> I assume that for a given residue the output order of the atoms is
> always the same?

No! In practice maybe, but nothing guarantees this.

> V/2i*(1+cos(n*phi-gamma)). If V=0, how can this term give an energy
> contribution? And if it doesn't, why do they list it (I tried removing
> it and it made a difference in energy)?

I didn't look up your particular example, but in general, zero entries
can exist to override generic entries that would match the same atom
pattern. When a more specific pattern exists, the generic one is not

Konrad Hinsen                            | E-Mail: hinsen@cnrs-orleans.fr
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-
Rue Charles Sadron                       | Fax:  +33-
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais