Frequently Asked Questions

and ESPResSo++

 * Question
 * What is the relation between and ESPResSo++?


 * Answer
 * Originally, ESPResSo++ started off as a rewrite of the ESPResSo package and was intended to become its successor. However, it turned out that the original package had a lot of functionality that the new implementation was still lacking after several years of development, and furthermore a lively community that was attracting new developers that were adding even more new features. Adding to that, the application cases and focus of both packages started to drift apart. Therefore, we now consider them as two separate packages that share the same spirit and have partly the same developers.


 * To highlight the main differences between both packages:


 * ESPResSo


 * Lead development at the Institute for Computational Physics in Stuttgart, Germany
 * http://espressomd.org
 * Unique features:
 * Various methods for electrostatics and magnetic interactions
 * Coupling of the particles to mesoscopic fluid methods to incorporate hydrodynamic interactions
 * Particles can form flexible or rigid agglomerates


 * ESPResSo++


 * Lead development at the Max-Planck-Institute for Polymer Research in Mainz, Germany
 * http://www.espresso-pp.de
 * As for the unique features of ESPResSo++, maybe Torsten is the better person to reply

Tcl/FFTW not found

 * Question
 * complains that it can't find Tcl or FFTW!


 * Answer 1
 * Did you already install Tcl/Tk and FFTW3? If not, do so! Most Linux distributions provide packages for both.
 * Note that in many cases it is not enough to install the packages  and   that contain the libraries itself, but you will also need the development packages (e.g.   and  ), that contain the header include files. Also, you need FFTW3. FFTW version 2 is not supported anymore. Unfortunately, FFTW2 still seems to be the standard FFTW package in Ubuntu.


 * Answer 2 (when it was installed in a non-standard location)
 * If you have installed the packages, but you couldn't install them into one of the default system paths (/usr or /usr/local), you'll have to pass the information where to find the packages to the configure script. To do that, you can pass additional include and library paths to the configure script via the variables CPPFLAGS and LDFLAGS, like

configure CPPFLAGS="-I/path/to/tcl/include" LDFLAGS="-L/path/to/tcl/lib"


 * These and other variables are documented via

configure --help


 * Answer 3 (when Tcl was built from source)
 * Out of whatever reason, the most recent Tcl versions do not by default build the static Tcl libraries anymore, which are required by . To get it to build the static libraries, you will have to pass the option --disable-shared to the configure script of the Tcl library only. Then, it will build the static library. Unfortunately, it will not build the dynamic library anymore. If you need both, you will have to configure, build and install Tcl twice.


 * Answer 4 (only on 64bit machines)
 * If you are using Linux on a 64bit machine (e.g. an AMD 64), will try to build a 64bit binary to obtain maximal efficiency. Unfortunately, it is still not uncommon that 64bit machines have a 32bit Linux and corresponding 32bit libraries (Tcl, FFTW).
 * You can check whether you have a 64bit machine by executing one of the commands

cat /proc/cpuinfo uname -a gcc -dumpmachine


 * If you have a 64bit machine, you should check whether the Tcl library libtcl*.a and the FFTW library libfftw*.a are 64bit binaries via the file</tt> command:

file libtcl.a


 * If they are not, you have a number of possibilities:
 * In fact, the best solution is to install a 64bit Linux on the machine. By using a 32bit Linux on a 64bit machine, you basically waste half of the machines capabilities!
 * Install 64bit versions of the libraries. Many Linux distributions allow to have at least 64bit versions of libraries in parallel to the 32bit versions and provide corresponding packages. If not, you will have to build the libraries yourself. To learn how to build 64bit libraries, refer to the corresponding documentation of the libraries.

How do I compile on a BlueGene/P System ?
Recently we got to compile and run on the BlueGene/P at the RZG of the Max Planck Society. We have not yet run any benchmarks on this system, so we can tell nothing about performance or scaling behaviour yet. Following is a description of what we had to do, to get to compile and run on the BlueGene/P:

1. Login to the front node "genius"

2. Set your CC environment variable CC to mpicc: setenv CC mpicc (where "which mpicc" should point to something similar to bgsys/drivers/ppcfloor/comm/bin/mpicc)

3. Get a tcl/tk source package, e.g. from sourceforge.net - we used tcl8.4.14-src.tar.gz, newer versions are likely to work too. After unpacking do the following: cd tcl8.4.14/unix ./configure --prefix=$HOME/software --disable-shared --disable-threads --disable-load make make install

4. Enter the directory: cd $SOMEPATH/espresso-2.1.2j ./configure CFLAGS="-I $HOME/software/include" LDFLAGS="-L $HOME/software/lib" LIBS="-lm -lc" make

5. A job submit script could look like this: # # P=/path/BlueGene/src/espresso-2.1.2j \ mpirun -exe $P/obj-unknown-pc-linux/Espresso_bin \ -env ESPRESSO_SCRIPTS=$P/scripts -mode VN -cwd $P \ -args "$P/test_lj_liquid.tcl"
 * 1) !/bin/ksh
 * 2) @ job_name = testjob
 * 3) @ error = $(job_name).$(jobid).out
 * 4) @ output = $(job_name).$(jobid).out
 * 5) @ environment = COPY_ALL
 * 6) @ wall_clock_limit = 00:30:00
 * 7) @ notification = error
 * 8) @ notify_user = your@email.address
 * 9) @ job_type = bluegene
 * 10) @ bg_size = 128
 * 11) @ queue = tiny_30m

6. Now submit the job: llsubmit test.job

Why does the feature XYZ not work?

 * Question
 * I have read that supports the feature xyz. Now that I try,  doesn't seem to be able to handle it!


 * Answer
 * Have you activated (i.e. compiled in) the corresponding feature? By default, only activates a certain number of features - not all features of  are always compiled in. Out of efficiency reasons, it is recommended to only activate those features of, that you actually require.
 * To learn how to activate or deactivate features, read the section myconfig.h: Activating and deactivating features in the chapter Compiling and installing  of the User's Guide (see Documentation).

I get a Segmentation Fault when running my script!

 * Question
 * Sometimes, when I run my script, I get a segmentation fault!


 * Answer
 * Please check what version of MPI (if any) you are using. If you are using OpenMPI of a version less than 1.4, it seems to be a bug in OpenMPI.
 * If you are not using OpenMPI, or a version 1.4 or later, then this is usually a sign of a bug in . Please write a mailing to the mailing list, or report a bug in the bug tracker!

Checkpointing

 * Question
 * How can I checkpoint my simulation, i.e. how can I write the current state of my simulation to a file? Why is there no simple command ?


 * Answer (from the User's Guide)
 * Unfortunately, a simple command  could not work, out of two reasons. The main reason is that  has no way to determine what information constitutes the actual state of the simulation.  On the one hand,  scripts sometimes use Tcl-variables that contain essential information about a simulation, e.g. the stored values of an observable that was computed in previous time steps, counters, etc.  These would have to be contained in a checkpoint. However, not all Tcl-variables are of interest. For example, Tcl has a number of automatically set variables that contain information about the hostname, the machine type, etc. These variables should most probably not be included the simulation state.  has no way to distinguish between these variables.  On the other hand, the  core has a number of internal variables, e.g. the particle coordinates. While most of these are probably good candidates for being included into a checkpoint, this is not  necessarily so.  For example, when you have particles in your system that have fixed coordinates, should these be stored in a checkpoint, or not?  If the system contains mostly fixed particles and only very few moving particles, this would increase the memory size of a checkpoint needlessly. And what about the interactions in the system, or the bonds? Should these be stored in a checkpoint, or are they generated by the script?
 * Another problem with a generic checkpoint would be the control flow of the script. In principle, the checkpoint would have to store where in the script the checkpointing function was called to be able to return there. All this is even further complicated by the fact that  is running in parallel.
 * Instead, in, the user has to specify what information needs to be saved to a file to be able to restore the simulation state. The   command helps you to do that.

Some coordinates are outside of the box!

 * Question
 * Why do the output files often contain particle coordinates that are outside the specified box size (box_l</tt>)? Why does part pid print pos</tt> return such coordinates?


 * Answer
 * In a periodic system, the particle positions are stored in absolute coordinates, i.e. when a particle crosses the boundary of a box, the coordinates are not folded back into the central image. However, all particles nonetheless interact with all images of all other particles, which is defined by the box size box_l</tt>. The reason for this behavior is, that it allows to compute observables like the mean square displacement of a particle after some time.


 * To get the coordinates of the central image of a particle, you can use the command part print folded_pos