[MMTK] external fields

Richard Graham richard at rdg.cc
Fri Aug 30 20:31:02 UTC 2013


Hi Konrad,

Thanks again for your reply. That does clear up some things but I still
have some confusion.

By the way, my application is very simple, the field applies to every
atom and has the form of a harmonic potential relative to a fixed point
in space. I need only a couple of constants when making it to specify
the strength. I will only have a few atoms in my simulation.

I am still not sure where exactly I set the force on each atom. The dict
I was referring to is the one returned by an individual computation
method. In the electric field example I see the keys 'energy', 'virial',
'force_constants' etc. Do I set the force through these (force_constants
entry?) or do I somehow write into the individual atoms via the
universe/configuration? What keys are required?

Also, as a sanity check I tried to make a very simple simulation
starting with two ions in a universe a few um apart. I want to see that
they fly apart by the coulomb force when I start the simulation. I
wasn't able to get this to work. It seems that I can't use the
AmberForceFields when the universe only has atoms. It needs to contain
something more complicated otherwise I get a
 AttributeError: 'AtomType' object has no attribute 'amber_atom_type'
when I try and run the integrator. Is there a reason for this? Perhaps I
need to restrict the forcefield to just electrostatics?

Thanks!

Richard Graham



On 08/30/2013 04:09 AM, Konrad Hinsen wrote:
> Richard Graham writes:
> 
>  > By my understanding, basically what I need to do is write a new
>  > forcefield representing my trapping potential. I will add this to one of
>  > the built in force fields and do a molecular dynamics simulation.
> 
> Right.
> 
>  > The force field is something with an evaluatorTerms method that
>  > returns something with an evaluate method. This method will need to
> 
> True but there are more conditions. For example, a force field must be
> a subclass of MMTK.ForceFields.ForceField. That's why it's best to
> start from a working force field and modify it.
> 
>  > go through everything in the given universe and work out the force
>  > based on its position. This then somehow goes in the results dict.
> 
> It's not a dictionary, it's a list of Python objects that represent
> the computational routines.
> 
> The idea behind decomposing the energy evaluation into two steps
> (ForceField.evaluatorTerms() and EnergyTerm.evaluate()) is that the
> first step needs to be done only once for a universe, whereas the
> second one needs to be redone for each configuration. Obviously you
> want to do as much of the work as possible in the first step.
> 
> 
> For writing a new force field term, I suggest starting by thinking
> about what information it depends on and how you would like to provide
> it.  What is trapped by your force field? Any atom? A specific atom?
> The center of mass of a group of atoms? Next, what is the trap defined
> by? A fixed point in space? Another atom or group of atoms? Finally,
> what is the functional form of the interaction, which parameters enter
> into it, and where do they come from?
> 
> Any information other than the universe must be a parameter to your
> force field class. Its energyTerms() method should then combine this
> information with whatever information you need from the universe,
> and package all that in a convenient way for the final step, the
> energy evaluator.
> 
>  > Do you have any standard interface for the integrator 'actions' objects?
> 
> Yes, but it's not really documented. The best starting point is the Cython
> module MMTK_trajectory_action.
> 
> Note that these actions are completely unrelated to force field
> terms. There is no communication between the two, except they both
> have access to the current configuration.
> 
>  > I noticed that when creating an atom, it seems to get an average mass of
>  > all the isotopes. If seems like it would be better for the atom to have
>  > a randomly selected isotope weighted by the natural abundances when created.
> 
> In theory, that looks like a good approach. In practice, it makes
> simulations non-reproducible because all results will vary slightly at
> each run due to the different masses. It then becomes rather difficult
> to test and debug simulation code.
> 
> Note that you can change the mass of each atom after it has been created,
> so if you want randomly drawn masses, you can do that.
> 
> Konrad.
> 






More information about the mmtk mailing list