SimGrid
3.13
Versatile Simulation of Distributed Systems
|
SimGrid should work out of the box on Linux, Mac OSX, FreeBSD, and Windows (under windows, only the Java interfaces are available at the moment).
The easiest way to install SimGrid is to go for a binary package. Under Debian or Ubuntu, this is very easy as SimGrid is directly integrated to the official repositories. If you just want to use Java, simply copy the jar file on your disk and you're set.
Recompiling an official archive is not much more complex. SimGrid has very few dependencies and rely only on very standard tools. First, download the SimGrid-3.13.tar.gz archive from the download page. Then, recompiling the archive should be done in a few lines:
If you want to stay on the bleeding edge, you should get the latest git version, and recompile it as you would do for an official archive. Depending on the files you change in the source tree, some extra tools may be needed.
Most of the developers use a Debian or Ubuntu system, and some of us happen to be Debian Maintainers, so the packages for these systems are well integrated with these systems and very up-to-date. To install them, simply type:
apt-get install simgrid
For other Linux variants, you probably want to go for a source install. Please contact us if you want to contribute the build scripts for your preferred distribution.
The easiest way to install the Java bindings of SimGrid is to grab the jar file from the download page and copy it in your classpath (typically, in the same directory as your source code). If you go for that version, there is no need to install the C library as it is already bundled within the jar file. Actually, only a bunch of architectures are supported this way to keep the jar file size under control and because we don't have access to every exotic architectures ourselves.
If the jarfile fails on you, complaining that your architecture is not supported, drop us an email on simgr. We may extend the jarfile for you, provided we have access to this particular architecture to build SimGrid on it. id-d evel@ list s.gfo rge. inria .fr
If the error message is about the boost-context library, then you should install that library on your machine. This is a known issue in the 3.12 release that will be fixed in the next release.
You can retrieve a nightly build of the jar file from our autobuilders. For Windows, head to AppVeyor. Click on the artefact link on the right, and grab your file. If the latest build failed, there will be no artefact. Then you will need to first click on "History" on the top and search for the last successful build. For non-Windows systems (Linux, Mac or FreeBSD), head to Jenkins. In the build history, pick the last green (or at least yellow) build that is not blinking (i.e., not currently under build). In the list, pick a system that is close to yours, and click on the ball in the Debug row. The build artefact will appear on the top of the resulting page.
SimGrid only uses very standard tools:
fink install boost1.53.nopython
, or with homebrew: brew install boost
apt-get install libboost-dev libboost-context-dev
For platform specific details, please see Building on Mac OS X and Building on Windows.
If you just want to use SimGrid, you should probably grab the latest stable version available from the download page. We do our best to release soon and release often, but sometimes you need to install the developer version of SimGrid, directly from the git repository.
git clone git://scm.gforge.inria.fr/simgrid/simgrid.git simgrid
Note that compile-time options are very different from run-time options.
The default configuration should be fine for most usages, but if you need to change something, there are several ways to do so. First, you can use environment variables. For example, you can change the compilers used by issuing these commands before launching cmake:
export CC=gcc-4.7 export CXX=g++-4.7
Note that other variables are available, such as CFLAGS and CXXFLAGS to add options respectively for the C and C++ compilers.
Another way to do so is to use the -D argument of cmake as follows. Note that the terminating dot is mandatory (see Compiling into a separate directory to understand its meaning).
cmake -DCC=clang -DCXX=clang++ .
Finally, you can use a graphical interface such as ccmake to change these settings. Simply follow the instructions after starting the interface.
ccmake .
In addition to the classical cmake configuration variables, SimGrid accepts several options, as listed below.
If you need to empty the cache of values saved by cmake (either because you added a new library or because something seriously went wrong), you can simply delete the file CMakeCache.txt that is created at the root of the source tree. You may also want to directly edit this file in some circumstances.
By default, the files produced during the compilation are placed in the source directory. As compilation generates a lot of files, it is advised to put them all in a separate directory. It is then easier to cleanup, and this allows to compile several configurations out of the same source tree. For that, simply enter the directory where you want the produced files to land, and invoke cmake (or ccmake) with the full path to the SimGrid source as last argument. This approach is called "out-of-source-tree compilation".
mkdir build cd build cmake [options] .. make
SimGrid compiles like a charm with clang (version 3.0 or higher) on Mac OS X:
cmake -DCMAKE_C_COMPILER=/path/to/clang -DCMAKE_CXX_COMPILER=/path/to/clang++ . make
With the XCode version of clang 4.1, you may get the following error message:
CMake Error: Parse error in cache file build_dir/CMakeCache.txt. Offending entry: /SDKs/MacOSX10.8.sdk
In that case, edit the CMakeCache.txt file directly, so that the CMAKE_OSX_SYSROOT is similar to the following. Don't worry about the warning that the "-pthread" argument is not used, if it appears.
CMAKE_OSX_SYSROOT:PATH=/Applications/XCode.app/Contents/Developer/Platforms/MacOSX.platform/Developer
In the El Capitan version of Max OS X, Apple decided that users don't need no /usr/include directory anymore. If you are hit by this pure madness, just run the following command to restore that classical UNIX directory: xcode-select -install
Building from the source on Windows, may be something of an adventure. We never managed to compile SimGrid with something else than MinGW-64 ourselves. We usually use the activestate version of Perl, and the msys version of git on this architecture, but YMMV. You can have a look at the configuration scripts in the appveyor.yml file, but you are basically on your own here. Sorry. We are not fluent with Windows so we cannot really help.
The drawback of MinGW-64 is that the produced DLL are not compatible with MS Visual C. If you need it, clang-cl sounds promising. If you manage to get something working, please tell us how you achieved it.
In most cases, compiling and installing SimGrid is enough:
make make install # try "sudo make install" if you don't have the permission to write
In addition, several compilation targets are provided in SimGrid. If your system is well configured, the full list of targets is available for completion when using the Tab key. Note that some of the existing targets are not really for public consumption so don't worry if some stuff doesn't work for you.
make simgrid Build only the SimGrid library and not any example make masterslave Build only this example (and its dependencies) make clean Clean the results of a previous compilation make install Install the project (doc/ bin/ lib/ include/) make uninstall Uninstall the project (doc/ bin/ lib/ include/) make dist Build a distribution archive (tgz) make distcheck Check the dist (make + make dist + tests on the distribution) make documentation Create SimGrid documentation
If you want to see what is really happening, try adding VERBOSE=1 to your compilation requests:
make VERBOSE=1
Once everything is built, you may want to test the result. SimGrid comes with an extensive set of regression tests (see that page of the insider manual for more details). Running the tests is done using the ctest binary that comes with cmake. These tests are run for every commit and the result is publicly available.
ctest # Launch all tests ctest -R msg # Launch only the tests which name match the string "msg" ctest -j4 # Launch all tests in parallel, at most 4 at the same time ctest --verbose # Display all details on what's going on ctest --output-on-failure # Only get verbose for the tests that fail ctest -R msg- -j5 --output-on-failure # You changed MSG and want to check that you didn't break anything, huh? # That's fine, I do so all the time myself.
Do not build your simulator by modifying the SimGrid examples. Go outside the SimGrid source tree and create your own working directory (say /home/joe/SimGrid/MyFirstScheduler/
).
Suppose your simulation has the following structure (remember it is just an example to illustrate a possible way to compile everything; feel free to organize it as you want).
sched.h
: a description of the core of the scheduler (i.e. which functions are can be used by the agents). For example we could find the following functions (master, forwarder, slave). sched.c
: a C file including sched.h
and implementing the core of the scheduler. Most of these functions use the MSG functions defined in section Task Actions. masterslave.c
: a C file with the main function, i.e. the MSG initialization (MSG_init()), the platform creation (e.g. with MSG_create_environment()), the deployment phase (e.g. with MSG_function_register() and MSG_launch_application()) and the call to MSG_main()).To compile such a program, we suggest to use the following Makefile. It is a generic Makefile that we have used many times with our students when we teach the C language.
# The first rule of a Makefile is the default target. It will be built when make is called with no parameter # Here, we want to build the binary 'masterslave' all: masterslave # This second rule lists the dependencies of the masterslave binary # How this dependencies are linked is described in an implicit rule below masterslave: masterslave.o sched.o # These third give the dependencies of the each source file masterslave.o: masterslave.c sched.h # list every .h that you use sched.o: sched.c sched.h # Some configuration SIMGRID_INSTALL_PATH = /opt/simgrid # Where you installed simgrid CC = gcc # Your compiler WARNING = -Wshadow -Wcast-align -Waggregate-return -Wmissing-prototypes \ -Wmissing-declarations -Wstrict-prototypes -Wmissing-prototypes \ -Wmissing-declarations -Wmissing-noreturn -Wredundant-decls \ -Wnested-externs -Wpointer-arith -Wwrite-strings -finline-functions # CFLAGS = -g -O0 $(WARNINGS) # Use this line to make debugging easier CFLAGS = -g -O2 $(WARNINGS) # Use this line to get better performance # No change should be mandated past that line ############################################# # The following are implicit rules, used by default to actually build # the targets for which you listed the dependencies above. # The blanks before the $(CC) must be a Tab char, not spaces %: %.o $(CC) -L$(SIMGRID_INSTALL_PATH)/lib/ $(CFLAGS) $^ -lsimgrid -o $@ %.o: %.c $(CC) -I$(SIMGRID_INSTALL_PATH)/include $(CFLAGS) -c -o $@ $< clean: rm -f *.o *~ .PHONY: clean
The comments of this file should be enough to understand what's going on. If you are completely new to makefiles, you should install the make-doc
package and type this command in a terminal: info make
.
Sometimes, the following error message (or similar) will be produced.
masterworker.c:209: undefined reference to `sg_version_check' masterworker.c:209: undefined reference to `MSG_init_nocheck' (and possibly many other undefined references)
It means that the system does not manage to find simgrid when it tries to execute your programs. Specify where to search with the LD_LIBRARY_PATH
variable. Try running the following command before executing your code. If it helps, you should add this line to your ~/.bashrc so that it gets executed each time you log into your computer.
export LD_LIBRARY_PATH=/opt/simgrid/lib
On a multiarch x86_64 Linux, it should be possible to compile a 32 bit version of SimGrid with something like:
CFLAGS=-m32 \ CXXFLAGS=-m32 \ PKG_CONFIG_LIBDIR=/usr/lib/i386-linux-gnu/pkgconfig/ \ cmake . \ -DCMAKE_SYSTEM_PROCESSOR=i386 \ -DCMAKE_Fortran_COMPILER=/some/path/to/i686-linux-gnu-gfortran \ -DGFORTRAN_EXE=/some/path/to/i686-linux-gnu-gfortran \ -DCMAKE_Fortran_FLAGS=-m32
where i686-linux-gnu-gfortran can be implemented as:
#!/bin/sh exec gfortran -m32 "$@"