\section faq_simgrid I'm new to SimGrid. I have some questions. Where should I start?
You are at the right place... Having a look to these
-<a href="http://graal.ens-lyon.fr/~alegrand/articles/slides_g5k_simul.pdf">slides</a>
-(or to these
+<a href="http://www.loria.fr/~quinson/articles/simgrid-tutorial.pdf">the tutorial slides</a>
+(or to these <a href="http://graal.ens-lyon.fr/~alegrand/articles/slides_g5k_simul.pdf">old slides</a>,
+or to these
<a href="http://graal.ens-lyon.fr/~alegrand/articles/Simgrid-Introduction.pdf">"obsolete" slides</a>)
may give you some insights on what SimGrid can help you to do and what
are its limitations. Then you definitely should read the \ref
-MSG_examples. There is also a mailing list: <simgrid-user@lists.gforge.inria.fr>.
+MSG_examples. The \ref GRAS_tut can also help you.
+
+If you are stuck at any point and if this FAQ cannot help you, please drop us a
+mail to the user mailing list: <simgrid-user@lists.gforge.inria.fr>.
\subsection faq_interfaces What is the difference between MSG, SimDag, and GRAS? Do they serve the same purpose?
With SimDag, you express your code as a collection of interdependent
parallel tasks. So, in this model, applications can be seen as a DAG of
tasks. This is the interface of choice for people wanting to port old
-code designed for SimGrid v1 or v2 to the lastest framework.
+code designed for SimGrid v1 or v2 to the framework current version.
With both GRAS and MSG, your application is seen as a set of communicating
processes, exchanging data by the way of messages and performing computation
on their own.
The difference between both is that MSG is somehow easier to use, but GRAS
-is not limitated to the simulator. Once you're done writing your GRAS code,
+is not limited to the simulator. Once you're done writing your GRAS code,
you can run your code both in the simulator or on a real platform. For this,
there is two implementations of the GRAS interface, one for simulation, one
for real execution. So, you just have to relink your code to chose one of
read the \ref GRAS_tut. The first section constitutes an introduction
to the tool and presents the model we use. The second section
constitutes a complete step-by-step tutorial building a distributed
-application from the begining and exemplifying most of the GRAS
+application from the beginning and exemplifying most of the GRAS
features in the process. The last section groups some HOWTOS
highlighting a given feature of the framework in a more concise way.
./msg_test small_platform.xml small_deployment.xml 2>&1 | ../../tools/MSG_visualization/colorize.pl
\endverbatim
-We also have a more graphical output. Have a look at MSG_paje_output(). It
-generates an input to <a href="http://www-id.imag.fr/Logiciels/paje/">Paje</a>.
-<center>
-\htmlonly
- <a href="Paje_MSG_screenshot.jpg"><img src="Paje_MSG_screenshot_thn.jpg"></a>
-\endhtmlonly
-</center>
-
-Vizualization with Paje can be seen as a kind of postmortem
-analysis. However, as soon as you start playing with big simulations,
-you'll realize that processing such output is kind of tricky. There is
-so much generic informations that it is hard to find the information
-you are looking for.
-
-As a matter of fact, loging really depends on simulations (e.g. what
-kind of events is important...). That is why we do not propose a big
-dump of your whole simulation (it would slow everything down) but give
-you neat tools to structure you logs. Have a look at \ref XBT_log. In
-fact, rather than a post-mortem analysis, you may want to do it on the
-fly. The process you are running can do whatever you want. Have you
-thought about adding a global structure where you directly compute the
-informations that are really important rather than writing everything
-down and then processing huge files?
+We also have a more graphical output. Have a look at section \ref faq_tracing.
\subsection faq_C Argh! Do I really have to code in C?
instructions and still have some troubles, drop an e-mail to
<simgrid-user@lists.gforge.inria.fr>.
-\subsection faq_compiling Compiling SimGrid from an archive
+\subsection faq_compiling Compiling SimGrid from a stable archive
First of all, you need to download the latest version of SimGrid from
<a href="http://gforge.inria.fr/frs/?group_id=12">here</a>.
directory. Change your directory to
<tt>/home/joe/tmp/simgrid-3.0.1</tt> and type
-\verbatim./configure --prefix=$HOME
+\verbatim
+./configure --prefix=$HOME
make
make install
\endverbatim
-If at some point, something fails, check the section "\ref
-faq_trouble_compil". If it does not help, you can report this problem to the
+If at some point, something fails, check the section \ref faq_trouble_compil .
+If it does not help, you can report this problem to the
list but, please, avoid sending a laconic mail like "There is a problem. Is it
okay?". Send the config.log file which is automatically generated by
configure. Try to capture both the standard output and the error output of the
\verbatim export LD_LIBRARY_PATH=$HOME/lib/:$LD_LIBRARY_PATH
\endverbatim
+\subsection faq_compiling_java Java bindings don't get compiled
+
+The configure script detects automatically whether you have the
+softwares needed to use the Java bindings or not. At the end of the
+configure, you can see the configuration picked by the script, which
+should look similar to
+\verbatim Configuration of package simgrid' (version 3.3.4-svn) on
+little64 (=4):
+
+ Compiler: gcc (version: )
+
+ CFlags: -O3 -finline-functions -funroll-loops -fno-strict-aliasing -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wchar-subscripts -Wcomment -Wformat -Wwrite-strings -Wno-unused-function -Wno-unused-parameter -Wno-strict-aliasing -Wno-format-nonliteral -Werror -g3
+ CPPFlags:
+ LDFlags:
+
+ Context backend: ucontext
+ Compile Java: no
+
+ Maintainer mode: no
+ Supernovae mode: yes
+\endverbatim
+
+In this example, Java backends won't be compiled.
+
+On Debian-like systems (which includes ubuntu), you need the following
+packages: sun-java6-jdk libgcj10-dev. If you cannot find the
+libgcj10-dev, try another version, like libgcj9-dev (on Ubuntu before
+9.10) or libgcj11-dev (not released yet, but certainly one day).
+Please note that you need to activate the contrib and non-free
+repositories in Debian, and the universe ones in Ubuntu. Java comes at
+this price...
+
+\subsection faq_compiling_snapshoot SimGrid development snapshots
+
+We have very high standards on software quality, and we are reluctant releasing
+a stable release as long as there is still some known bug in the code base. In
+addition, we added quite an extensive test base, making sure that we correctly
+test the most important parts of the tool.
+
+As an unfortunate conclusion, there may be some time between the stable
+releases. If you want to benefit from the most recent features we introduced,
+but don't want to take the risk of an untested version from the SVN, then
+development snapshots are done for you.
+
+These are pre-releases of SimGrid that still fail some tests about features
+that almost nobody use, or on platforms not being in our core target (which is
+Linux, Mac, other Unixes and Windows, from the most important to the less
+one). That means that using this development releases should be safe for most
+users.
+
+These archives can be found on
+<a href="http://www.loria.fr/~quinson/simgrid.html">this web page</a>. Once you
+got the lastest archive, you can compile it just like any archive (see above).
\subsection faq_compiling_svn Compiling SimGrid from the SVN
-The project development takes place in the svn, where all changes are
-commited when they happen. Then every once in a while, we make sure that the
+The project development takes place in the SVN, where all changes are
+committed when they happen. Then every once in a while, we make sure that the
code quality meets our standard and release an archive from the code in the
SVN. We afterward go back to the development in the SVN. So, if you need a
recently added feature and can afford some little problem with the stability
(i.e. anything different from a recent linux distribution) may be
... uncertain. If you need to compile the SVN version on a machine where all these
dependencies are not met, the easiest is to do <tt>make dist</tt> in the SVN
-dir of another machine where all dependencies are met. It will create an
+directory of another machine where all dependencies are met. It will create an
archive you may deploy on other sites just as a regular stable release.
In summary, the following commands will checkout the SVN, regenerate the
them in a specific order with specific arguments. Most of the times, the
makefiles will automatically call the tools for you. When it's not possible
(such as the first time you checkout the SVN), use the ./bootstrap command
-to call them explicitely.
+to call them explicitly.
\subsection faq_setting_MSG Setting up your own MSG code
is not the better source of information. Instead, you should check the GRAS
tutorial in general, and the \ref GRAS_tut_tour_setup in particular.
-\subsection faq_crosscompile Cross-compiling a Windows DLL of SimGrid from linux
+\section faq_cmake CMAKE
-At the moment, we do not distribute Windows pre-compiled version of SimGrid
-because the support for this platform is still experimental. We know that
-some parts of the GRAS environment do not work, and we think that the others
-environments (MSG and SD) have good chances to work, but we didn't test
-ourselves. This section explains how we generate the SimGrid DLL so that you
-can build it for yourself. First of all, you need to have a version more
-recent than 3.1 (ie, a SVN version as time of writting).
+\subsection faq_intro Some generalitty
-In order to cross-compile the package to windows from linux, you need to
-install mingw32 (minimalist gnu win32). On Debian, you can do so by
-installing the packages mingw32 (compiler), mingw32-binutils (linker and
-so), mingw32-runtime.
+\subsubsection faq_intro1 What is Cmake?
-You can use the VPATH support of configure to compile at the same time for
-linux and windows without dupplicating the source nor cleaning the tree
-between each. Just run bootstrap (if you use the SVN) to run the autotools.
-Then, create a linux and a win directories. Then, type:
-\verbatim cd linux; ../configure --srcdir=.. <usual configure flags>; make; cd ..
-cd win; ../configure --srcdir=.. --host=i586-mingw32msvc <flags>; make; cd ..
+CMake is a family of tools designed to build, test and package software. CMake is used to control the software compilation process using simple platform and compiler independent configuration files. CMake generates native makefiles and workspaces that can be used in the compiler environment of your choice. For more information see official web site <a href="http://www.cmake.org/">here</a>.
+
+\subsubsection faq_intro2 Why cmake?
+
+CMake permits to developers to compil projects on different plateform. Then many tools are embedded like ctest for making test, a link to cdash for vizualise results but also test coverage and bug reports.
+
+\subsubsection faq_intro3 What cmake need?
+
+CMake needs some prerequists like :
+ \li make
+ \li c, c++ and java compiler regards to developers
+ \li ccmake for graphical used of CMake
+ \li cmake <a href="http://www.cmake.org/cmake/resources/software.html">(download page)</a>
+
+\subsubsection faq_intro4 Cmake vs Autotools...
+
+TODO
+
+\subsection faq_cmakeoption Cmake options
+
+\subsubsection faq_cmakeoption1 Liste of options
+
+\verbatim
+"cmake -D[name]=[value] ... ./"
+
+[name] enable_gtnets [value] ON/OFF or TRUE/FALSE or 1/0
+ enable_java ON/OFF or TRUE/FALSE or 1/0
+ enable_lua ON/OFF or TRUE/FALSE or 1/0
+ enable_ruby ON/OFF or TRUE/FALSE or 1/0
+ enable_compile_optimizations ON/OFF or TRUE/FALSE or 1/0
+ enable_compile_warnings ON/OFF or TRUE/FALSE or 1/0
+ enable_maintainer_mode ON/OFF or TRUE/FALSE or 1/0
+ enable_supernovae ON/OFF or TRUE/FALSE or 1/0
+ enable_tracing ON/OFF or TRUE/FALSE or 1/0
+ enable_coverage ON/OFF or TRUE/FALSE or 1/0
+ enable_memcheck ON/OFF or TRUE/FALSE or 1/0
+ enable_print_message ON/OFF or TRUE/FALSE or 1/0
+
+ gtnets_path <path_to_gtnets_directory>
+ prefix <path_to_install_directory>
+ BIBTEX2HTML <path_to_bibtex2html>
+ with_context auto/ucontext/pthread/window
\endverbatim
-The trick to VPATH builds is to call configure from another directory,
-passing it an extra --srcdir argument to tell it where all the sources are.
-It will understand you want to use VPATH. Then, the trick to cross-compile
-is simply to add a --host argument specifying the target you want to build
-for. The i586-mingw32msvc string is what you have to pass to use the mingw32
-environment as distributed in Debian.
+
+\subsubsection faq_cmakeoption2 Options explaination
-After that, you can run all make targets from both directories, and test
-easily that what you change for one arch does not break the other one.
+ \li enable_gtnets : set to true implie that user wants to use gtnets.
-It is possible that this VPATH build thing breaks from time to time in the
-SVN since it's quite fragile, but it's granted to work in any released
-version. If you experience problems, drop us a mail.
+ \li enable_java : set to true implie that user wants to add java langage into simgrid compilation.
-Another possible source of issue is that at the moment, building the
-examples request to use the gras_stub_generator tool, which is a compiled
-program, not a script. In cross-compilation, you need to cross-execute with
-wine for example, which is not really pleasant. We are working on this, but
-in the meanwhile, simply don't build the examples in cross-compilation
-(<tt>cd src</tt> before running make).
-
-Program (cross-)compiled with mingw32 do request an extra DLL at run-time to be
-usable. For example, if you want to test your build with wine, you should do
-the following to put this library where wine looks for DLLs.
-\verbatim
-cp /usr/share/doc/mingw32-runtime/mingwm10.dll.gz ~/.wine/c/windows/system/
-gunzip ~/.wine/c/windows/system/mingwm10.dll.gz
+ \li enable_lua : set to true implie that user wants to add lua langage into simgrid compilation.
+
+ \li enable_ruby : set to true implie that user wants to add ruby langage into simgrid compilation.
+
+ \li enable_compile_optimizations : add flags "-O3 -finline-functions -funroll-loops -fno-strict-aliasing"
+
+ \li enable_compile_warnings : add flags "-Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wchar-subscripts -Wcomment -Wformat -Wwrite-strings -Wno-unused-function -Wno-unused-parameter -Wno-strict-aliasing -Wno-format-nonliteral -Werror"
+
+ \li enable_maintainer_mode : set to true it remakes some files.
+\verbatim
+include/surf/simgrid_dtd.h
+include/xbt/graphxml.h
+
+src/cunit_unit.c
+src/ex_unit.c
+src/dynar_unit.c
+src/dict_unit.c
+src/set_unit.c
+src/swag_unit.c
+src/xbt_str_unit.c
+src/xbt_strbuff_unit.c
+src/xbt_sha_unit.c
+src/config_unit.c
+src/xbt_synchro_unit.c
+src/simgrid_units_main.c
+
+src/simdag/dax_dtd.c
+src/simdag/dax_dtd.h
+src/simdag/dax_dtd.l
+
+src/surf/simgrid_dtd.c
+src/surf/simgrid_dtd.l
+
+src/xbt/graphxml.c
+src/xbt/graphxml.l
+
+src/gras/DataDesc/ddt_parse.yy.c
+\endverbatim
+ \li enable_supernovae : set to true make one file for each lib and compile with those generated files.
+\verbatim
+/src/supernovae_sg.c
+/src/supernovae_gras.c
+/src/supernovae_smpi.c
\endverbatim
-The DLL is builded in src/.libs, and installed in the <i>prefix</i>/bin directory
-when you run make install.
+ \li enable_tracing : To enable the generation of simulation traces for visualization
-If you want to use it in a native project on windows, you need to use
-simgrid.dll and mingwm10.dll. For each DLL, you need to build .def file
-under linux (listing the defined symbols), and convert it into a .lib file
-under windows (specifying this in a way that windows compilers like). To
-generate the def files, run (under linux):
-\verbatim echo "LIBRARY libsimgrid-0.dll" > simgrid.def
-echo EXPORTS >> simgrid.def
-nm libsimgrid-0.dll | grep ' T _' | sed 's/.* T _//' >> simgrid.def
-nm libsimgrid-0.dll | grep ' D _' | sed 's/.* D _//' | sed 's/$/ DATA/' >> simgrid.def
+ \li enable_coverage : When set to true this option enable code coverage by setting -fprofile-arcs -ftest-coverage flags.
-echo "LIBRARY mingwm10.dll" > mingwm10.def
-echo EXPORTS >> mingwm10.def
-nm mingwm10.dll | grep ' T _' | sed 's/.* T _//' >> mingwm10.def
-nm mingwm10.dll | grep ' D _' | sed 's/.* D _//' | sed 's/$/ DATA/' >> mingwm10.def
+ \li enable_memcheck : When set to true this option enable tests for memcheck.
+
+ \li enable_print_message : This option when enable permits to see variables from gras_config.h
+
+ \li gtnets_path : Path to gtnets install directory (ex /usr)
+
+ \li prefix : Path where are installed lib/ doc/ and include/ directories (ex /usr/local)
+
+ \li BIBTEX2HTML : Path where is installed bibtex2html.
+
+ \li with context : specify which context the user wants to use.
+
+\subsubsection faq_cmakeoption3 Initialisation
+
+Those options are initialized the first time you launch \"cmake ./\" whithout specified option.
+
+\verbatim
+enable_gtnets on
+enable_lua on
+enable_ruby on
+enable_java off
+enable_compile_optimizations off
+enable_compile_warnings off
+enable_maintainer_mode off
+enable_supernovae off
+enable_tracing off
+enable_coverage off
+enable_memcheck off
+enable_print_message off
+
+gtnets_path null
+prefix null
+BIBTEX2HTML null
+with_context auto
\endverbatim
-To create the import .lib files, use the <tt>lib</tt> windows tool (from
-MSVC) the following way to produce simgrid.lib and mingwm10.lib
-\verbatim lib /def:simgrid.def
-lib /def:mingwm10.def
+\subsubsection faq_cmakeoption4 Option's cache and how to reset?
+
+When options have been set they are keep into a cache file named \"CMakeCache.txt\". So if you want
+reset values you just delete this file located to the project directory.
+
+\subsection faq_cmakecompilation Cmake compilation
+
+\subsubsection faq_cmakecompilation1 With command line.
+
+\verbatim
+cmake -D[name]=[value] ... ./
+make
\endverbatim
-If you happen to use Borland C Builder, the right command line is the
-following (note that you don't need any file.def to get this working).
-\verbatim implib simgrid.lib libsimgrid-0.dll
-implib mingwm10.lib mingwm10.dll
+\subsubsection faq_cmakecompilation2 With ccmake tool.
+
+\verbatim
+"ccmake ./"
\endverbatim
+Then follow instructions.
-Then, set the following parameters in Visual C++ 2005:
-Linker -> Input -> Additional dependencies = simgrid.lib mingwm10.lib
+\subsubsection faq_cmakecompilation3 Resume of command line
-Just in case you wonder how to generate a DLL from libtool in another
-project, we added -no-undefined to any lib*_la_LDFLAGS variables so that
-libtool accepts to generate a dynamic library under windows. Then, to make
-it true, we pass any dependencies (such as -lws2 under windows or -lpthread
-on need) on the linking line. Passing such deps is a good idea anyway so
-that they get noted in the library itself, avoiding the users to know about
-our dependencies and put them manually on their compilation line. Then we
-added the AC_LIBTOOL_WIN32_DLL macro just before AC_PROG_LIBTOOL in the
-configure.ac. It means that we exported any symbols which need to be.
-Nowadays, functions get automatically exported, so we don't need to load our
-header files with tons of __declspec(dllexport) cruft. We only need to do so
-for data, but there is no public data in SimGrid so we are good.
+ \li CMake
+\verbatim
+cmake ./ configure the project
+make build all targets
+make VERBOSE=1 build all targets and print build command lines
+make test test all targets and summarize
+make dist make the distrib
+make distcheck check the dist (make + make dist + make test)
+make install-simgrid install the project (doc/ lib/ include/)
+make uninstall uninstall the project (doc/ lib/ include/)
+make clean clean all targets
+make java-clean clean files created by java option
+make doc-clean clean files created for making doc
+make supernovae-clean clean supernovae files
+make maintainer-clean clean maintainer files
+make all-clean execute the 5 upper clean command
+make html Create simgrid documentation
+make maintainer-clean Remove all files generated by mainainer mode
+\endverbatim
+
+When the project have been succesfully compiling and build you can make tests.
+
+ \li CTest
+\verbatim
+ctest launch only tests
+ctest -D Continuous
+ctest -D Continuous(Start|Update|Configure|Build)
+ctest -D Continuous(Test|Coverage|MemCheck|Submit)
+ctest -D Experimental
+ctest -D Experimental(Start|Update|Configure|Build)
+ctest -D Experimental(Test|Coverage|MemCheck|Submit)
+ctest -D Nightly
+ctest -D Nightly(Start|Update|Configure|Build)
+ctest -D Nightly(Test|Coverage|MemCheck|Submit)
+ctest -D NightlyMemoryCheck
+\endverbatim
+
+If you want to test before make a commit you can simply make "ctest -D Experimental" and then you can visualize results submitted into Cdash. <a href="http://cdash.inria.fr/CDash/index.php?project=Simgrid">(Go to Cdash site)</a>.
+
+\subsubsection faq_cmakecompilation4 Examples for different mode.
+
+\li Mode maintainer
+
+cmake -Denable_maintainer_mode=on ./
+\verbatim GTnetS doesn't works : set -Ddisable_gtnets=on
+with_context auto change to ucontext
+(skaddr)
+(sksize)
+Make : src/simgrid.jar with : /usr/bin/javac
+Make examples/java with : /usr/bin/javac
+
+Configuration of package `simgrid' (revision 7228M) on arch (=4):
+ BUILDNAME : UCONTEXT
+ SITE : Linux_Ubuntu 9.10_x86_64
+
+ Compiler: c++ : /usr/bin/c++
+ version: c++ (Ubuntu 4.4.1-4ubuntu9) 4.4.1
+ c : /usr/bin/gcc
+ version: gcc (Ubuntu 4.4.1-4ubuntu9) 4.4.1
+
+ CFlags: -g3
+ CPPFlags:
+ LDFlags:
+
+ Context backend: ucontext
+ Compile Gtnets: 0
+ path:
+ Compile Java: 1
+ Compile Lua: 1
+ Compile Ruby: 0
+
+ Maintainer mode: on
+ Supernovae mode: off
+
+ Simgrid dependencies: dl -llua5.1
+ Gras dependencies: pthread
+ Ruby dependencies:
+ Smpi dependencies:
+
+ USER_PREFIX: /usr/local
+ INSTALL_PREFIX: /usr/local
+
+-- Configuring done
+-- Generating done
+-- Build files have been written to: /home/navarrop/Bureau/simgrid-trunk
+\endverbatim
+
+\li Mode supernovae
+
+cmake -Dsupernovae=on ./
+\verbatim GTnetS doesn't works : set -Ddisable_gtnets=on
+with_context auto change to ucontext
+(skaddr)
+(sksize)
+Make : src/simgrid.jar with : /usr/bin/javac
+Make examples/java with : /usr/bin/javac
+
+Configuration of package `simgrid' (revision 7228M) on arch (=4):
+ BUILDNAME : SUPERNOVAE
+ SITE : Linux_Ubuntu 9.10_x86_64
+
+ Compiler: c++ : /usr/bin/c++
+ version: c++ (Ubuntu 4.4.1-4ubuntu9) 4.4.1
+ c : /usr/bin/gcc
+ version: gcc (Ubuntu 4.4.1-4ubuntu9) 4.4.1
+
+ CFlags: -O3 -finline-functions -funroll-loops -fno-strict-aliasing -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wchar-subscripts -Wcomment -Wformat -Wwrite-strings -Wno-unused-function -Wno-unused-parameter -Wno-strict-aliasing -Wno-format-nonliteral -Werror -g3
+ CPPFlags:
+ LDFlags:
+
+ Context backend: ucontext
+ Compile Gtnets: 0
+ path:
+ Compile Java: 1
+ Compile Lua: 1
+ Compile Ruby: 0
+
+ Maintainer mode: off
+ Supernovae mode: on
+
+ Simgrid dependencies: dl -llua5.1
+ Gras dependencies: pthread
+ Ruby dependencies:
+ Smpi dependencies:
+
+ USER_PREFIX: /usr/local
+ INSTALL_PREFIX: /usr/local
+
+-- Configuring done
+-- Generating done
+-- Build files have been written to: /home/navarrop/Bureau/simgrid-trunk
+\endverbatim
+
+\li Mode GTnetS
+
+cmake -Dgtnets_path=/home/navarrop/Bureau/usr/ ./
+\verbatim with_context auto change to ucontext
+(skaddr)
+(sksize)
+Make : src/simgrid.jar with : /usr/bin/javac
+Make examples/java with : /usr/bin/javac
+
+Configuration of package `simgrid' (revision 7228M) on arch (=4):
+ BUILDNAME : GTNETS
+ SITE : Linux_Ubuntu 9.10_x86_64
+
+ Compiler: c++ : /usr/bin/c++
+ version: c++ (Ubuntu 4.4.1-4ubuntu9) 4.4.1
+ c : /usr/bin/gcc
+ version: gcc (Ubuntu 4.4.1-4ubuntu9) 4.4.1
+
+ CFlags: -L/home/navarrop/Bureau/usr/lib -I/home/navarrop/Bureau/usr/include/gtnets -g3
+ CPPFlags: -L/home/navarrop/Bureau/usr/lib -I/home/navarrop/Bureau/usr/include/gtnets
+ LDFlags:
+
+ Context backend: ucontext
+ Compile Gtnets: 1
+ path: /home/navarrop/Bureau/usr
+ Compile Java: 1
+ Compile Lua: 1
+ Compile Ruby: 0
+
+ Maintainer mode: off
+ Supernovae mode: off
+
+ Simgrid dependencies: dl -llua5.1 -lgtnets
+ Gras dependencies: pthread
+ Ruby dependencies:
+ Smpi dependencies:
+
+ USER_PREFIX: /usr/local
+ INSTALL_PREFIX: /usr/local
+
+INFO -->> Take care to have export LD_LIBRARY_PATH before run make command for make examples with gtnets
+copy and paste : export LD_LIBRARY_PATH=/home/navarrop/Bureau/usr/lib/:$LD_LIBRARY_PATH
+
+
+-- Configuring done
+-- Generating done
+-- Build files have been written to: /home/navarrop/Bureau/simgrid-trunk
+\endverbatim
+
+\subsection faq_cmakeinstall How to install with cmake?
+
+\subsubsection faq_cmakeinstall1 From svn.
+
+\verbatim
+cmake -Denable_maintainer_mode=on -Dprefix=/home/navarrop/Bureau/install_simgrid ./
+make
+make install-simgrid
+\endverbatim
+
+\subsubsection faq_cmakeinstall2 From a distrib
+
+\verbatim
+cmake -Dprefix=/home/navarrop/Bureau/install_simgrid ./
+make
+make install-simgrid
+\endverbatim
+
+\subsection faq_screenshot Screenshot
+
+\verbatim
+navarrop@caraja:~$ cd Bureau/simgrid-trunk/
+navarrop@caraja:~/Bureau/simgrid-trunk$ cmake ./
+
+GTnetS doesn't works : set -Ddisable_gtnets=on <-|some warnings are printed
+with_context auto change to ucontext <-|
+(skaddr) <--info (needed)
+(sksize) <--info (needed)
+Make : src/simgrid.jar with : /usr/bin/javac <--info (if java)
+Make examples/java with : /usr/bin/javac <--info (if java)
+
+Configuration of package `simgrid' (revision 7209M) on arch (=4):
+ BUILDNAME : UCONTEXT <-- name of the compilation regarding to cdash
+ SITE : Linux_Ubuntu 9.10_x86_64 <-- distribution of the local machine regarding to cdash
+
+ Compiler: c++ : /usr/bin/c++
+ version: c++ (Ubuntu 4.4.1-4ubuntu9) 4.4.1
+ c : /usr/bin/gcc
+ version: gcc (Ubuntu 4.4.1-4ubuntu9) 4.4.1
+
+ CFlags: -g3
+ CPPFlags:
+ LDFlags:
+
+ Context backend: ucontext
+ Compile Gtnets: 0
+ path:
+ Compile Java: 1
+ Compile Lua: 1
+ Compile Ruby: 0
+
+ Maintainer mode: OFF
+ Supernovae mode: OFF
+
+ Simgrid dependencies: -ldl -llua5.1
+ Gras dependencies: pthread
+ Ruby dependencies:
+ Smpi dependencies:
+
+ USER_PREFIX: /usr/local
+ INSTALL_PREFIX: /usr/local
+
+-- Configuring done
+-- Generating done
+-- Build files have been written to: /home/navarrop/Bureau/simgrid-trunk
+\endverbatim
+Here all options are checked and printed. If it doesn't match with your configuration
+it is probably due to a wrong configuration.
+
+\subsection faq_cmakehowto How to modified sources files for developers
+
+\subsubsection faq_cmakehowto1 Add an executable or examples.
+
+If you want make an executable you have to create a CMakeList.txt to the src directory.
+You must specified where to create the executable, source list, dependencies and the name of the binary.
+
+\verbatim
+cmake_minimum_required(VERSION 2.6)
+
+set(EXECUTABLE_OUTPUT_PATH "./")
+set(LIBRARY_OUTPUT_PATH "${PROJECT_DIRECTORY}/lib")
+
+add_executable(get_sender get_sender.c) #add_executable(<name_of_target> <src list>)
+
+### Add definitions for compile
+target_link_libraries(get_sender simgrid m pthread -fprofile-arcs) #target_link_libraries(<name_of_targe> <dependencies>)
+\endverbatim
+
+Then you have to modified <project/directory>/buildtools/Cmake/src/CMakeMakeExeLib.txt and add
+this line :
+\verbatim
+add_subdirectory(${PROJECT_DIRECTORY}/<path_where_is_CMakeList.txt>)
+\endverbatim
+
+\subsubsection faq_cmakehowto2 Delete/add sources to lib.
+
+If you want modified, add or delete source files from a library you have to edit <project/directory>/buildtools/Cmake/src/CMakeDefinePackages.txt
+
+\verbatim
+set(JMSG_JAVA_SRC
+ ${PROJECT_DIRECTORY}/src/java/simgrid/msg/MsgException.java
+ ${PROJECT_DIRECTORY}/src/java/simgrid/msg/JniException.java
+ ${PROJECT_DIRECTORY}/src/java/simgrid/msg/NativeException.java
+ ${PROJECT_DIRECTORY}/src/java/simgrid/msg/HostNotFoundException.java
+ ${PROJECT_DIRECTORY}/src/java/simgrid/msg/ProcessNotFoundException.java
+ ${PROJECT_DIRECTORY}/src/java/simgrid/msg/Msg.java
+ ${PROJECT_DIRECTORY}/src/java/simgrid/msg/Process.java
+ ${PROJECT_DIRECTORY}/src/java/simgrid/msg/Host.java
+ ${PROJECT_DIRECTORY}/src/java/simgrid/msg/Task.java
+ ${PROJECT_DIRECTORY}/src/java/simgrid/msg/MsgNative.java
+ ${PROJECT_DIRECTORY}/src/java/simgrid/msg/ApplicationHandler.java
+ ${PROJECT_DIRECTORY}/src/java/simgrid/msg/Sem.java
+)
+\endverbatim
+
+\subsubsection faq_cmakehowto3 Add test
+
+If you want modified, add or delete tests you have to edit <project/directory>/buildtools/Cmake/src/CMakeTest.txt
+with this function : ADD_TEST(<name> <bin> <ARGS>)
+
+\verbatim
+add_test(test-simdag-1 ${PROJECT_DIRECTORY}/testsuite/simdag/sd_test --cfg=path:${PROJECT_DIRECTORY}/testsuite/simdag small_platform_variable.xml)
+\endverbatim
+
+\subsection faq_cmakeExplain Explaination of sources files for cmake
+
+\li CMakeLists.txt
+
+Those files are the "main parts". One located at the project directory call all the cmake sources files. The others
+are little projects called by the first for make examples.
+
+\li CMakeCompleteInFiles.txt
+
+Complete all .in files and define Variables for h files
+
+\li CMakeDocs.txt
+
+This file make the html documentation.
+
+\li CMakeMakeExeLib.txt
+
+Here are callled all "CMakeLists.txt" for make executables and libraries.
+
+\li CMakePrintArgs.txt
+
+This file is called at the end of the build for summarize environment variables.
+
+\li CMakeDefinePackages.txt
+
+Here is defined sources packages for compiling libs.
+
+\li CMakeFlags.txt
+
+Defined flags which are used for compiling sources.
+
+\li CMakeSupernovae.txt
+
+Here are made files for the supernovae mode.
+
+\li CMakeDistrib.txt
+
+Here is defined packages for install simgrid and make a distribution.
+
+\li CMakeMaintainerMode.txt
+
+Part where are generated source files for maintainer mode.
+
+\li CMakeOption.txt
+
+Here are defined options and initialized values.
+
+\li CMakeTest.txt
+
+All tests are listed.
+
+\li CTestConfig.cmake
+
+Properties which link tests with dashboard.
+
+\subsection faq_cmakeList List of files added for cmake
+
+Here is a list of files involved into cmake build (relative to project directory path) :
+\verbatim
+
+Cmake sources:
+ ./doc/CMakeLists.txt
+ ./buildtools/Cmake/src/CMakeCompleteInFiles.txt
+ ./buildtools/Cmake/src/CMakeDocs.txt
+ ./buildtools/Cmake/src/CMakeMakeExeLib.txt
+ ./buildtools/Cmake/src/CMakePrintArgs.txt
+ ./buildtools/Cmake/src/CMakeDefinePackages.txt
+ ./buildtools/Cmake/src/CMakeFlags.txt
+ ./buildtools/Cmake/src/CMakeSupernovae.txt
+ ./buildtools/Cmake/src/CMakeDistrib.txt
+ ./buildtools/Cmake/src/CMakeMaintainerMode.txt
+ ./buildtools/Cmake/src/CMakeOption.txt
+ ./buildtools/Cmake/src/CMakeTest.txt
+ ./buildtools/Cmake/src/CTestConfig.cmake
+
+Test files for define properties :
+ ./buildtools/Cmake/prog_test/prog_GRAS_ARCH.c
+ ./buildtools/Cmake/prog_test/prog_max_size.c
+ ./buildtools/Cmake/prog_test/prog_sem_init.c
+ ./buildtools/Cmake/prog_test/prog_stackgrowth.c
+ ./buildtools/Cmake/prog_test/prog_vsnprintf.c
+ ./buildtools/Cmake/prog_test/prog_AC_CHECK_MCSC.c
+ ./buildtools/Cmake/prog_test/prog_GRAS_CHECK_STRUCT_COMPACTION.c
+ ./buildtools/Cmake/prog_test/prog_mutex_timedlock.c
+ ./buildtools/Cmake/prog_test/prog_sem_timedwait.c
+ ./buildtools/Cmake/prog_test/prog_stacksetup.c
+ ./buildtools/Cmake/prog_test/prog_getline.c
+ ./buildtools/Cmake/prog_test/prog_gtnets.cpp
+ ./buildtools/Cmake/prog_test/prog_printf_null.c
+ ./buildtools/Cmake/prog_test/prog_snprintf.c
+ ./buildtools/Cmake/prog_test/prog_va_copy.c
+
+CMakeLists for each binaries or examples:
+ ./CMakeLists.txt
+ ./src/CMakeLists.txt
+ ./teshsuite/gras/empty_main/CMakeLists.txt
+ ./teshsuite/gras/small_sleep/CMakeLists.txt
+ ./teshsuite/gras/datadesc/CMakeLists.txt
+ ./teshsuite/gras/msg_handle/CMakeLists.txt
+ ./teshsuite/simdag/CMakeLists.txt
+ ./teshsuite/simdag/partask/CMakeLists.txt
+ ./teshsuite/simdag/platforms/CMakeLists.txt
+ ./teshsuite/simdag/network/CMakeLists.txt
+ ./teshsuite/simdag/network/mxn/CMakeLists.txt
+ ./teshsuite/simdag/network/p2p/CMakeLists.txt
+ ./teshsuite/xbt/CMakeLists.txt
+ ./teshsuite/msg/CMakeLists.txt
+ ./tools/gras/CMakeLists.txt
+ ./tools/tesh/CMakeLists.txt
+ ./testsuite/simdag/CMakeLists.txt
+ ./testsuite/xbt/CMakeLists.txt
+ ./testsuite/surf/CMakeLists.txt
+ ./examples/gras/properties/CMakeLists.txt
+ ./examples/gras/ping/CMakeLists.txt
+ ./examples/gras/pmm/CMakeLists.txt
+ ./examples/gras/mmrpc/CMakeLists.txt
+ ./examples/gras/synchro/CMakeLists.txt
+ ./examples/gras/timer/CMakeLists.txt
+ ./examples/gras/mutual_exclusion/simple_token/CMakeLists.txt
+ ./examples/gras/spawn/CMakeLists.txt
+ ./examples/gras/chrono/CMakeLists.txt
+ ./examples/gras/rpc/CMakeLists.txt
+ ./examples/gras/all2all/CMakeLists.txt
+ ./examples/simdag/properties/CMakeLists.txt
+ ./examples/simdag/CMakeLists.txt
+ ./examples/simdag/metaxml/CMakeLists.txt
+ ./examples/simdag/dax/CMakeLists.txt
+ ./examples/smpi/CMakeLists.txt
+ ./examples/amok/bandwidth/CMakeLists.txt
+ ./examples/amok/saturate/CMakeLists.txt
+ ./examples/msg/priority/CMakeLists.txt
+ ./examples/msg/properties/CMakeLists.txt
+ ./examples/msg/migration/CMakeLists.txt
+ ./examples/msg/gtnets/CMakeLists.txt
+ ./examples/msg/parallel_task/CMakeLists.txt
+ ./examples/msg/trace/CMakeLists.txt
+ ./examples/msg/suspend/CMakeLists.txt
+ ./examples/msg/masterslave/CMakeLists.txt
+ ./examples/msg/actions/CMakeLists.txt
+ ./examples/msg/sendrecv/CMakeLists.txt
+\endverbatim
\section faq_howto Feature related questions
Here is the deal. The whole SimGrid project (MSG, SURF, GRAS, ...) is
meant to be kept as simple and generic as possible. We cannot add
-functions for everybody's need when these functions can easily be
+functions for everybody's needs when these functions can easily be
built from the ones already in the API. Most of the time, it is
possible and when it was not possible we always have upgraded the API
accordingly. When somebody asks us a question like "How to do that?
We know. We should add some more examples, but not really some more
complex ones... We should add some examples that illustrate some other
-functionalities (like how to simply encode asynchronous
+functionalists (like how to simply encode asynchronous
communications, RPC, process migrations, thread synchronization, ...)
and we will do it when we will have a little bit more time. We have
tried to document the examples so that they are understandable. Tell
MSG_task_get_remaining_computation(), MSG_task_get_data_size(),
and MSG_task_get_data().
-You could use a dictionnary (#xbt_dict_t) of dynars (#xbt_dynar_t). If
+You could use a dictionary (#xbt_dict_t) of dynars (#xbt_dynar_t). If
you still don't see how to do it, please come back to us...
\subsubsection faq_MIA_asynchronous I want to do asynchronous communications in MSG
\subsubsection faq_SG_comm Implementing communication delays between tasks.
-A classic question of SimDag newcommers is about how to express a
+A classic question of SimDag newcomers is about how to express a
communication delay between tasks. The thing is that in SimDag, both
computation and communication are seen as tasks. So, if you want to
model a data dependency between two DAG tasks t1 and t2, you have to
generic way is thus very hard). However some people have implemented
their own batch schedulers. Vincent Garonne wrote one during his PhD
and put his code in the contrib directory of our SVN so that other can
-keep working on it. You may find inspinring ideas in it.
+keep working on it. You may find inspiring ideas in it.
\subsubsection faq_MIA_checkpointing I need a checkpointing thing
There is several little examples in the archive, in the examples/msg
directory. From time to time, we are asked for other files, but we
-don't have any at hand right now.
+don't have much at hand right now.
-We do have a description of the Grid'5000 platform, but because of
-some flaws in the current formalism, this file is actually 500Mb,
-which is ways too big to be used in the parser. We have an internship
-currently working on xml syntax improvements which will allow to
-reduce the size of this file and release it.
-
-Once it's done, we plan to model manually other existing platforms the
-same way we did for G5K and also release those files in some sort of
-SimGrid platform catalog project.
+You should refer to the Platform Description Archive
+(http://pda.gforge.inria.fr) project to see the other platform file we
+have available, as well as the Simulacrum simulator, meant to generate
+SimGrid platforms using all classical generation algorithms.
\subsubsection faq_platform_alnem How can I automatically map an existing platform?
</route>
\endverbatim
-Althrough it is perfectly valid, it does not mean that data traveling
+Although it is perfectly valid, it does not mean that data traveling
from A to C can either go directly (using link 3) or through B (using
links 1 and 2). It simply means that the routing on the graph is not
trivial, and that data do not following the shortest path in number of
the provided ones.
You are also free to declare platform where the routing is not
-symetric. For example, add the following to the previous file:
+symmetric. For example, add the following to the previous file:
\verbatim
<route src="C" dst="A">
\subsubsection faq_flexml_bypassing Bypassing the XML parser with your own C functions
-So you want to bypass the XML files parser, uh? Maybe doin some parameter
+So you want to bypass the XML files parser, uh? Maybe doing some parameter
sweep experiments on your simulations or so? This is possible, and
it's not even really difficult (well. Such a brutal idea could be
harder to implement). Here is how it goes.
functions. An example of this trick is distributed in the file
examples/msg/masterslave/masterslave_bypass.c
+\subsection faq_simgrid_configuration Changing SimGrid's behavior
+
+A number of options can be given at runtime to change the default
+SimGrid behavior. In particular, you can change the default cpu and
+network models...
+
+\subsubsection faq_simgrid_configuration_gtnets Using GTNetS
+
+It is possible to use a packet-level network simulator
+instead of the default flow-based simulation. You may want to use such
+an approach if you have doubts about the validity of the default model
+or if you want to perform some validation experiments. At the moment,
+we support the GTNetS simulator (it is still rather experimental
+though, so leave us a message if you play with it).
+
+
+<i>
+To enable GTNetS model inside SimGrid it is needed to patch the GTNetS simulator source code
+and build/install it from scratch
+</i>
+
+ - <b>Download and enter the recent downloaded GTNetS directory</b>
+
+ \verbatim
+ svn checkout svn://scm.gforge.inria.fr/svn/simgrid/contrib/trunk/GTNetS/
+ cd GTNetS
+ \endverbatim
+
+
+ - <b>Use the following commands to unzip and patch GTNetS package to work within SimGrid.</b>
+
+ \verbatim
+ unzip gtnets-current.zip
+ tar zxvf gtnets-current-patch.tgz
+ cd gtnets-current
+ cat ../00*.patch | patch -p1
+ \endverbatim
+
+ - <b>OPTIONALLY</b> you can use a patch for itanium 64bit processor family.
+
+ \verbatim
+ cat ../AMD64-FATAL-Removed-DUL_SIZE_DIFF-Added-fPIC-compillin.patch | patch -p1
+ \endverbatim
+
+ - <b>Compile GTNetS</b>
+
+ Due to portability issues it is possible that GTNetS does not compile in your architecture. The patches furnished in SimGrid SVN repository are intended for use in Linux architecture only. Unfortunately, we do not have the time, the money, neither the manpower to guarantee GTNetS portability. We advice you to use one of GTNetS communication channel to get more help in compiling GTNetS.
+
+
+ \verbatim
+ ln -sf Makefile.linux Makefile
+ make depend
+ make debug
+ \endverbatim
+
+
+ - <b>NOTE</b> A lot of warnings are expected but the application should compile
+ just fine. If the makefile insists in compiling some QT libraries
+ please try a make clean before asking for help.
+
+
+ - <b>To compile optimized version</b>
+
+ \verbatim
+ make opt
+ \endverbatim
+
+
+ - <b>Installing GTNetS</b>
+
+ It is important to put the full path of your libgtsim-xxxx.so file when creating the symbolic link. Replace < userhome > by some path you have write access to.
+
+ \verbatim
+ ln -sf /<absolute_path>/gtnets_current/libgtsim-debug.so /<userhome>/usr/lib/libgtnets.so
+ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/<userhome>/usr/lib/libgtnets.so
+ mkdir /<userhome>/usr/include/gtnets
+ cp -fr SRC/*.h /<userhome>/usr/include/gtnets
+ \endverbatim
+
+
+ - <b>Enable GTNetS support in SimGrid</b>
+
+ \verbatim
+ ./configure --with-gtnets=/<userhome>/usr
+ \endverbatim
+
+ - <b>Once you have followed all the instructions for compiling and
+ installing successfully you can activate this feature at
+ runntime with the following options:</b>
+
+ \verbatim
+ cd simgrid/example/msg/
+ make
+ make check
+ \endverbatim
+
+
+ - <b>Or try the GTNetS model dogbone example with</b>
+
+ \verbatim
+ gtnets/gtnets gtnets/onelink-p.xml gtnets/onelink-d.xml --cfg=network_model:GTNets
+ \endverbatim
+
+
+ A long version of this <a href="http://gforge.inria.fr/docman/view.php/12/6283/GTNetS HowTo.html">HowTo</a> it is available
+
+
+ More about GTNetS simulator at <a href="http://www.ece.gatech.edu/research/labs/MANIACS/GTNetS/index.html">GTNetS Website</a>
+
+
+ - <b>DISCLAIMER</b>
+ The patches provided by us worked successfully with GTNetS found
+ <a href="http://www.ece.gatech.edu/research/labs/MANIACS/GTNetS/software/gtnets-current.zip">here</a>,
+ dated from 12th June 2008. Due to the discontinuing development of
+ GTNetS it is impossible to precise a version number. We STRONGLY recommend you
+ to download and install the GTNetS version found in SimGrid repository as explained above.
+
+
+
+
+\subsubsection faq_simgrid_configuration_alternate_network Using alternative flow models
+
+The default simgrid network model uses a max-min based approach as
+explained in the research report
+<a href="ftp://ftp.ens-lyon.fr/pub/LIP/Rapports/RR/RR2002/RR2002-40.ps.gz">A Network Model for Simulation of Grid Application</a>.
+Other models have been proposed and implemented since then (see for example
+<a href="http://mescal.imag.fr/membres/arnaud.legrand/articles/simutools09.pdf">Accuracy Study and Improvement of Network Simulation in the SimGrid Framework</a>)
+and can be activated at runtime. For example:
+\verbatim
+./mycode platform.xml deployment.xml --cfg=workstation_model:compound --cfg=network_model:LV08 -cfg=cpu_model:Cas01
+\endverbatim
+
+Possible models for the network are currently "Constant", "CM02",
+"LegrandVelho", "GTNets", Reno", "Reno2", "Vegas". Others will
+probably be added in the future and many of the previous ones are
+experimental and are likely to disappear without notice...
+
+\subsection faq_tracing Tracing Simulations for Visualization
+
+The trace visualization is widely used to observe and understand the behavior
+of parallel applications and distributed algorithms. Usually, this is done in a
+two-step fashion: the user instruments the application and the traces are
+analyzed after the end of the execution. The visualization itself can highlights
+unexpected behaviors, bottlenecks and sometimes can be used to correct
+distributed algorithms. The SimGrid team is currently instrumenting the library
+in order to let users trace their simulations and analyze them. This part of the
+user manual explains how the tracing-related features can be enabled and used
+during the development of simulators using the SimGrid library.
+
+\subsubsection faq_tracing_howitworks How it works
+
+For now, the SimGrid library is instrumented so users can trace the <b>platform
+utilization</b> using the MSG interface. This means that the tracing will
+register how much power is used for each host and how much bandwidth is used for
+each link of the platform. The idea with this type of tracing is to observe the
+overall view of resources utilization in the first place, especially the
+identification of bottlenecks, load-balancing among hosts, and so on.
+
+The idea of the instrumentation is to classify the MSG tasks by category,
+and trace
+the platform utilization (hosts and links) for each of the categories. For that,
+the tracing interface enables the declaration of categories and a function to
+mark a task with a previously declared category. <em>The tasks that are not
+classified according to a category are not traced</em>.
+
+\subsubsection faq_tracing_enabling Enabling using CMake
+
+With the sources of SimGrid, it is possible to enable the tracing
+using the parameter <b>-Dtracing=on</b> when the cmake is executed.
+The section \ref faq_tracing_functions describes all the functions available
+when this Cmake options is activated. These functions will have no effect
+if SimGrid is configured without this option (they are wiped-out by the
+C-preprocessor).
+
+\verbatim
+$ cmake -Dtracing=on .
+$ make
+\endverbatim
+
+\subsubsection faq_tracing_functions Tracing Functions
+
+\subsubsubsection Mandatory Functions
+
+\li <b>\c TRACE_start (const char *filename)</b>: This is the first function to
+be called. It receives a single argument as parameter that contains the name of
+the file that will hold the trace in the end of the simulation. It returns 0 if
+everything was properly initialized, 1 otherwise. All trace functions called
+before TRACE_start do nothing.
+
+\li <b>\c TRACE_category (const char *category)</b>: This function should be used
+to define a user category. The category can be used to differentiate the tasks
+that are created during the simulation (for example, tasks from server1,
+server2, or request tasks, computation tasks, communication tasks).
+All resource utilization (host power and link bandwidth) will be
+classified according to the task category. Tasks that do not belong to a
+category are not traced.
+
+\li <b>\c TRACE_msg_set_task_category (m_task_t task, const char *category)</b>:
+This function should be called after the creation of a task, to define the
+category of that task. The first parameter \c task must contain a task that was
+created with the function \c MSG_task_create. The second parameter
+\c category must contain a category that was previously defined by the function
+\c TRACE_category.
+
+\li <b>\c TRACE_end ()</b>: This is the last function to be called. It closes
+the trace file and stops the tracing of the simulation. All tracing will be
+completely disabled after the calling this function. Although we recommend
+the use of this function somewhere in the end of program, it can be used
+anywhere in the code. This function returns 0 if everything is ok, 1 otherwise.
+
+\subsubsubsection Optional Functions
+
+\li <b>\c TRACE_host_variable_declare (const char *variable)</b>:
+Declare a user variable that will be associated to hosts. A variable can
+be used to trace user variables such as the number of tasks in a server,
+the number of clients in an application, and so on.
+
+\li <b>\c TRACE_host_variable_[set|add|sub] (const char *variable, double
+value)</b>:
+Set the value of a given user variable. It is important to remind that
+the value of this variable is always associated to the host. The host
+that will be used when these functions are called is the one returned by
+the function \c MSG_host_self().
+
+\subsubsection faq_tracing_example Example of Instrumentation
+
+A simplified example using the tracing mandatory functions.
+
+\verbatim
+int main (int argc, char **argv)
+{
+ TRACE_start ("traced_simulation.trace");
+ TRACE_category ("request");
+ TRACE_category ("computation");
+ TRACE_category ("finalize");
+
+ MSG_global_init (&argc, &argv);
+
+ //(... after deployment ...)
+
+ m_task_t req1 = MSG_task_create("1st_request_task", 10, 10, NULL);
+ m_task_t req2 = MSG_task_create("2nd_request_task", 10, 10, NULL);
+ m_task_t req3 = MSG_task_create("3rd_request_task", 10, 10, NULL);
+ m_task_t req4 = MSG_task_create("4th_request_task", 10, 10, NULL);
+ TRACE_msg_set_task_category (req1, "request");
+ TRACE_msg_set_task_category (req2, "request");
+ TRACE_msg_set_task_category (req3, "request");
+ TRACE_msg_set_task_category (req4, "request");
+
+ m_task_t comp = MSG_task_create ("comp_task", 100, 100, NULL);
+ TRACE_msg_set_task_category (comp, "computation");
+
+ m_task_t finalize = MSG_task_create ("finalize", 0, 0, NULL);
+ TRACE_msg_set_task_category (finalize, "finalize");
+
+ //(...)
+
+ MSG_clean();
+
+ TRACE_end();
+ return 0;
+}
+\endverbatim
+
+\subsubsection faq_tracing_analyzing Analyzing the SimGrid Traces
+
+The SimGrid library, during an instrumented simulation, creates a trace file in
+the Paje file format that contains the platform utilization for the simulation
+that was executed. The visualization analysis of this file is performed with the
+visualization tool <a href="http://triva.gforge.inria.fr">Triva</a>, with
+special configurations tunned to SimGrid needs. This part of the documentation
+explains how to configure and use Triva to analyse a SimGrid trace file.
+
+- <b>Installing Triva</b>: the tool is available in the INRIAGforge,
+at <a href="http://triva.gforge.inria.fr">http://triva.gforge.inria.fr</a>.
+Use the following command to get the sources, and then check the file
+<i>INSTALL.simplified</i>. This file contains instructions to install
+the tool's dependencies in a Ubuntu/Debian Linux.
+\verbatim
+$ svn checkout svn://scm.gforge.inria.fr/svn/triva
+$ cd triva
+$ cat INSTALL.simplified
+\endverbatim
+
+- <b>Executing Triva</b>: a binary called <i>Triva</i> is available after the
+ installation (you can execute it passing <em>--help</em> to check its
+options). If the triva binary is not available after following the
+installation instructions, you may want to execute the following command to
+initialize the GNUstep environment variables (note that the location of the
+<i>GNUstep.sh</i> file may vary depending on your GNUstep installation - the
+command is known to work in Ubuntu and Debian Linux):
+\verbatim
+$ source /usr/share/GNUstep/Makefiles/GNUstep.sh
+\endverbatim
+You should be able to see this output after the installation of triva:
+\verbatim
+$ ./Triva.app/Triva --help
+Usage: Triva [OPTION...] TRACEFILE
+Trace Analysis through Visualization
+
+ You need to use one of the following options:
+ -g, --graph Graph Analysis
+ -t, --treemap Treemap Analysis
+
+ Other auxiliary options to check the trace file:
+ -c, --check Check the integrity of trace file
+ -h, --hierarchy Export the trace type hierarchy
+ -l, --list List entity types
+
+ -?, --help Give this help list
+ --usage Give a short usage message
+\endverbatim
+Triva expects that the user choose one of the available options
+(currently <em>--graph</em> or <em>--treemap</em> for a visualization analysis)
+and the trace file from the simulation.
+
+- <b>Understanding Triva - time-slice</b>: the analysis of a trace file using
+ the tool always takes into account the concept of the <em>time-slice</em>.
+This concept means that what is being visualized in the screen is always
+calculated considering a specific time frame, with its beggining and end
+timestamp. The time-slice is configured by the user and can be changed
+dynamically through the window called <em>Time Interval</em> that is opened
+whenever a trace file is being analyzed. The next figure depicts the time-slice
+configuration window.
+In the top of the window, in the space named <i>Trace Time</i>,
+the two fields show the beggining of the trace (which usually starts in 0) and
+the end (that depends on the time simulated by SimGrid). The middle of the
+window, in the square named <i>Time Slice Configuration</i>, contains the
+aspects related to the time-slice, including its <i>start</i> and its
+<i>size</i>. The gray rectangle in the bottom of this part indicates the
+<i>current time-slice</i> that is considered for the drawings. If the checkbox
+<i>Update Drawings on Sliders Change</i> is not selected, the button
+<i>Apply</i> must be clicked in order to inform triva that the
+new time-slice must be considered. The bottom part of the window, in the space
+indicated by the square <i>Time Slice Animation</i> can be used to advance
+the time-frame automatically. The user configures the amount of time that the
+time-frame will forward and how frequent this update will happen. Once this is
+configured, the user clicks the <i>Play</i> button in order to see the dynamic
+changes on the drawings.
+<center>
+\htmlonly
+<a href="triva-time_interval.png" border=0><img src="triva-time_interval.png" width="50%" border=0></a>
+\endhtmlonly
+</center>
+<b>Remarks:</b> when the trace has too many hosts or links, the computation to
+take into account a new time-slice can be expensive. When this happens, the
+<i>Frequency</i> parameter, but also updates caused by change on configurations
+when the checkbox <i>Update Drawings on Sliders
+Change</i> is selected will not be followed.
+
+- <b>Understanding Triva - graph</b>: this part of the documention explains how
+ to analyze the traces using the graph view of Triva, when the user executes
+the tool passing <em>--graph</em> as parameter. Triva opens three windows when
+this parameter is used: the <i>Time Interval</i> window (previously described),
+the <i>Graph Representation</i> window, and the <em>Graph Configuration</em>
+window. The Graph Representation is the window where drawings take place.
+Initially, it is completely white waiting for a proper graph configuration input
+by the user. We start the description of this type of analysis by describing the
+<i>Graph Configuration</i> window (depicted below). By using a particular
+configuration, triva
+can be used to customize the graph drawing according to
+the SimGrid trace that was created with user-specific categories. Before delving
+into the details of this customization, let us first explain the major parts of
+the graph configuration window. The buttons located in the top-right corner can
+be used to delete, copy and create a new configuration. The checkbox in the
+top-middle part of the window indicates if the configuration typed in the
+textfield is syntactically correct (we are using the non-XML
+<a href="http://en.wikipedia.org/wiki/Property_list">Property List Format</a> to
+describe the configuration). The pop-up button located on the top-left corner
+indicates the selected configuration (the user can have multiple graph
+configurations). The bottom-left text field contains the name of the current
+configuration (updates on this field must be followed by typing enter on the
+keyboard to take into account the name change). The bottom-right <em>Apply</em>
+button activates the current configuration, resulting on an update on the graph
+drawings.
+<center>
+\htmlonly
+<a href="triva-graph_configuration.png" border=0><img src="triva-graph_configuration.png" width="50%" border=0></a>
+\endhtmlonly
+</center>
+<b>Basic SimGrid Configuration</b>: The figure shows in the big textfield the
+basic configuration that should be used during the analysis of a SimGrid trace
+file. The basic logic of the configuration is as follows:
+\verbatim
+{
+ node = (HOST);
+ edge = (LINK);
+\endverbatim
+The nodes of the graph will be created based on the <i>node</i> parameter, which
+in this case is the different <em>"HOST"</em>s of the platform
+used to simulate. The <i>edge</i> parameter indicates that the edges of the
+graph will be created based on the <em>"LINK"</em>s of the platform. After the
+definition of these two parameters, the configuration must detail how
+<em>HOST</em>s and <em>LINK</em>s should be drawn. For that, the configuration
+must have an entry for each of the types used. For <em>HOST</em>, as basic
+configuration, we have:
+\verbatim
+ HOST = {
+ size = power;
+ scale = global;
+ };
+\endverbatim
+The parameter <em>size</em> indicates which variable from the trace file will be
+used to define the size of the node HOST in the visualization. If the simulation
+was executed with availability traces, the size of the nodes will be changed
+according to these traces. The parameter <em>scale</em> indicates if the value
+of the variable is <em>global</em> or <em>local</em>. If it is global, the value
+will be relative to the power of all other hosts, if it is local, the value will
+be relative locally.
+For <em>LINK</em> we have:
+\verbatim
+ LINK = {
+ src = SrcHost;
+ dst = DstHost;
+
+ size = bandwidth;
+ scale = global;
+ };
+\endverbatim
+For the types specified in the <em>edge</em> parameter (such as <em>LINK</em>),
+the configuration must contain two additional parameters: <em>src</em> and
+<em>dst</em> that are used to properly identify which nodes this edge is
+connecting. The values <em>SrcHost</em> and <em>DstHost</em> are always present
+in the SimGrid trace file and should not be changed in the configuration. The
+parameter <em>size</em> for the LINK, in this case, is configured as the
+variable <em>bandwidth</em>, with a <em>global</em> scale. The scale meaning
+here is exactly the same used for nodes. The last parameter is the GraphViz
+algorithm used to calculate the position of the nodes in the graph
+representation.
+\verbatim
+ graphviz-algorithm = neato;
+}
+\endverbatim
+<b>Customizing the Graph Representation</b>: triva is capable to handle
+a customized graph representation based on the variables present in the trace
+file. In the case of SimGrid, every time a category is created for tasks, two
+variables in the trace file are defined: one to indicate node utilization (how
+much power was used by that task category), and another to indicate link
+utilization (how much bandwidth was used by that category). For instance, if the
+user declares a category named <i>request</i>, there will be variables named
+<b>p</b><i>request</i> and a <b>b</b><i>request</i> (<b>p</b> for power and
+<b>b</b> for bandwidth). It is important to notice that the variable
+<i>prequest</i> in this case is only available for HOST, and
+<i>brequest</i> is only available for LINK. <b>Example</b>: suppose there are
+two categories for tasks: request and compute. To create a customized graph
+representation with a proportional separation of host and link utilization, use
+as configuration for HOST and LINK this:
+\verbatim
+ HOST = {
+ size = power;
+ scale = global;
+
+ sep_host = {
+ type = separation;
+ size = power;
+ values = (prequest, pcomputation);
+ };
+ };
+
+ LINK = {
+ src = SrcHost;
+ dst = DstHost;
+ size = bandwidth;
+ scale = global;
+
+ sep_link = {
+ type = separation;
+ size = bandwidth;
+ values = (brequest, bcomputation);
+ };
+ };
+\endverbatim
+Where <i>sep_host</i> contains a composition of type <i>separation</i> where
+its max size is the <i>power</i> of the host and the variables <i>prequest</i>
+and <i>pcomputation</i> are drawn proportionally to the size of the HOST. And
+<i>sep_link</i> is also a separation where max is defined as the
+<i>bandwidth</i> of the link, and the variables <i>brequest</i> and
+<i>bcomputation</i> are drawn proportionally within a LINK.
+<i>This configuration enables the analysis of resource utilization by MSG tasks,
+and the identification of load-balancing issues, network bottlenecks, for
+instance.</i> \n
+<b>Other compositions</b>: besides <i>separation</i>, it is possible to use
+other types of compositions, such as gradients, and colors, like this:
+\verbatim
+ gra_host = {
+ type = gradient;
+ scale = global;
+ values = (numberOfTasks);
+ };
+ color_host = {
+ type = color;
+ values = (is_server);
+ };
+\endverbatim
+Where <i>gra_host</i> creates a gradient within a node of the graph, using a
+global scale and using as value a variable called <i>numberOfTasks</i>, that
+could be declared by the user using the optional tracing functions of SimGrid.
+If scale is global, the max and min value for the gradient will be equal to the
+max and min numberOfTasks among all hosts, and if scale is local, the max and
+min value based on the value of numberOfTasks locally in each host.
+And <i>color_host</i> composition draws a square based on a positive value of
+the variable <i>is_server</i>, that could also be defined by the user using the
+SimGrid tracing functions. \n
+<b>The Graph Visualization</b>: The next figure shows a graph visualization of a
+given time-slice of the masterslave_forwarder example (present in the SimGrid
+sources). The red color indicates tasks from the <i>compute</i> category. This
+visualization was generated with the following configuration:
+\verbatim
+{
+ node = (HOST);
+ edge = (LINK);
+
+ HOST = {
+ size = power;
+ scale = global;
+
+ sep_host = {
+ type = separation;
+ size = power;
+ values = (pcompute, pfinalize);
+ };
+ };
+ LINK = {
+ src = SrcHost;
+ dst = DstHost;
+ size = bandwidth;
+ scale = global;
+
+ sep_link = {
+ type = separation;
+ size = bandwidth;
+ values = (bcompute, bfinalize);
+ };
+ };
+ graphviz-algorithm = neato;
+}
+\endverbatim
+<center>
+\htmlonly
+<a href="triva-graph_visualization.png" border=0><img src="triva-graph_visualization.png" width="50%" border=0></a>
+\endhtmlonly
+</center>
+
+- <b>Understading Triva - colors</b>: An important issue when using Triva is how
+ to define colors. To do that, we have to know which variables are defined in
+the trace file generated by the SimGrid library. The parameter <em>--list</em>
+lists the variables for a given trace file:
+\verbatim
+$ Triva -l masterslave_forwarder.trace
+iFile
+c platform
+c HOST
+v power
+v is_slave
+v is_master
+v task_creation
+v task_computation
+v pcompute
+v pfinalize
+c LINK
+v bandwidth
+v latency
+v bcompute
+v bfinalize
+c user_type
+\endverbatim
+We can see that HOST has seven variables (from power to pfinalize) and LINK has
+four (from bandwidth to bfinalize). To define a red color for the
+<i>pcompute</i> and <i>bcompute</i> (which are defined based on user category
+<i>compute</i>), execute:
+\verbatim
+$ defaults write Triva 'pcompute Color' '1 0 0'
+$ defaults write Triva 'bcompute Color' '1 0 0'
+\endverbatim
+Where the three numbers in each line are the RGB color with values from 0 to 1.
+
\section faq_troubleshooting Troubleshooting
\subsection faq_trouble_lib_compil SimGrid compilation and installation problems
\subsubsection faq_trouble_lib_config ./configure fails!
-We now only one reason for the configure to fail:
+We know only one reason for the configure to fail:
- - <b>You are using a borken build environment</b>\n
+ - <b>You are using a broken build environment</b>\n
If symptom is that configure complains about gcc not being able to build
executables, you are probably missing the libc6-dev package. Damn Ubuntu.
There is several reasons which may cause the make check to fail on your
machine:
- - <b>You are using a borken libc (probably concerning the contextes)</b>.\n
+ - <b>You are using a broken libc (probably concerning the contextes)</b>.\n
The symptom is that the "make check" fails within the examples/msg directory.\n
By default, SimGrid uses something called ucontexts. This is part of the
libc, but it's quite undertested. For example, some (old) versions of the
glibc on alpha do not implement these functions, but provide the stubs
- (which return ENOSYS: not implemented). It may fool our detection mecanism
+ (which return ENOSYS: not implemented). It may fool our detection mechanism
and leads to segfaults. There is not much we can do to fix the bug.
A workaround is to compile with --with-context=pthread to avoid
- ucontext completely. You'll be a bit more limitated in the number
- of simulated processes you can start concurently, but 5000
+ ucontext completely. You'll be a bit more limited in the number
+ of simulated processes you can start concurrently, but 5000
processes is still enough for most purposes, isn't it?\n
This limitation is the reason why we insist on using this piece of ...
software even if it's so troublesome.\n
for all the details, but you simply forgot to call one of
XBT_LOG_NEW_DEFAULT_CATEGORY() or XBT_LOG_NEW_DEFAULT_SUBCATEGORY().
-\subsubsection faq_trouble_pthreadstatic "gcc: undefinded reference to pthread_key_create"
+\subsubsection faq_trouble_pthreadstatic "gcc: undefined reference to pthread_key_create"
This indicates that one of the library SimGrid depends on (libpthread
here) was missing on the linking command line. Dependencies of
Actually, the message comes directly from FleXML, the technology on top of
which the parser is built. FleXML has the bad idea of fetching the whole
document in memory before parsing it. And moreover, the memory buffer size
-must be determinded at compilation time.
+must be determined at compilation time.
We use a value which seems big enough for our need without bloating the
simulators footprints. But of course your mileage may vary. In this case,
Flex is recent enough (>= 2.5.31). If not the compilation process should
warn you.
-A while ago, we worked on FleXML to reduce a bit its memory consumtion, but
+A while ago, we worked on FleXML to reduce a bit its memory consumption, but
these issues remain. There is two things we should do:
- use a dynamic buffer instead of a static one so that the only limit
and it breaks the hack we devised to bypass the parser, as explained in
\ref faq_flexml_bypassing. Indeed, this is not a classical usage of the
parser, and Will didn't imagine that we may have used (and even documented)
-such a crude usage of FleXML. So, we now have to repare the bypassing
-functionnality to use the lastest FleXML version and fix the memory usage in
+such a crude usage of FleXML. So, we now have to repair the bypassing
+functionality to use the lastest FleXML version and fix the memory usage in
SimGrid.
\subsubsection faq_trouble_gras_transport GRAS spits networking error messages
Gras, on real platforms, naturally use regular sockets to communicate. They
-are deeply hiden in the gras abstraction, but when things go wrong, you may
+are deeply hidden in the gras abstraction, but when things go wrong, you may
get some weird error messages. Here are some example, with the probable
reason:
- <b>Socket closed by remote side</b>: if the remote process is not
supposed to close the socket at this point, it may be dead.
- - <b>Connection reset by peer</b>: I found this on internet about this
+ - <b>Connection reset by peer</b>: I found this on Internet about this
error. I think it's what's happening here, too:\n
<i>This basically means that a network error occurred while the client was
receiving data from the server. But what is really happening is that the
When debugging SimGrid, it's easier to pass the
--disable-compiler-optimization flag to the configure if valgrind or
gdb get fooled by the optimization done by the compiler. But you
-should remove these flages when everything works before going in
+should remove these flag when everything works before going in
production (before launching your 1252135 experiments), or everything
will run only one half of the true SimGrid potential.
*/
+******************************************************************
+* OLD CRUFT NOT USED ANYMORE *
+******************************************************************
+
+
+\subsection faq_crosscompile Cross-compiling a Windows DLL of SimGrid from linux
+
+At the moment, we do not distribute Windows pre-compiled version of SimGrid
+because the support for this platform is still experimental. We know that
+some parts of the GRAS environment do not work, and we think that the others
+environments (MSG and SD) have good chances to work, but we didn't test
+ourselves. This section explains how we generate the SimGrid DLL so that you
+can build it for yourself. First of all, you need to have a version more
+recent than 3.1 (ie, a SVN version as time of writting).
+
+In order to cross-compile the package to windows from linux, you need to
+install mingw32 (minimalist gnu win32). On Debian, you can do so by
+installing the packages mingw32 (compiler), mingw32-binutils (linker and
+so), mingw32-runtime.
+
+You can use the VPATH support of configure to compile at the same time for
+linux and windows without dupplicating the source nor cleaning the tree
+between each. Just run bootstrap (if you use the SVN) to run the autotools.
+Then, create a linux and a win directories. Then, type:
+\verbatim cd linux; ../configure --srcdir=.. <usual configure flags>; make; cd ..
+cd win; ../configure --srcdir=.. --host=i586-mingw32msvc <flags>; make; cd ..
+\endverbatim
+The trick to VPATH builds is to call configure from another directory,
+passing it an extra --srcdir argument to tell it where all the sources are.
+It will understand you want to use VPATH. Then, the trick to cross-compile
+is simply to add a --host argument specifying the target you want to build
+for. The i586-mingw32msvc string is what you have to pass to use the mingw32
+environment as distributed in Debian.
+
+After that, you can run all make targets from both directories, and test
+easily that what you change for one arch does not break the other one.
+
+It is possible that this VPATH build thing breaks from time to time in the
+SVN since it's quite fragile, but it's granted to work in any released
+version. If you experience problems, drop us a mail.
+
+Another possible source of issue is that at the moment, building the
+examples request to use the gras_stub_generator tool, which is a compiled
+program, not a script. In cross-compilation, you need to cross-execute with
+wine for example, which is not really pleasant. We are working on this, but
+in the meanwhile, simply don't build the examples in cross-compilation
+(<tt>cd src</tt> before running make).
+
+Program (cross-)compiled with mingw32 do request an extra DLL at run-time to be
+usable. For example, if you want to test your build with wine, you should do
+the following to put this library where wine looks for DLLs.
+\verbatim
+cp /usr/share/doc/mingw32-runtime/mingwm10.dll.gz ~/.wine/c/windows/system/
+gunzip ~/.wine/c/windows/system/mingwm10.dll.gz
+\endverbatim
+
+The DLL is built in src/.libs, and installed in the <i>prefix</i>/bin directory
+when you run make install.
+
+If you want to use it in a native project on windows, you need to use
+simgrid.dll and mingwm10.dll. For each DLL, you need to build .def file
+under linux (listing the defined symbols), and convert it into a .lib file
+under windows (specifying this in a way that windows compilers like). To
+generate the def files, run (under linux):
+\verbatim echo "LIBRARY libsimgrid-0.dll" > simgrid.def
+echo EXPORTS >> simgrid.def
+nm libsimgrid-0.dll | grep ' T _' | sed 's/.* T _//' >> simgrid.def
+nm libsimgrid-0.dll | grep ' D _' | sed 's/.* D _//' | sed 's/$/ DATA/' >> simgrid.def
+
+echo "LIBRARY mingwm10.dll" > mingwm10.def
+echo EXPORTS >> mingwm10.def
+nm mingwm10.dll | grep ' T _' | sed 's/.* T _//' >> mingwm10.def
+nm mingwm10.dll | grep ' D _' | sed 's/.* D _//' | sed 's/$/ DATA/' >> mingwm10.def
+\endverbatim
+
+To create the import .lib files, use the <tt>lib</tt> windows tool (from
+MSVC) the following way to produce simgrid.lib and mingwm10.lib
+\verbatim lib /def:simgrid.def
+lib /def:mingwm10.def
+\endverbatim
+
+If you happen to use Borland C Builder, the right command line is the
+following (note that you don't need any file.def to get this working).
+\verbatim implib simgrid.lib libsimgrid-0.dll
+implib mingwm10.lib mingwm10.dll
+\endverbatim
+
+Then, set the following parameters in Visual C++ 2005:
+Linker -> Input -> Additional dependencies = simgrid.lib mingwm10.lib
+
+Just in case you wonder how to generate a DLL from libtool in another
+project, we added -no-undefined to any lib*_la_LDFLAGS variables so that
+libtool accepts to generate a dynamic library under windows. Then, to make
+it true, we pass any dependencies (such as -lws2 under windows or -lpthread
+on need) on the linking line. Passing such deps is a good idea anyway so
+that they get noted in the library itself, avoiding the users to know about
+our dependencies and put them manually on their compilation line. Then we
+added the AC_LIBTOOL_WIN32_DLL macro just before AC_PROG_LIBTOOL in the
+configure.ac. It means that we exported any symbols which need to be.
+Nowadays, functions get automatically exported, so we don't need to load our
+header files with tons of __declspec(dllexport) cruft. We only need to do so
+for data, but there is no public data in SimGrid so we are good.
+
