Re: [ESPResSo-users] referring to stored configs separately

[Olaf Lenz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Koen!

On 03/26/2013 08:18 AM, Koen Nickmans wrote:
> 1. When a lennard-jones potential is shifted so that the potential
> is equal at a cutoff radius, how does espresso handle the
> calculation of forces around the cutoff point? I cannot find where
> this is discussed.

The standard LJ potential in ESPResSo does have a discontinuity in
the force at the cutoff radius. We do not handle the case otherwise. To
my knowledge, this is only important when you choose the cutoff radius
very small or want to simulate at very high accuracy. If you really need
this, it should not be very hard to extend the LJ potential accordingly.
We would be interested in that code if you write it.

> 2. During my simulation I store configurations at regular intervals
>  using the /analyze append /command, and write them with the
> blockfile command. In a next script I retrieve the configurations
> with /blockfile $file read auto. /How can I now refer to each
> stored configuration separately? What I would like is:
> 
> for /i/ number of configs { access config /i/ calculate property }

Unfortunately, it doesn't work like that.
The problem is that in ESPResSo a *configuration* only contains the
coordinates of all particles, but not all the additional information
that are required to restore the full *state* of the simulation, e.g.
the velocities, the interactions, etc. It is necessary to distinguish
between these two terms.

"analyze append" will only store the configuration. Therefore there is
no simple function to set the current simulation state from that
configuration, as it will be incomplete and may even be inconsistent.
The command "analyze append" is intended mostly for averaging analysis
commands, like "analyze <rdf>".

When you store the configurations in a blockfile via "blockfile
<channel> write configs", this still only means that you store all
configurations that you have collected via "analyze append" to disk.

Ultimately, what you are touching with your question is the problem of
checkpointing, i.e. a simple way to store and restore the state of the
simulation. The problem is that there is no way for ESPResSo to
determine what exactly is the state of the system that would need to be
stored, as this state may consist not only of particle data, but also of
Tcl variables, the random number generator state, etc. Some of these are
fully under control of the user that has written the ESPResSo script, so
ESPResSo has no chance to do anything with it. The only possible way
would be to store a full snapshot of the memory of the process, but even
that wouldn't work in all circumstances.

Therefore, ESPResSo has to rely on the user to tell it what information
constitutes the state of the system, and provides the different
blockfile functions to make this easy for the user, that allow you to
write out the coordinates, the bonds, the interactions, etc. to a
blockfile, and load the file using "blockfile read auto".

Sorry for the lengthy reply, but the question of checkpointing occurs
frequently, and so I thought I give a more detailed information here. I
will probably use this mailing to extend the User's Guide and the FAQ
accordingly.

Olaf

- -- 
Dr. rer. nat. Olaf Lenz
Institut für Computerphysik, Allmandring 3, D-70569 Stuttgart
Phone: +49-711-685-63607
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlFRYPwACgkQtQ3riQ3oo/p74QCeO2DPUT9P/HNYa0zbrLW2bpJQ
H/cAnRrIU1mdMQkeuNODBLkcmmz7Oc3q
=L5ui
-----END PGP SIGNATURE-----