Frequently Asked Questions
- 1 General
- 2 Installation and Compilation
- 3 Running
- 4 Analysis
ESPResSo and ESPResSo++
- What is the relation between ESPResSo and ESPResSo++?
- 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:
- Lead development at the Institute for Computational Physics in Stuttgart, Germany
- 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
Installation and Compilation
Tcl/FFTW not found
configurecomplains 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
fftwthat contain the libraries itself, but you will also need the development packages (e.g.
libfftw3-dev), 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
- 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 ESPResSo. 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), ESPResSo 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 command:
- 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 ESPResSo on a BlueGene/P System ?
Recently we got ESPResSo 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 ESPResSo 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 ESPResSo 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:
#!/bin/ksh # @ job_name = testjob # @ error = $(job_name).$(jobid).out # @ output = $(job_name).$(jobid).out # @ environment = COPY_ALL # @ wall_clock_limit = 00:30:00 # @ notification = error # @ notify_user = firstname.lastname@example.org # @ job_type = bluegene # @ bg_size = 128 # @ queue = tiny_30m # # 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"6. Now submit the job:
Why does the feature XYZ not work?
- I have read that ESPResSo supports the feature xyz. Now that I try, ESPResSo doesn't seem to be able to handle it!
- Have you activated (i.e. compiled in) the corresponding feature? By default, ESPResSo only activates a certain number of features - not all features of ESPResSo are always compiled in. Out of efficiency reasons, it is recommended to only activate those features of ESPResSo, 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 ESPResSo of the User's Guide (see Documentation).
I get a Segmentation Fault when running my script!
- Sometimes, when I run my script, I get a segmentation fault!
- 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 ESPResSo. Please write a mailing to the mailing list, or report a bug in the bug tracker!
- 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
checkpointcould not work, out of two reasons. The main reason is that ESPResSo has no way to determine what information constitutes the actual state of the simulation. On the one hand, ESPResSo 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. ESPResSo has no way to distinguish between these variables. On the other hand, the ESPResSo 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 ESPResSo is running in parallel.
- Instead, in ESPResSo, the user has to specify what information needs to be saved to a file to be able to restore the simulation state. The
blockfilecommand helps you to do that.
Some coordinates are outside of the box!
- Why do the output files often contain particle coordinates that are outside the specified box size (box_l)? Why does part pid print pos return such coordinates?
- 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. 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 <pid> print folded_pos