-/*! \page faq Frequently Asked Questions
+/*! \page FAQ Frequently Asked Questions
\htmlinclude .FAQ.doc.toc
\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://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://www.loria.fr/~quinson/blog/2010/06/28/Tutorial_at_HPCS/">the slides of the HPCS'10 tutorial</a>
+(or to these <a href="http://graal.ens-lyon.fr/~alegrand/articles/slides_g5k_simul.pdf">ancient
+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
The difference between both is that MSG is somehow easier to use, but GRAS
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
-both world.
-
-\subsection faq_generic First steps with SimGrid
-
-If you decide to go for the MSG interface, please read carefully the
-\ref MSG_examples. You'll find in \ref MSG_ex_master_slave a very
-simple consisting of a master (that owns a bunch of tasks and
-distributes them) , some slaves (that process tasks whenever they
-receive one) and some forwarder agents (that simply pass the tasks
-they receive to some slaves).
-
-If you decide to go for the GRAS interface, you should definitively
-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 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.
-
-If you decide to go for another interface, I'm afraid your only sources
-of information will be the source code and the mailing lists...
+you can run your code both in the simulator and on a real platform. For this,
+there are two implementations of the GRAS interface, one for simulation, and one
+for real execution. So, you just have to relink your code to choose one of
+both worlds.
\subsection faq_visualization Visualizing and analyzing the results
./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 section \ref faq_tracing.
+We also have a more graphical output. Have a look at section \ref options_tracing.
\subsection faq_C Argh! Do I really have to code in C?
-Up until now, there is no binding for other languages. If you use C++,
+Currently bindings on top of MSG are supported for Java, Ruby and Lua. You can find a few
+documentation about them on the doc page. Note that bindings are released separately from the main dist
+and so have their own version numbers.
+
+Moreover If you use C++,
you should be able to use the SimGrid library as a standard C library
and everything should work fine (simply <i>link</i> against this
library; recompiling SimGrid with a C++ compiler won't work and it
wouldn't help if you could).
-In fact, we are currently working on Java bindings of MSG to allow
-all the undergrad students of the world to use this tool. This is a
-little more tricky than I would have expected, but the work is moving
-fast forward [2006/05/13]. More languages are evaluated, but for now,
-we do not feel a real demand for any other language. Please speak up!
-
-\section faq_cmake Installing the SimGrid library with Cmake (since V3.4)
-
-\subsection faq_intro Some generalitty
-
-\subsubsection faq_intro1 What is Cmake?
-
-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 plateforms. 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 :
-
-For Unix and MacOS:
- \li make
- \li perl and libpcre
- \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>
-
-For Windows :
- \li cmake 2.8 <a href="http://www.cmake.org/cmake/resources/software.html">(download page)</a>
- \li perl strawberry <a href="http://www.strawberryperl.com/download/5.12.2.0/strawberry-perl-5.12.2.0.msi">(download page)</a>
- \li pcre-7.0 <a href="http://sourceforge.net/projects/gnuwin32/files/pcre/7.0/pcre-7.0.exe/download">(download page)</a>
-
-\subsubsection faq_cmakeoption1 Liste of options
-
-\verbatim
-"cmake -D[name]=[value] ... ./"
-
-[name] enable_gtnets [value] ON/OFF or TRUE/FALSE or 1/0
- enable_lua 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_smpi 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_model-checking ON/OFF or TRUE/FALSE or 1/0
- enable_debug ON/OFF or TRUE/FALSE or 1/0
- enable_jedule ON/OFF or TRUE/FALSE or 1/0
- enable_latency_bound_tracking ON/OFF or TRUE/FALSE or 1/0
- enable_lib_static ON/OFF or TRUE/FALSE or 1/0
- enable_pcre ON/OFF or TRUE/FALSE or 1/0
- custom_flags <flags>
- gtnets_path <path_to_gtnets_directory>
- CMAKE_INSTALL_PREFIX <path_to_install_directory>
- pipol_user <pipol_username>
-\endverbatim
-
-\subsubsection faq_cmakeoption2 Options explaination
-
- \li enable_gtnets : set to true implie that user wants to use gtnets.
-
- \li enable_lua : set to true implie that user wants to add lua 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_smpi : Set to true if you want to use smpi lib. Actually on simgrid v3.4.1 Mac doesn't support lib smpi.
-
- \li enable_maintainer_mode : set to true it remakes some files.
-
- \li enable_supernovae : set to true make one file for each lib and compile with those generated files.
-
- \li enable_tracing : To enable the generation of simulation traces for visualization.
-
- \li enable_coverage : When set to true this option enable code coverage by setting -fprofile-arcs -ftest-coverage flags.
-
- \li enable_memcheck : When set to true this option enable tests for memcheck.
-
- \li enable_model-checking : Enable the model checking when set to true.
-
- \li enable_debug : If enable_debug is set to 'off' Simgrid compil flag has '-DNDEBUG' option.
-
- \li enable_jedule : To enable jedule mode, which creates visualizations of task schedules with Simdag.
-
- \li enable_latency_bound_tracking : Set to on if you want to be warned when communications are limited by round trip time.
-
- \li enable_lib_static : Enable generated Simgrid and smpi static libraries.
-
- \li enable_pcre : Use or not the pcre lib for memory optimization.
-
- \li custom_flags : If user wants to use a specific flag during compilation, give here.
-
- \li gtnets_path : Path to gtnets install directory (ex /usr)
-
- \li CMAKE_INSTALL_PREFIX : Path where are installed lib/ doc/ and include/ directories (ex /usr/local)
-
- \li pipol_user : specify your pipol username if you want to use the pipol-remote command.
-
-\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_smpi on
-enable_supernovae on
-enable_tracing on
-enable_compile_optimizations on
-enable_debug on
-enable_pcre on
-enable_compile_warnings off
-enable_maintainer_mode off
-enable_coverage off
-enable_memcheck off
-enable_model-checking off
-enable_jedule off
-enable_latency_bound_tracking off
-enable_lib_static off
-CMAKE_INSTALL_PREFIX /usr/local
-custom_flags null
-gtnets_path null
-pipol_user null
-\endverbatim
-
-\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
-
-On Windows
-
-\verbatim
-cmake -G"Unix Makefiles" -D[name]=[value] ... ./
-gmake
-\endverbatim
-
-\subsubsection faq_cmakecompilation2 With ccmake tool.
-
-\verbatim
-"ccmake ./"
-\endverbatim
-Then follow instructions.
-
-\subsubsection faq_cmakecompilation2bis Build out of source.
-
-As cmake generate many files used for compilation, we recommand to make a build directory.
-For examples you can make :
-
-\verbatim
-"navarrop@caraja:~/Developments$ cd simgrid/"
-"navarrop@caraja:~/Developments/simgrid$ mkdir build_directory"
-"navarrop@caraja:~/Developments/simgrid$ cd build_directory/"
-"navarrop@caraja:~/Developments/simgrid/build_directory$ cmake ../"
-"navarrop@caraja:~/Developments/simgrid/build_directory$ make"
-\endverbatim
-
-Or complety out of sources :
-
-\verbatim
-"navarrop@caraja:~/Developments$ mkdir build_dir"
-"navarrop@caraja:~/Developments$ cd build_dir/"
-"navarrop@caraja:~/Developments/build_dir$ cmake ../simgrid/"
-"navarrop@caraja:~/Developments/build_dir$ make"
-\endverbatim
-
-Those two kind of compilation permit to delete files created by compilation easier.
-
-\subsubsection faq_cmakecompilation3 Resume of command line
-
- \li CMake
-\verbatim
-cmake <path> configure the project
-make build all targets
-make VERBOSE=1 build all targets and print build command lines
-make check test all targets and summarize
-make dist make the distrib
-make distcheck check the dist (make + make dist + make check)
-make install install the project (doc/ bin/ lib/ include/)
-make uninstall uninstall the project (doc/ bin/ lib/ include/)
-make clean clean all targets
-make simgrid_documentation Create simgrid documentation
-\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>.
-
-\subsection faq_cmakeinstall How to install with cmake?
-
-\subsubsection faq_cmakeinstall1 From svn.
-
-For Unix and MacOS:
-\verbatim
-cmake -Denable_maintainer_mode=on -DCMAKE_INSTALL_PREFIX=/home/navarrop/Bureau/install_simgrid ./
-make
-make install
-\endverbatim
-
-For Windows:
-
-\verbatim
-cmake -G"Unix Makefiles" -DCMAKE_INSTALL_PREFIX=C:\simgrid_install ./
-gmake
-gmake install
-\endverbatim
-
-\subsubsection faq_cmakeinstall2 From a distrib
-
-\verbatim
-For version 3.4.1 and 3.4
- cmake -Dprefix=/home/navarrop/Bureau/install_simgrid ./
- make
- make install-simgrid
-Since version 3.5
- cmake -DCMAKE_INSTALL_PREFIX=/home/navarrop/Bureau/install_simgrid ./
- make
- make install
-\endverbatim
-
-\subsection faq_cmakeWHATisInstall What is installed by cmake?
-
-\subsubsection faq_cmakeWHATisInstallBIN CMAKE_INSTALL_PREFIX/bin
-\verbatim
-tesh
-graphicator
-gras_stub_generator
-simgrid_update_xml
-simgrid-colorizer
-smpicc
-smpiff
-smpif2c
-smpirun
-\endverbatim
-\subsubsection faq_cmakeWHATisInstallDOC CMAKE_INSTALL_PREFIX/doc
-\verbatim
-simgrid/examples/
-simgrid/html/
-\endverbatim
-\subsubsection faq_cmakeWHATisInstallINCLUDE CMAKE_INSTALL_PREFIX/include
-\verbatim
-amok/
-gras/
-instr/
-mc/
-msg/
-simdag/
-simix/
-smpi/
-surf/
-xbt/
-gras.h
-simgrid_config.h
-xbt.h
-\endverbatim
-\subsubsection faq_cmakeWHATisInstallLIB CMAKE_INSTALL_PREFIX/lib
-\verbatim
-libgras.so.3.5
-libsimgrid.so.3.5
-libsmpi.so.3.5
-libsimgrid.so -> libsimgrid.so.3.5
-libgras.so -> libgras.so.3.5
-libsmpi.so -> libsmpi.so.3.5
-lua/5.1/simgrid.so -> ../../libsimgrid.so
-ruby/1.9.0/x86_64-linux/libsimgrid.so -> ../../../libsimgrid.so
-ruby/1.9.0/x86_64-linux/simgrid.rb
-\endverbatim
-\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 "${CMAKE_HOME_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) #target_link_libraries(<name_of_targe> <dependencies>)
-\endverbatim
-
-Then you have to modified <project/directory>/buildtools/Cmake/MakeExeLib.cmake and add
-this line :
-\verbatim
-add_subdirectory(${CMAKE_HOME_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/DefinePackages.cmake
-
-\verbatim
-set(JMSG_JAVA_SRC
- ${CMAKE_HOME_DIRECTORY}/src/java/simgrid/msg/MsgException.java
- ${CMAKE_HOME_DIRECTORY}/src/java/simgrid/msg/JniException.java
- ${CMAKE_HOME_DIRECTORY}/src/java/simgrid/msg/NativeException.java
- ${CMAKE_HOME_DIRECTORY}/src/java/simgrid/msg/HostNotFoundException.java
- ${CMAKE_HOME_DIRECTORY}/src/java/simgrid/msg/ProcessNotFoundException.java
- ${CMAKE_HOME_DIRECTORY}/src/java/simgrid/msg/Msg.java
- ${CMAKE_HOME_DIRECTORY}/src/java/simgrid/msg/Process.java
- ${CMAKE_HOME_DIRECTORY}/src/java/simgrid/msg/Host.java
- ${CMAKE_HOME_DIRECTORY}/src/java/simgrid/msg/Task.java
- ${CMAKE_HOME_DIRECTORY}/src/java/simgrid/msg/MsgNative.java
- ${CMAKE_HOME_DIRECTORY}/src/java/simgrid/msg/ApplicationHandler.java
- ${CMAKE_HOME_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/AddTests.cmake
-with this function : ADD_TEST(<name> <bin> <ARGS>)
-
-\verbatim
-add_test(test-simdag-1 ${CMAKE_HOME_DIRECTORY}/testsuite/simdag/sd_test --cfg=path:${CMAKE_HOME_DIRECTORY}/testsuite/simdag small_platform_variable.xml)
-\endverbatim
-
-\subsection faq_PIPOL Pipol-remote
-
-Now we offer the possibility to test your local sources on pipol platforms before a commit. Of course you have to be user of pipol <a href="https://pipol.inria.fr/users/">(Account request)</a> cause you need to give your pipol_username to cmake. Here is a list of available systems :
-\verbatim
- amd64_kvm-linux-debian-lenny
- amd64_kvm-linux-debian-testing
- amd64_kvm-windows-7
- amd64-linux-centos-5.dd.gz
- amd64-linux-debian-etch.dd.gz
- amd64-linux-debian-lenny.dd.gz
- amd64-linux-debian-testing.dd.gz
- amd64-linux-fedora-core10.dd.gz
- amd64-linux-fedora-core11.dd.gz
- amd64-linux-fedora-core12.dd.gz
- amd64-linux-fedora-core13.dd.gz
- amd64-linux-fedora-core7.dd.gz
- amd64-linux-fedora-core8.dd.gz
- amd64-linux-fedora-core9.dd.gz
- amd64-linux-mandriva-2007_springs_powerpack.dd.gz
- amd64-linux-mandriva-2009_powerpack.dd.gz
- amd64-linux-opensuse-11.dd.gz
- amd64-linux-redhatEL-5.0.dd.gz
- amd64-linux-suse-LES10.dd.gz
- amd64-linux-ubuntu-feisty.dd.gz
- amd64-linux-ubuntu-hardy.dd.gz
- amd64-linux-ubuntu-intrepid.dd.gz
- amd64-linux-ubuntu-jaunty.dd.gz
- amd64-linux-ubuntu-karmic.dd.gz
- amd64-linux-ubuntu-lucid.dd.gz
- amd64-unix-freebsd-7.dd.gz
- amd64-windows-server-2003-64bits.dd.gz
- amd64-windows-server-2008-64bits.dd.gz
- i386_kvm-linux-debian-lenny
- i386_kvm-linux-debian-testing
- i386_kvm-linux-fedora-core13
- i386_kvm-windows-xp-pro-sp3
- i386-linux-centos-5.dd.gz
- i386-linux-debian-etch.dd.gz
- i386-linux-debian-lenny.dd.gz
- i386-linux-debian-testing.dd.gz
- i386-linux-fedora-core10.dd.gz
- i386-linux-fedora-core11.dd.gz
- i386-linux-fedora-core12.dd.gz
- i386-linux-fedora-core13.dd.gz
- i386-linux-fedora-core7.dd.gz
- i386-linux-fedora-core8.dd.gz
- i386-linux-fedora-core9.dd.gz
- i386-linux-mandriva-2007_springs_powerpack.dd.gz
- i386-linux-mandriva-2009_powerpack.dd.gz
- i386-linux-opensuse-11.dd.gz
- i386-linux-redhatEL-5.0.dd.gz
- i386-linux-suse-LES10.dd.gz
- i386-linux-ubuntu-feisty.dd.gz
- i386-linux-ubuntu-hardy.dd.gz
- i386-linux-ubuntu-intrepid.dd.gz
- i386-linux-ubuntu-jaunty.dd.gz
- i386-linux-ubuntu-karmic.dd.gz
- i386-linux-ubuntu-lucid.dd.gz
- i386_mac-mac-osx-server-leopard.dd.gz
- i386-unix-freebsd-7.dd.gz
- i386-unix-opensolaris-10.dd.gz
- i386-unix-opensolaris-11.dd.gz
- i386-unix-solaris-10.dd.gz
- ia64-linux-debian-lenny.dd
- ia64-linux-fedora-core9.dd
- ia64-linux-redhatEL-5.0.dd
- x86_64_mac-mac-osx-server-snow-leopard.dd.gz
- x86_mac-mac-osx-server-snow-leopard.dd.gz
-\endverbatim
-
-Two kind of uses are possible :
-\verbatim
-This command copy your source and execute a configure then a build and finish with tests.
- bob@caraja:~/Developments/simgrid/tmp_build$ make <name_of_image>
-
-This command copy your source and execute a \"ctest -D Experimental\" and submit the result to cdash.
- bob@caraja:~/Developments/simgrid/tmp_build$ make <name_of_image>_experimental
-\endverbatim
-All commands are resumed with :
-\verbatim
-bob@caraja:~/Developments/simgrid/tmp_build$ make pipol_experimental_list_images
-bob@caraja:~/Developments/simgrid/tmp_build$ make pipol_test_list_images
-\endverbatim
-
-\section faq_installation Installing the SimGrid library with Autotools (valid until V3.3.4)
-
-Many people have been asking me questions on how to use SimGrid. Quite
-often, the questions were not really about SimGrid but on the
-installation process. This section is intended to help people that are
-not familiar with compiling C files under UNIX. If you follow these
-instructions and still have some troubles, drop an e-mail to
-<simgrid-user@lists.gforge.inria.fr>.
-
-\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>.
-Suppose you have uncompressed SimGrid in some temporary location of
-your home directory (say <tt>/home/joe/tmp/simgrid-3.0.1 </tt>). The
-simplest way to use SimGrid is to install it in your home
-directory. Change your directory to
-<tt>/home/joe/tmp/simgrid-3.0.1</tt> and type
-
-\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
-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
-<tt>make</tt> command with <tt>script</tt>. There is no way for us to help you
-without the relevant bits of information.
-
-Now, the following directory should have been created :
-
- \li <tt>/home/joe/doc/simgrid/html/</tt>
- \li <tt>/home/joe/lib/</tt>
- \li <tt>/home/joe/include/</tt>
-
-SimGrid is not a binary, it is a library. Both a static and a dynamic
-version are available. Here is what you can find if you try a <tt>ls
-/home/joe/lib</tt>:
-
-\verbatim libsimgrid.a libsimgrid.la libsimgrid.so libsimgrid.so.0 libsimgrid.so.0.0.1
-\endverbatim
-
-Thus, there is two ways to link your program with SimGrid:
- \li Either you use the static version, e.g
-\verbatim gcc libsimgrid.a -o MainProgram MainProgram.c
-\endverbatim
- In this case, all the SimGrid functions are directly
- included in <tt>MainProgram</tt> (hence a bigger binary).
- \li Either you use the dynamic version (the preferred method)
-\verbatim gcc -lsimgrid -o MainProgram MainProgram.c
-\endverbatim
- In this case, the SimGrid functions are not included in
- <tt>MainProgram</tt> and you need to set your environment
- variable in such a way that <tt>libsimgrid.so</tt> will be
- found at runtime. This can be done by adding the following
- line in your .bashrc (if you use bash and if you have
- installed the SimGrid libraries in your home directory):
-\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
-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
-of the lastest features, you may want to use the SVN version instead of a
-released one.
-
-For that, you first need to get the "simgrid" module from
-<a href="http://gforge.inria.fr/scm/?group_id=12">here</a>.
-
-You won't find any <tt>configure</tt> and a few other things
-(<tt>Makefile.in</tt>'s, documentation, ...) will be missing as well. The
-reason for that is that all these files have to be regenerated using the
-latest versions of <tt>autoconf</tt>, <tt>libtool</tt>, <tt>automake</tt>
-(>1.9) and <tt>doxygen</tt> (>1.4). To generate the <tt>configure</tt> and
-the <tt>Makefile.in</tt>'s, you just have to launch the <tt>bootstrap</tt>
-command that resides in the top of the source tree. Then just follow the
-instructions of Section \ref faq_compiling.
-
-We insist on the fact that you really need the latest versions of
-autoconf, automake and libtool. Doing this step on exotic architectures/systems
-(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
-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
-configure script and friends, configure SimGrid and build it.
-
-\verbatim svn checkout svn://scm.gforge.inria.fr/svn/simgrid/simgrid/trunk simgrid
-cd simgrid
-./bootstrap
-./configure --enable-maintainer-mode --prefix=<where to install SimGrid>
-make \endverbatim
-
-Then, if you want to install SimGrid on the current box, just do:
-\verbatim make install \endverbatim
-
-If you want to build an snapshot of the SVN to deploy it on another box (for
-example because the other machine don't have the autotools), do:
-\verbatim make dist \endverbatim
-
-Moreover, you should never call the autotools manually since you must run
-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 explicitly.
-
-
-\subsection faq_setting_MSG Setting up your own MSG code
-
-Do not build your simulator by modifying the SimGrid examples. Go
-outside the SimGrid source tree and create your own working directory
-(say <tt>/home/joe/SimGrid/MyFirstScheduler/</tt>).
-
-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).
-
- \li <tt>sched.h</tt>: 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).
-
- \li <tt>sched.c</tt>: a C file including <tt>sched.h</tt> and
- implementing the core of the scheduler. Most of these
- functions use the MSG functions defined in section \ref
- msg_gos_functions.
-
- \li <tt>masterslave.c</tt>: a C file with the main function, i.e.
- the MSG initialization (MSG_global_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.
-
-\verbatim
-all: masterslave
-masterslave: masterslave.o sched.o
-
-INSTALL_PATH = $$HOME
-CC = gcc
-PEDANTIC_PARANOID_FREAK = -O0 -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
-REASONABLY_CAREFUL_DUDE = -Wall
-NO_PRAYER_FOR_THE_WICKED = -w -O2
-WARNINGS = $(REASONABLY_CAREFUL_DUDE)
-CFLAGS = -g $(WARNINGS)
-
-INCLUDES = -I$(INSTALL_PATH)/include
-DEFS = -L$(INSTALL_PATH)/lib/
-LDADD = -lm -lsimgrid
-LIBS =
-
-%: %.o
- $(CC) $(INCLUDES) $(DEFS) $(CFLAGS) $^ $(LIBS) $(LDADD) -o $@
-
-%.o: %.c
- $(CC) $(INCLUDES) $(DEFS) $(CFLAGS) -c -o $@ $<
-
-clean:
- rm -f $(BIN_FILES) *.o *~
-.SUFFIXES:
-.PHONY : clean
-
-\endverbatim
-
-The first two lines indicates what should be build when typing make
-(<tt>masterslave</tt>) and of which files it is to be made of
-(<tt>masterslave.o</tt> and <tt>sched.o</tt>). This makefile assumes
-that you have set up correctly your <tt>LD_LIBRARY_PATH</tt> variable
-(look, there is a <tt>LDADD = -lm -lsimgrid</tt>). If you prefer using
-the static version, remove the <tt>-lsimgrid</tt> and add a
-<tt>$(INSTALL_PATH)/lib/libsimgrid.a</tt> on the next line, right
-after the <tt>LIBS = </tt>.
-
-More generally, if you have never written a Makefile by yourself, type
-in a terminal : <tt>info make</tt> and read the introduction. The
-previous example should be enough for a first try but you may want to
-perform some more complex compilations...
-
-\subsection faq_setting_GRAS Setting up your own GRAS code
-
-If you use the GRAS interface instead of the MSG one, then previous section
-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.
+For now,
+we do not feel a real demand for any other language. But if you think there is one,
+ please speak up!
\section faq_howto Feature related questions
possible. This kind of feature is rather easy to implement by users
and the semantic you associate really depends on people. Having a
*generic* task duplication mechanism is not that trivial (in
-particular because of the data field). That is why I would recommand
+particular because of the data field). That is why I would recommend
that you write it by yourself even if I can give you advice on how to
do it.
-You have the following functions to get informations about a task:
+You have the following functions to get information about a task:
MSG_task_get_name(), MSG_task_get_compute_duration(),
MSG_task_get_remaining_computation(), MSG_task_get_data_size(),
and MSG_task_get_data().
- MSG_comm_destroy()
We refer you to the description of these functions for more details on their usage as well
-as to the exemple section on \ref MSG_ex_asynchronous_communications.
+as to the example section on \ref MSG_ex_asynchronous_communications.
\subsubsection faq_MIA_thread_synchronization I need to synchronize my MSG processes
communications have an influence on computational power. Should it be taken
into account too?
-First of all, it's near to impossible to predict the load beforehands in the
+First of all, it's near to impossible to predict the load beforehand in the
simulator since it depends on too much parameters (background load
variation, bandwidth sharing algorithmic complexity) some of them even being
-not known beforehands (other task starting at the same time). So, getting
+not known beforehand (other task starting at the same time). So, getting
this information is really hard (just like in real life). It's not just that
we want MSG to be as painful as real life. But as it is in some way
realistic, we face some of the same problems as we would face in real life.
of processes in your simulations.
- <b>A few thousands of simulated processes</b> (soft tricks)\n
- SimGrid can use either pthreads library or the UNIX98 contextes. On
+ SimGrid can use either pthreads library or the UNIX98 contexts. On
most systems, the number of pthreads is limited and then your
simulation may be limited for a stupid reason. This is especially
true with the current linux pthreads, and I cannot get more than
contexts allow me to raise the limit to 25,000 simulated processes
on my laptop.\n\n
The <tt>--with-context</tt> option of the <tt>./configure</tt>
- script allows you to choose between UNIX98 contextes
+ script allows you to choose between UNIX98 contexts
(<tt>--with-context=ucontext</tt>) and the pthread version
(<tt>--with-context=pthread</tt>). The default value is ucontext
when the script detect a working UNIX98 context implementation. On
Windows boxes, the provided value is discarded and an adapted
version is picked up.\n\n
- We experienced some issues with contextes on some rare systems
+ We experienced some issues with contexts on some rare systems
(solaris 8 and lower or old alpha linuxes comes to mind). The main
- problem is that the configure script detect the contextes as being
+ problem is that the configure script detect the contexts as being
functional when it's not true. If you happen to use such a system,
switch manually to the pthread version, and provide us with a good
patch for the configure script so that it is done automatically ;)
- <b>Hundred thousands of simulated processes</b> (hard-core tricks)\n
- As explained above, SimGrid can use UNIX98 contextes to represent
+ As explained above, SimGrid can use UNIX98 contexts to represent
and handle the simulated processes. Thanks to this, the main
limitation to the number of simulated processes becomes the
available memory.\n\n
between 25,000 processes on my laptop (1Gb memory, 1.5Gb swap).\n
- First of all, make sure your code runs for a few hundreds
processes before trying to push the limit. Make sure it's
- valgrind-clean, ie that valgrind does not report neither memory
+ valgrind-clean, i.e. that valgrind does not report neither memory
error nor memory leaks. Indeed, numerous simulated processes
result in *fat* simulation hindering debugging.
- It was really boring to write 25,000 entries in the deployment
- The deployment file became quite big, so I had to do what is in
the FAQ entry \ref faq_flexml_limit
- Each UNIX98 context has its own stack entry. As debugging this is
- quite hairly, the default value is a bit overestimated so that
- user don't get into trouble about this. You want to tune this
- size to increse the number of processes. This is the
+ quite hairy, the default value is a bit overestimated so that
+ user doesn't get into trouble about this. You want to tune this
+ size to increase the number of processes. This is the
<tt>STACK_SIZE</tt> define in
<tt>src/xbt/xbt_context_sysv.c</tt>, which is 128kb by default.
Reduce this as much as you can, but be warned that if this value
it) fails (cf. #MSG_HOST_FAILURE), then the task can be restarted
from the last checkpoint.\n
-Actually, such a thing does not exists in SimGrid either, but it's just
+Actually, such a thing does not exist in SimGrid either, but it's just
because we don't think it is fundamental and it may be done in the user code
at relatively low cost. You could for example use a watcher that
periodically get the remaining amount of things to do (using
\subsubsection faq_platform_example Where can I find SimGrid platform files?
-There is several little examples in the archive, in the examples/msg
+There are 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 much at hand right now.
\subsubsection faq_SURF_multicore Modeling multi-core resources
-There is currently no native support for multi-core or SMP machines in
-SimGrid. We are currently working on it, but coming up with the right
-model is very hard: Cores share caches and bus to access memory and
-thus interfere with each others. Memory contention is a crucial
-component of multi-core modeling.
-
-In the meanwhile, some user-level tricks can reveal sufficient for
-you. For example, you may model each core by a CPU and add some very
-high speed links between them. This complicates a bit the user code
-since you have to remember that when you assign something to a (real)
-host, it can be any of the (fake) hosts representing the cores of a
-given machine. For that, you can use the prop tag of the XML files as
-follows. Your code should then look at the ‘machine’ property
-associated with each workstation, and run parallel tasks over all
-cores of the machine.
-
+Since version 3.6 of simgrid we can specify the core number of a resource.
+To use this feature use tag 'host' with 'core' attribute.
\verbatim
- <host id="machine0/core0" power="91500E6">
- <prop id="machine" value="machine0"/>
- <prop id="core" value="0"/>
- </host>
- <host id="machine0/core1" power="91500E6">
- <prop id="machine" value="machine0"/>
- <prop id="core" value="1"/>
-</host>
-
-
+<?xml version='1.0'?>
+<!DOCTYPE platform SYSTEM "http://simgrid.gforge.inria.fr/simgrid.dtd">
+<platform version="3">
+ <AS id="AS0" routing="Full">
+ <host id="Tremblay" power="98095000" core="6"/>
+ </AS>
+</platform>
\endverbatim
+The specified computing power will be available to up to 6 sequential
+tasks without sharing. If more tasks are placed on this host, the
+resource will be shared accordingly. For example, if you schedule 12
+tasks on the host, each will get half of the computing power. Please
+note that although sound, this model were never scientifically
+assessed. Please keep this fact in mind when using it.
+
\subsubsection faq_SURF_dynamic Modeling dynamic resource availability
A nice feature of SimGrid is that it enables you to seamlessly have
\endverbatim
At time 0, our host will deliver 100 flop/s. At time 11.0, it will
-deliver only 50 flop/s until time 20.0 where it will will start
+deliver only 50 flop/s until time 20.0 where it will start
delivering 90 flop/s. Last at time 21.0 (20.0 plus the periodicity
1.0), we'll be back to the beginning and it will deliver 100 flop/s.
\verbatim
<route src="A" dst="B">
- <link:ctn id="1"/>
+ <link_ctn id="1"/>
</route>
<route src="B" dst="C">
- <link:ctn id="2"/>
+ <link_ctn id="2"/>
</route>
<route src="A" dst="C">
- <link:ctn id="3"/>
+ <link_ctn id="3"/>
</route>
\endverbatim
trivial, and that data do not following the shortest path in number of
hops on this graph. Another way to say it is that there is no implicit
in these routing descriptions. The system will only use the routes you
-declare (such as <route src="A" dst="C"><link:ctn
+declare (such as <route src="A" dst="C"><link_ctn
id="3"/></route>), without trying to build new routes by aggregating
the provided ones.
\verbatim
<route src="C" dst="A">
- <link:ctn id="2"/>
- <link:ctn id="1"/>
+ <link_ctn id="2"/>
+ <link_ctn id="1"/>
</route>
\endverbatim
- start "link" with ...
- end "link"
- start "route" with ...
- - start "link:ctn" with ...
- - end "link:ctn"
+ - start "link_ctn" with ...
+ - end "link_ctn"
- end "route"
- end "platform_description"
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_fullduplex Using Fullduplex
-
-Experimental fullduplex support is now available on the svn branch. In order to fullduple to work your platform must have two links for each pair
-of interconnected hosts, see an example here:
-\verbatim
- simgrid_svn_sources/exemples/msg/gtnets/fullduplex-p.xml
-\endverbatim
-
-Using fullduplex support ongoing and incoming communication flows are
-treated independently for most models. The exception is the LV08 model which
-adds 0.05 of usage on the opposite direction for each new created flow. This
-can be useful to simulate some important TCP phenomena such as ack compression.
-
-Running a fullduplex example:
-\verbatim
- cd simgrid_svn_sources/exemples/msg/gtnets
- ./gtnets fullduplex-p.xml fullduplex-d.xml --cfg=fullduplex:1
-\endverbatim
-
-
-
-
-
-\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>
-
-In order to enable gtnets with simgrid you have to give where is gtnets. (path to \<gtnets_path\>/lib and \<gtnets_path\>/include)
-
- \verbatim
- Since v3.4 (with cmake)
- cmake . -Dgtnets_path=/<userhome>/usr
-
- Until v3.4 (with autotools)
- ./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
- Since v3.4 (with cmake)
- cd simgrid
- make
- ctest -R gtnets
-
- Until v3.4 (with autotools)
- 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... To know the
-list of the currently implemented models, you should use the
---help-models command line option.
-
-\verbatim
-./masterslave_forwarder ../small_platform.xml deployment_masterslave.xml --help-models
-Long description of the workstation models accepted by this simulator:
- CLM03: Default workstation model, using LV08 and CM02 as network and CPU
- compound: Workstation model allowing you to use other network and CPU models
- ptask_L07: Workstation model with better parallel task modeling
-Long description of the CPU models accepted by this simulator:
- Cas01_fullupdate: CPU classical model time=size/power
- Cas01: Variation of Cas01_fullupdate with partial invalidation optimization of lmm system. Should produce the same values, only faster
- CpuTI: Variation of Cas01 with also trace integration. Should produce the same values, only faster if you use availability traces
-Long description of the network models accepted by this simulator:
- Constant: Simplistic network model where all communication take a constant time (one second)
- CM02: Realistic network model with lmm_solve and no correction factors
- LV08: Realistic network model with lmm_solve and these correction factors: latency*=10.4, bandwidth*=.92, S=8775
- Reno: Model using lagrange_solve instead of lmm_solve (experts only)
- Reno2: Model using lagrange_solve instead of lmm_solve (experts only)
- Vegas: Model using lagrange_solve instead of lmm_solve (experts only)
-\endverbatim
-
-\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 has instrumented 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, SimDAG and SMPI 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 tracing facilities is to give SimGrid users to possibility to
-classify MSG and SimDAG tasks by category, tracing 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>. Even if the user
-does not specify any category, the simulations can still be traced in terms
-of resource utilization by using a special parameter that is detailed below.
-
-\subsubsection faq_tracing_enabling Enabling using CMake
-
-With the sources of SimGrid, it is possible to enable the tracing
-using the parameter <b>-Denable_tracing=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 -Denable_tracing=ON .
-$ make
-\endverbatim
-
-\subsubsection faq_tracing_functions Tracing Functions
-
-\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. The color for the category that is being declared
-is random (use next function to specify a color).
-
-\li <b>\c TRACE_category_with_color (const char *category, const char *color)</b>: Same
-as TRACE_category, but let user specify a color encoded as a RGB-like string with
-three floats from 0 to 1. So, to specify a red color, the user can pass "1 0 0" as
-color parameter. A light-gray color can be specified using "0.7 0.7 0.7" as color.
-
-\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 MSG 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_sd_set_task_category (SD_task_t task, const char *category)</b>:
-This function should be called after the creation of a SimDAG 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_[host|link]_variable_declare (const char *variable)</b>:
-Declare a user variable that will be associated to host/link. 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 (for hosts), and so on.
-
-\li <b>\c TRACE_[host|link]_variable_[set|add|sub] (const char *[host|link], const char *variable, double value)</b>:
-Set the value of a given user variable for a given host/link. The value
-of this variable is always associated to the host/link. The host/link
-parameters should be its name as the one listed in the platform file.
-
-\li <b>\c TRACE_[host|link]_variable_[set|add|sub]_with_time (double time, const char *[host|link], const char *variable, double value)</b>:
-Same as TRACE_[host|link]_variable_[set|add|sub], but let user specify
-the time used to trace it. Users can specify a time that is not the
-simulated clock time as defined by the core simulator. This allows
-a fine-grain control of time definition, but should be used with
-caution since the trace can be inconsistent if resource utilization
-traces are also traced.
-
-\li <b>\c TRACE_link_srcdst_variable_[set|add|sub] (const char *src, const char *dst, const char *variable, double value)</b>:
-Same as TRACE_link_variable_[set|add|sub], but now users specify a source and
-destination hosts (as the names from the platform file). The tracing library
-will get the corresponding route that connects those two hosts (src and dst) and
-[set|add|sub] the value's variable for all the links of the route.
-
-\li <b>\c TRACE_link_srcdst_variable_[set|add|sub]_with_time (double time, const char *src, const char *dst, const char *variable, double value)</b>:
-Same as TRACE_link_srcdst_variable_[set|add|sub], but user specify a time different from the simulated time.
-
-\subsubsection faq_tracing_options Tracing configuration Options
-
-These are the options accepted by the tracing system of SimGrid:
-
-\li <b>\c
-tracing
-</b>:
- Safe switch. It activates (or deactivates) the tracing system.
- No other tracing options take effect if this one is not activated.
-
-\li <b>\c
-tracing/platform
-</b>:
- Register the simulation platform in the trace file.
-
-\li <b>\c
-tracing/onelink_only
-</b>:
- By default, the tracing system uses all routes in the platform file
- to re-create a "graph" of the platform and register it in the trace file.
- This option let the user tell the tracing system to use only the routes
- that are composed with just one link.
-
-\li <b>\c
-tracing/categorized
-</b>:
- It activates the categorized resource utilization tracing. It should
- be enabled if tracing categories are used by this simulator.
-
-\li <b>\c
-tracing/uncategorized
-</b>:
- It activates the uncategorized resource utilization tracing. Use it if
- this simulator do not use tracing categories and resource use have to be
- traced.
-
-\li <b>\c
-tracing/filename
-</b>:
- A file with this name will be created to register the simulation. The file
- is in the Paje format and can be analyzed using Triva or Paje visualization
- tools. More information can be found in these webpages:
- <a href="http://triva.gforge.inria.fr/">http://triva.gforge.inria.fr/</a>
- <a href="http://paje.sourceforge.net/">http://paje.sourceforge.net/</a>
-
-\li <b>\c
-tracing/smpi
-</b>:
- This option only has effect if this simulator is SMPI-based. Traces the MPI
- interface and generates a trace that can be analyzed using Gantt-like
- visualizations. Every MPI function (implemented by SMPI) is transformed in a
- state, and point-to-point communications can be analyzed with arrows.
-
-\li <b>\c
-tracing/smpi/group
-</b>:
- This option only has effect if this simulator is SMPI-based. The processes
- are grouped by the hosts where they were executed.
-
-\li <b>\c
-tracing/msg/task
-</b>:
- This option only has effect if this simulator is MSG-based. It traces the
- behavior of all categorized MSG tasks, grouping them by hosts.
-
-\li <b>\c
-tracing/msg/process
-</b>:
- This option only has effect if this simulator is MSG-based. It traces the
- behavior of all categorized MSG processes, grouping them by hosts. This option
- can be used to track process location if this simulator has process migration.
-
-
-\li <b>\c
-triva/categorized:graph_categorized.plist
-</b>:
- This option generates a graph configuration file for Triva considering
- categorized resource utilization.
-
-\li <b>\c
-triva/uncategorized:graph_uncategorized.plist
-</b>:
- This option generates a graph configuration file for Triva considering
- uncategorized resource utilization.
-
-\subsubsection faq_tracing_example Example of Instrumentation
-
-A simplified example using the tracing mandatory functions.
-
-\verbatim
-int main (int argc, char **argv)
-{
- MSG_global_init (&argc, &argv);
-
- //(... after deployment ...)
-
- //note that category declaration must be called after MSG_create_environment
- TRACE_category_with_color ("request", "1 0 0");
- TRACE_category_with_color ("computation", "0.3 1 0.4");
- TRACE_category ("finalize");
-
- 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();
- 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</i>. This file contains instructions to install
-the tool's dependencies in a Ubuntu/Debian Linux. The tool can also
-be compiled in MacOSes natively, check <i>INSTALL.mac</i> file.
-\verbatim
-$ svn checkout svn://scm.gforge.inria.fr/svn/triva
-$ cd triva
-$ cat INSTALL
-\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. We strongly recommend that you
-use the latest GNUstep packages, and not the packages available through apt-get
-in Ubuntu/Debian packaging systems. If you install GNUstep using the latest
-available packages, you can execute this command:
-\verbatim
-$ source /usr/GNUstep/System/Library/Makefiles/GNUstep.sh
-\endverbatim
-You should be able to see this output after the installation of triva:
-\verbatim
-$ ./Triva.app/Triva --help
-Usage: Triva [OPTIONS...] TRACE0 [TRACE1]
-Trace Analysis through Visualization
-
-TimeInterval
- --ti_frequency {double} Animation: frequency of updates
- --ti_hide Hide the TimeInterval window
- --ti_forward {double} Animation: value to move time-slice
- --ti_apply Apply the configuration
- --ti_update Update on slider change
- --ti_animate Start animation
- --ti_start {double} Start of time slice
- --ti_size {double} Size of time slice
-Triva
- --comparison Compare Trace Files (Experimental)
- --graph Configurable Graph
- --list Print Trace Type Hierarchy
- --hierarchy Export Trace Type Hierarchy (dot)
- --stat Trace Statistics and Memory Utilization
- --instances List All Trace Entities
- --linkview Link View (Experimental)
- --treemap Squarified Treemap
- --merge Merge Trace Files (Experimental)
- --check Check Trace File Integrity
-GraphConfiguration
- --gc_conf {file} Graph Configuration in Property List Format
- --gc_apply Apply the configuration
- --gc_hide Hide the GraphConfiguration window
-\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 = source;
- dst = destination;
-
- 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>source</em> and <em>destination</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 = source;
- dst = destination;
- 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 = source;
- dst = destination;
- 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.
-
-\subsection faq_modelchecking Model-Checking
-\subsubsection faq_modelchecking_howto How to use it
-To enable the experimental SimGrid model-checking support the program should
-be executed with the command line argument
-\verbatim
---cfg=model-check:1
-\endverbatim
-Properties are expressed as assertions using the function
-\verbatim
-void MC_assert(int prop);
-\endverbatim
-
-\subsection faq_binding_lua Lua Binding
-Most of Simgrid modules require a good level in C programming, since simgrid is used to be as standard C library.
- Sometime users prefer using some kind of « easy scripts » or a language easier to code with, for their works,
- which avoid dealing with C errors, and sometime an important gain of time.
-Besides Java Binding, Lua and Ruby bindings are available since version 3.4 of Simgrid
-for MSG Module, and we are currenlty working on bindings for other modules.
-
-
-\subsubsection faq_binding_lua_about What is lua ?
-Lua is a lightweight, reflective, imperative and functional programming language,
- designed as a scripting language with extensible semantics as a primary goal (see official web site <a href="http://www.lua.org">here</a>).
-\subsubsection faq_binding_lua_why Why lua ?
-Lua is a fast, portable and powerful script language, quite simple to use for developpers.
-it combines procedural features with powerful data description facilities,
- by using a simple, yet powerful, mechanism of tables.
-Lua has a relatively simple C API compared to other scripting languages,
-and accordingly it provides a robust, easy to use it.
-\subsubsection faq_binding_lua_simgrid How to use lua in Simgrid ?
-Actually, the use of lua in Simgrid is quite simple, you have just to follow the same steps as coding with C in Simgird :
- - Coding functions coresponding to each process
- - loading the platforme/deployment XML file that describe the environment of simulation
- - and … Running the Simulation.
-
-\dontinclude lua/masterslave/master.lua
-\subsubsection faq_binding_lua_example_master_slave Master/Slave Example
-
- \li Master Code
- \until end_of_master
-we mainly use simgrid.Task.new(task_name,computation_size,communication_size) to create our MSG Task,
- then simgrid.Task.send(task,alias) to send it.
-we use also simgrid.Task.name(task), to get the task's name.
-
-\dontinclude lua/masterslave/slave.lua
-\li Slave Code
-\until end_of_slave
-Here, we see the use of simgrid.Task.recv(alias) to receive a task with a specific alias,
-this function return directly the task recevied.
-
-\dontinclude lua/masterslave/master_slave.lua
-\li Set Environmenet and run application
-\until simgrid.clean()
-
-\subsubsection faq_binding_lua_example_data Exchanging Data
-You can also exchange data between Process using lua. for that, you have to deal with lua task as a table,
-since lua is based itself on a mechanism of tables,
-so you can exchange any kind of data (tables, matrix, strings,…) between process via tasks.
-
-\li Sender process
-\verbatim
- task = simgrid.Task.new("data_task",task_comp,task_comm);
- task['matrix'] = my_matrix;
- task['table'] = my_table;
- task['message'] = "Hello from (Lua || Simgrid ) !! "
- …
- simgrid.Task.send(task,alias)
-\endverbatim
- After creating task, we associate to it various kind of data with a specific key (string in this case)
- to distinguish between data variables. The receiver will use this key to access easily to datas.
-
-
-\li Receiver processe
-\verbatim
- task = simgrid.Task.recv(alias);
- sender_matrix = task['matrix'];
- sender_table = task['table'];
- sender_message = task['message']
- ...
-\endverbatim
- Note that in lua, both sender and receiver share the same lua task.
- So that the receiver could joint data directly on the received task without sending it back.
- You can find a complet example (matrix multiplication case) in the file example/lua/mult_matrix.lua.
-
-
-\subsubsection faq_binding_lua_example_bypass Bypass XML
- maybe you wonder if there is a way to bypass the XML files,
- and describe your platform directly from the code, with lua bindings it's Possible !! how ?
- We provide some additional (tricky?) functions in lua that allows you to set up your own platform without using the XML files
- ( this can be useful for large platforms, so a simple for loop will avoid you to deal with an annoying XML File ;) )
-
-
-\li set Routing mode
-\verbatim
- simgrid.AS.new{id="AS0",mode="Full"};
-\endverbatim
-
-\li set Hosts
-\verbatim
- simgrid.Host.new{id="Tremblay",power=98095000};
- simgrid.Host.new{id="Jupiter",power=76296000};
- simgrid.Host.new{id="Fafard",power=76296000};
- simgrid.Host.new{id="Ginette",power=48492000};
- simgrid.Host.new{id="Bourassa",power=48492000};
-\endverbatim
- we use simgrid.Host.new{id=id_host,power=power_host} to instanciate our hosts.
-
-\li set Links
-\verbatim
- for i=0,11 do
- simgrid.Link.new{id=i,bandwidth=252750+ i*768,latency=0.000270544+i*0.087}; -- some crazy values ;)
- end
-\endverbatim
- we used simgrid.Link.new{id=link_id,bandwidth=bw,latency=lat} with a simple for loop to create all links we need (much easier than XML hein ?)
-
-\li set Routes
-\verbatim
--- simgrid.Route.new(src_id,des_id,links_nb,links_list)
- simgrid.Route.new("Tremblay","Jupiter",1,{"1"});
- simgrid.Route.new("Tremblay","Fafard",6,{"0","1","2","3","4","8"});
- simgrid.Route.new("Tremblay","Ginette",3,{"3","4","5"});
- simgrid.Route.new("Tremblay","Bourassa",7,{"0","1","3","2","4","6","7"});
-
- simgrid.Route.new("Jupiter","Tremblay",1,{"1"});
- simgrid.Route.new("Jupiter","Fafard",7,{"0","1","2","3","4","8","9"});
- simgrid.Route.new("Jupiter","Ginette",4,{"3","4","5","9"});
- simgrid.Route.new("Jupiter","Bourassa",8,{"0","1","2","3","4","6","7","9"});
- ...
-\endverbatim
- for each host you have to specify which route to choose to access to the rest of hosts connected in the grid.
-
-\li Save platform
-\verbatim
- simgrid.register_platform();
-\endverbatim
-Don't forget to register your platform, that SURF callbacks starts their work ;)
-
-\li set application
-\verbatim
- simgrid.Host.setFunction("Tremblay","Master",4,{"20","550000000","1000000","4"});
- simgrid.Host.setFunction("Bourassa","Slave",1,{"0"});
- simgrid.Host.setFunction("Jupiter","Slave",1,{"1"});
- simgrid.Host.setFunction("Fafard","Slave",1,{"2"});
- simgrid.Host.setFunction("Ginette","Slave",1,{"3"});
-\endverbatim
- you don't need to use a deployment XML file, thanks to simgrid.Host.setFunction(host_id,function,args_number,args_list)
- you can associate functions for each host with arguments if needed .
-
-\li
-\verbatim
- simgrid.register_application();
-\endverbatim
-Yes, Here too you have to resgiter your application before running the simulation.
-
-the full example is distributed in the file examples/lua/master_slave_bypass.lua
-
-\subsection faq_binding_ruby Ruby Binding
-
-
-\subsubsection faq_binding_ruby_simgrid Use Ruby in Simgrid
-Since v3.4, the use of <a href="http://ruby-lang.org">ruby</a> in simgrid is available for the MSG Module.
-you can find almost all MSG functionalities in Ruby code, that allows you to set up your environment, manage tasks between hosts and run the simulation.
-
-\subsubsection faq_binding_ruby_example Master/Slave Ruby Application
-for each process method(master and slave in this example), you have to associate a ruby class, that should inherit from <i>MSG::Process</i> ruby class,
- with a 'main' function that describe the behaviour of the process during the simulation.
-\li required stuff
-\verbatim
-require 'simgrid'
-include MSG
-\endverbatim
-
-\li Master code
-\verbatim
-class Master < MSG::Process
- # main : that function that will be executed when running simulation
-
- def main(args) # args is an array containing arguments for function master
- size = args.size
- for i in 0..size-1
- MSG::info("args["+String(i)+"]="+args[i])
- end
-
- raise "Master needs 3 arguments" if size < 3
- numberOfTask = Integer(args[0])
- taskComputeSize = Float(args[1])
- taskCommunicationSize = Float(args[2])
- slaveCount = Integer(args[3])
-
- # Creates and sends the tasks
- for i in 0..numberOfTask-1
- task = Task.new("Task_"+ i.to_s, taskComputeSize , taskCommunicationSize);
- mailbox = "slave " + (i%slaveCount).to_s
- MSG::info("Master Sending "+ task.name + " to " + mailbox + " with Comput Size " +
- task.compSize.to_s)
- task.send(mailbox)
- MSG::info("Master Done Sending " + task.name + " to " + mailbox)
- end
-
- # Sending Finalize MSG::Tasks
- MSG::info("Master: All tasks have been dispatched. Let's tell everybody the computation is over.")
- for i in 0..slaveCount-1
- mailbox = "slave " + i.to_s
- finalize_task = Task.new("finalize",0,0)
- finalize_task.send(mailbox)
- end
- MSG::info("Master : Everything's Done")
- end
-end
-\endverbatim
-
-
-the class MSG::Task contains methods that allows the management of the native MSG tasks.
-in master ruby code we used :
- - <i>MSG::Task.new(task_name,compute_size,communication_size)</i> : to instanciate a new task.
- - <i>MSG::Task.send(mailbox)</i> : to send the task via a mailbox alias.
- - <i>MSG::Task.name</i> : to get the task's name.
-
-\li Slave code
-\verbatim
-class Slave < MSG::Process
-
- def main(args)
- mailbox = "slave " + args[0]
- for i in 0..args.size-1
- MSG::debug("args["+String(i)+"]="+args[i])
- end
-
- while true
- MSG::info("Slave '"+ mailbox +"' waiting for new task");
- task = Task.receive(mailbox)
- if (task.name == "finalize")
- break
- end
- task.execute
- MSG::info("Slave '" + mailbox + "' done executing task "+ task.name + ".")
- end
- MSG::info("I'm done, see you")
- end
-end
-\enverbatim
-to receive a task, we use the method <i>MSG::Task.receive(mailbox)</i> that return a MSG:Task object (received task).
-
-\li Main chunk
-
-\verbatim
-require 'simgrid'
-include MSG
-(...)
-
-if (ARGV.length == 2)
- MSG.createEnvironment(ARGV[0])
- MSG.deployApplication(ARGV[1])
-
-else
-
- MSG.createEnvironment("platform.xml")
- MSG.deployApplication("deploy.xml")
-end
-MSG.run
-puts "Simulation time : " + MSG.getClock.to_s
-MSG.exit
-\endverbatim
-
-- <i>MSG.createEnvironment(platform_file)</i> : set up the environment
-- <i>MSG.deployApplication(deployment_file)</i> : load the deployment file description.
-- <i>MSG.run</i> : run the simulation
-
-\subsubsection faq_binding_ruby_data Exchanging data
-ruby bindings provides two ways to exchange data between ruby processes.
-\li MSG::Task.join & MSG::Task.data <br/>
-
- the MSG::Task class contains 2 methods that allows a data exchange between 2 process.
-
- -<i>MSG::Task.join</i> : makes possible to join any kind of ruby data within a task.
- \verbatim
- ...
- myTable = Array.new
- myTable <<1<<-2<<45<<67<<87<<76<<89<<56<<78<<3<<-4<<99
- # Creates and send Task With the Table inside
- task = MSG::Task.new("quicksort_task",taskComputeSize, taskCommunicationSize);
- task.join(myTable);
- ...
- task.send(mailbox);
- \endverbatim
- -<i>MSG::Task.data</i> : to access to the data contained into the task.
- \verbatim
- ...
- task = MSG::Task.receive(recv_mailbox.to_s)
- table = task.data
- quicksort(table,0,table.size-1)
- ...
- \endverbatim
-you can find a complet example illustrating the use of those methods in file /example/ruby/Quicksort.rb
-
-\li inheritence
-
- another 'object-oriented' way to do it, is to make your own 'task' class that inherit from MSG::Task ,
- and contains data you want to deal with, the only 'tricky' thing is that "the initializer" method has no effect !
-
- the use of some getter/setter methods would be the simple way to manage your data :)
- \verbatim
-class PingPongTask < MSG::Task
- # The initialize method has no effect
- @time
- def setTime(t)
- @time = t
- end
- def getTime()
- return @time
- end
-end
- \endverbatim
- you can find an example of use in file example/ruby/PingPong.rb
-
\section faq_troubleshooting Troubleshooting
\subsection faq_trouble_lib_compil SimGrid compilation and installation problems
http://www.chiark.greenend.org.uk/~sgtatham/bugs.html (it is not SimGrid
specific at all, but it's full of good advices).
-\author Arnaud Legrand (arnaud.legrand::imag.fr)
-\author Martin Quinson (martin.quinson::loria.fr)
-
+\author Da SimGrid team <simgrid-devel@lists.gforge.inria.fr>
*/
******************************************************************
-\subsection faq_crosscompile Cross-compiling a Windows DLL of SimGrid from linux
+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
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.
-
-
