+\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