doc/options.doc

   1 /*! \page options Simgrid options and configurations
   2
   3 \htmlinclude .options.doc.toc
   4
   5 \section options_simgrid_configuration Changing SimGrid's behavior
   6
   7 A number of options can be given at runtime to change the default
   8 SimGrid behavior. In particular, you can change the default cpu and
   9 network models...
  10
  11 \subsection options_simgrid_configuration_fullduplex Using Fullduplex
  12
  13 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
  14 of interconnected hosts, see an example here:
  15 \verbatim
  16         simgrid_svn_sources/exemples/msg/gtnets/fullduplex-p.xml
  17 \endverbatim
  18
  19 Using fullduplex support ongoing and incoming communication flows are
  20 treated independently for most models. The exception is the LV08 model which
  21 adds 0.05 of usage on the opposite direction for each new created flow. This
  22 can be useful to simulate some important TCP phenomena such as ack compression.
  23
  24 Running a fullduplex example:
  25 \verbatim
  26         cd simgrid_svn_sources/exemples/msg/gtnets
  27         ./gtnets fullduplex-p.xml fullduplex-d.xml --cfg=fullduplex:1
  28 \endverbatim
  29
  30 \subsection options_simgrid_configuration_alternate_network Using alternative flow models
  31
  32 The default simgrid network model uses a max-min based approach as
  33 explained in the research report
  34 <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>.
  35 Other models have been proposed and implemented since then (see for example
  36 <a href="http://mescal.imag.fr/membres/arnaud.legrand/articles/simutools09.pdf">Accuracy Study and Improvement of Network Simulation in the SimGrid Framework</a>)
  37 and can be activated at runtime. For example:
  38 \verbatim
  39 ./mycode platform.xml deployment.xml --cfg=workstation/model:compound --cfg=network/model:LV08 -cfg=cpu/model:Cas01
  40 \endverbatim
  41
  42 Possible models for the network are currently "Constant", "CM02",
  43 "LegrandVelho", "GTNets", Reno", "Reno2", "Vegas". Others will
  44 probably be added in the future and many of the previous ones are
  45 experimental and are likely to disappear without notice... To know the
  46 list of the currently  implemented models, you should use the
  47 --help-models command line option.
  48
  49 \verbatim
  50 ./masterslave_forwarder ../small_platform.xml deployment_masterslave.xml  --help-models
  51 Long description of the workstation models accepted by this simulator:
  52   CLM03: Default workstation model, using LV08 and CM02 as network and CPU
  53   compound: Workstation model allowing you to use other network and CPU models
  54   ptask_L07: Workstation model with better parallel task modeling
  55 Long description of the CPU models accepted by this simulator:
  56   Cas01_fullupdate: CPU classical model time=size/power
  57   Cas01: Variation of Cas01_fullupdate with partial invalidation optimization of lmm system. Should produce the same values, only faster
  58   CpuTI: Variation of Cas01 with also trace integration. Should produce the same values, only faster if you use availability traces
  59 Long description of the network models accepted by this simulator:
  60   Constant: Simplistic network model where all communication take a constant time (one second)
  61   CM02: Realistic network model with lmm_solve and no correction factors
  62   LV08: Realistic network model with lmm_solve and these correction factors: latency*=10.4, bandwidth*=.92, S=8775
  63   Reno: Model using lagrange_solve instead of lmm_solve (experts only)
  64   Reno2: Model using lagrange_solve instead of lmm_solve (experts only)
  65   Vegas: Model using lagrange_solve instead of lmm_solve (experts only)
  66 \endverbatim
  67
  68 \section options_tracing Tracing Simulations for Visualization
  69
  70 The trace visualization is widely used to observe and understand the behavior
  71 of parallel applications and distributed algorithms. Usually, this is done in a
  72 two-step fashion: the user instruments the application and the traces are
  73 analyzed after the end of the execution. The visualization itself can highlights
  74 unexpected behaviors, bottlenecks and sometimes can be used to correct
  75 distributed algorithms. The SimGrid team has instrumented the library
  76 in order to let users trace their simulations and analyze them. This part of the
  77 user manual explains how the tracing-related features can be enabled and used
  78 during the development of simulators using the SimGrid library.
  79
  80 \subsection options_tracing_howitworks How it works
  81
  82 For now, the SimGrid library is instrumented so users can trace the <b>platform
  83 utilization</b> using the MSG, SimDAG and SMPI interface. This means that the tracing will
  84 register how much power is used for each host and how much bandwidth is used for
  85 each link of the platform. The idea with this type of tracing is to observe the
  86 overall view of resources utilization in the first place, especially the
  87 identification of bottlenecks, load-balancing among hosts, and so on.
  88
  89 The idea of the tracing facilities is to give SimGrid users to possibility to
  90 classify MSG and SimDAG tasks by category, tracing the platform utilization
  91 (hosts and links) for each of the categories. For that,
  92 the tracing interface enables the declaration of categories and a function to
  93 mark a task with a previously declared category. <em>The tasks that are not
  94 classified according to a category are not traced</em>. Even if the user
  95 does not specify any category, the simulations can still be traced in terms
  96 of resource utilization by using a special parameter that is detailed below.
  97
  98 \subsection options_tracing_enabling Enabling using CMake
  99
 100 With the sources of SimGrid, it is possible to enable the tracing
 101 using the parameter <b>-Denable_tracing=ON</b> when the cmake is executed.
 102 The section \ref options_tracing_functions describes all the functions available
 103 when this Cmake options is activated. These functions will have no effect
 104 if SimGrid is configured without this option (they are wiped-out by the
 105 C-preprocessor).
 106
 107 \verbatim
 108 $ cmake -Denable_tracing=ON .
 109 $ make
 110 \endverbatim
 111
 112 \subsection options_tracing_functions Tracing Functions
 113
 114 \li <b>\c TRACE_category (const char *category)</b>: This function should be used
 115 to define a user category. The category can be used to differentiate the tasks
 116 that are created during the simulation (for example, tasks from server1,
 117 server2, or request tasks, computation tasks, communication tasks).
 118 All resource utilization (host power and link bandwidth) will be
 119 classified according to the task category. Tasks that do not belong to a
 120 category are not traced. The color for the category that is being declared
 121 is random (use next function to specify a color).
 122
 123 \li <b>\c TRACE_category_with_color (const char *category, const char *color)</b>: Same
 124 as TRACE_category, but let user specify a color encoded as a RGB-like string with
 125 three floats from 0 to 1. So, to specify a red color, the user can pass "1 0 0" as
 126 color parameter. A light-gray color can be specified using "0.7 0.7 0.7" as color.
 127
 128 \li <b>\c TRACE_msg_set_task_category (m_task_t task, const char *category)</b>:
 129 This function should be called after the creation of a MSG task, to define the
 130 category of that task. The first parameter \c task must contain a task that was
 131 created with the function \c MSG_task_create. The second parameter
 132 \c category must contain a category that was previously defined by the function
 133 \c TRACE_category.
 134
 135 \li <b>\c TRACE_sd_set_task_category (SD_task_t task, const char *category)</b>:
 136 This function should be called after the creation of a SimDAG task, to define the
 137 category of that task. The first parameter \c task must contain a task that was
 138 created with the function \c MSG_task_create. The second parameter
 139 \c category must contain a category that was previously defined by the function
 140 \c TRACE_category.
 141
 142 \li <b>\c TRACE_[host|link]_variable_declare (const char *variable)</b>:
 143 Declare a user variable that will be associated to host/link. A variable can
 144 be used to trace user variables such as the number of tasks in a server,
 145 the number of clients in an application (for hosts), and so on.
 146
 147 \li <b>\c TRACE_[host|link]_variable_[set|add|sub] (const char *[host|link], const char *variable, double value)</b>:
 148 Set the value of a given user variable for a given host/link. The value
 149 of this variable is always associated to the host/link. The host/link
 150 parameters should be its name as the one listed in the platform file.
 151
 152 \li <b>\c TRACE_[host|link]_variable_[set|add|sub]_with_time (double time, const char *[host|link], const char *variable, double value)</b>:
 153 Same as TRACE_[host|link]_variable_[set|add|sub], but let user specify
 154 the time used to trace it. Users can specify a time that is not the
 155 simulated clock time as defined by the core simulator. This allows
 156 a fine-grain control of time definition, but should be used with
 157 caution since the trace can be inconsistent if resource utilization
 158 traces are also traced.
 159
 160 \li <b>\c TRACE_link_srcdst_variable_[set|add|sub] (const char *src, const char *dst, const char *variable, double value)</b>:
 161 Same as TRACE_link_variable_[set|add|sub], but now users specify a source and
 162 destination hosts (as the names from the platform file). The tracing library
 163 will get the corresponding route that connects those two hosts (src and dst) and
 164 [set|add|sub] the value's variable for all the links of the route.
 165
 166 \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>:
 167 Same as TRACE_link_srcdst_variable_[set|add|sub], but user specify a time different from the simulated time.
 168
 169 \subsection options_tracing_options Tracing configuration Options
 170
 171 These are the options accepted by the tracing system of SimGrid:
 172
 173 \li <b>\c
 174 tracing
 175 </b>:
 176   Safe switch. It activates (or deactivates) the tracing system.
 177   No other tracing options take effect if this one is not activated.
 178
 179 \li <b>\c
 180 tracing/platform
 181 </b>:
 182   Register the simulation platform in the trace file.
 183
 184 \li <b>\c
 185 tracing/onelink_only
 186 </b>:
 187   By default, the tracing system uses all routes in the platform file
 188   to re-create a "graph" of the platform and register it in the trace file.
 189   This option let the user tell the tracing system to use only the routes
 190   that are composed with just one link.
 191
 192 \li <b>\c
 193 tracing/categorized
 194 </b>:
 195   It activates the categorized resource utilization tracing. It should
 196   be enabled if tracing categories are used by this simulator.
 197
 198 \li <b>\c
 199 tracing/uncategorized
 200 </b>:
 201   It activates the uncategorized resource utilization tracing. Use it if
 202   this simulator do not use tracing categories and resource use have to be
 203   traced.
 204
 205 \li <b>\c
 206 tracing/filename
 207 </b>:
 208   A file with this name will be created to register the simulation. The file
 209   is in the Paje format and can be analyzed using Triva or Paje visualization
 210   tools. More information can be found in these webpages:
 211      <a href="http://triva.gforge.inria.fr/">http://triva.gforge.inria.fr/</a>
 212      <a href="http://paje.sourceforge.net/">http://paje.sourceforge.net/</a>
 213
 214 \li <b>\c
 215 tracing/smpi
 216 </b>:
 217   This option only has effect if this simulator is SMPI-based. Traces the MPI
 218   interface and generates a trace that can be analyzed using Gantt-like
 219   visualizations. Every MPI function (implemented by SMPI) is transformed in a
 220   state, and point-to-point communications can be analyzed with arrows.
 221
 222 \li <b>\c
 223 tracing/smpi/group
 224 </b>:
 225   This option only has effect if this simulator is SMPI-based. The processes
 226   are grouped by the hosts where they were executed.
 227
 228 \li <b>\c
 229 tracing/msg/task
 230 </b>:
 231   This option only has effect if this simulator is MSG-based. It traces the
 232   behavior of all categorized MSG tasks, grouping them by hosts.
 233
 234 \li <b>\c
 235 tracing/msg/process
 236 </b>:
 237   This option only has effect if this simulator is MSG-based. It traces the
 238   behavior of all categorized MSG processes, grouping them by hosts. This option
 239   can be used to track process location if this simulator has process migration.
 240
 241
 242 \li <b>\c
 243 triva/categorized:graph_categorized.plist
 244 </b>:
 245   This option generates a graph configuration file for Triva considering
 246   categorized resource utilization.
 247
 248 \li <b>\c
 249 triva/uncategorized:graph_uncategorized.plist
 250 </b>:
 251   This option generates a graph configuration file for Triva considering
 252   uncategorized resource utilization.
 253
 254 \subsection options_tracing_example Example of Instrumentation
 255
 256 A simplified example using the tracing mandatory functions.
 257
 258 \verbatim
 259 int main (int argc, char **argv)
 260 {
 261   MSG_global_init (&argc, &argv);
 262
 263   //(... after deployment ...)
 264
 265   //note that category declaration must be called after MSG_create_environment
 266   TRACE_category_with_color ("request", "1 0 0");
 267   TRACE_category_with_color ("computation", "0.3 1 0.4");
 268   TRACE_category ("finalize");
 269
 270   m_task_t req1 = MSG_task_create("1st_request_task", 10, 10, NULL);
 271   m_task_t req2 = MSG_task_create("2nd_request_task", 10, 10, NULL);
 272   m_task_t req3 = MSG_task_create("3rd_request_task", 10, 10, NULL);
 273   m_task_t req4 = MSG_task_create("4th_request_task", 10, 10, NULL);
 274   TRACE_msg_set_task_category (req1, "request");
 275   TRACE_msg_set_task_category (req2, "request");
 276   TRACE_msg_set_task_category (req3, "request");
 277   TRACE_msg_set_task_category (req4, "request");
 278
 279   m_task_t comp = MSG_task_create ("comp_task", 100, 100, NULL);
 280   TRACE_msg_set_task_category (comp, "computation");
 281
 282   m_task_t finalize = MSG_task_create ("finalize", 0, 0, NULL);
 283   TRACE_msg_set_task_category (finalize, "finalize");
 284
 285   //(...)
 286
 287   MSG_clean();
 288   return 0;
 289 }
 290 \endverbatim
 291
 292 \subsection options_tracing_analyzing Analyzing the SimGrid Traces
 293
 294 The SimGrid library, during an instrumented simulation, creates a trace file in
 295 the Paje file format that contains the platform utilization for the simulation
 296 that was executed. The visualization analysis of this file is performed with the
 297 visualization tool <a href="http://triva.gforge.inria.fr">Triva</a>, with
 298 special configurations tunned to SimGrid needs. This part of the documentation
 299 explains how to configure and use Triva to analyse a SimGrid trace file.
 300
 301 - <b>Installing Triva</b>: the tool is available in the INRIAGforge,
 302 at <a href="http://triva.gforge.inria.fr">http://triva.gforge.inria.fr</a>.
 303 Use the following command to get the sources, and then check the file
 304 <i>INSTALL</i>. This file contains instructions to install
 305 the tool's dependencies in a Ubuntu/Debian Linux. The tool can also
 306 be compiled in MacOSes natively, check <i>INSTALL.mac</i> file.
 307 \verbatim
 308 $ svn checkout svn://scm.gforge.inria.fr/svn/triva
 309 $ cd triva
 310 $ cat INSTALL
 311 \endverbatim
 312
 313 - <b>Executing Triva</b>: a binary called <i>Triva</i> is available after the
 314   installation (you can execute it passing <em>--help</em> to check its
 315 options). If the triva binary is not available after following the
 316 installation instructions, you may want to execute the following command to
 317 initialize the GNUstep environment variables. We strongly recommend that you
 318 use the latest GNUstep packages, and not the packages available through apt-get
 319 in Ubuntu/Debian packaging systems. If you install GNUstep using the latest
 320 available packages, you can execute this command:
 321 \verbatim
 322 $ source /usr/GNUstep/System/Library/Makefiles/GNUstep.sh
 323 \endverbatim
 324 You should be able to see this output after the installation of triva:
 325 \verbatim
 326 $ ./Triva.app/Triva --help
 327 Usage: Triva [OPTIONS...] TRACE0 [TRACE1]
 328 Trace Analysis through Visualization
 329
 330 TimeInterval
 331     --ti_frequency {double}    Animation: frequency of updates
 332     --ti_hide                  Hide the TimeInterval window
 333     --ti_forward {double}      Animation: value to move time-slice
 334     --ti_apply                 Apply the configuration
 335     --ti_update                Update on slider change
 336     --ti_animate               Start animation
 337     --ti_start {double}        Start of time slice
 338     --ti_size {double}         Size of time slice
 339 Triva
 340     --comparison               Compare Trace Files (Experimental)
 341     --graph                    Configurable Graph
 342     --list                     Print Trace Type Hierarchy
 343     --hierarchy                Export Trace Type Hierarchy (dot)
 344     --stat                     Trace Statistics and Memory Utilization
 345     --instances                List All Trace Entities
 346     --linkview                 Link View (Experimental)
 347     --treemap                  Squarified Treemap
 348     --merge                    Merge Trace Files (Experimental)
 349     --check                    Check Trace File Integrity
 350 GraphConfiguration
 351     --gc_conf {file}           Graph Configuration in Property List Format
 352     --gc_apply                 Apply the configuration
 353     --gc_hide                  Hide the GraphConfiguration window
 354 \endverbatim
 355 Triva expects that the user choose one of the available options
 356 (currently <em>--graph</em> or <em>--treemap</em> for a visualization analysis)
 357 and the trace file from the simulation.
 358
 359 - <b>Understanding Triva - time-slice</b>: the analysis of a trace file using
 360   the tool always takes into account the concept of the <em>time-slice</em>.
 361 This concept means that what is being visualized in the screen is always
 362 calculated considering a specific time frame, with its beggining and end
 363 timestamp. The time-slice is configured by the user and can be changed
 364 dynamically through the window called <em>Time Interval</em> that is opened
 365 whenever a trace file is being analyzed. The next figure depicts the time-slice
 366 configuration window.
 367 In the top of the window, in the space named <i>Trace Time</i>,
 368 the two fields show the beggining of the trace (which usually starts in 0) and
 369 the end (that depends on the time simulated by SimGrid). The middle of the
 370 window, in the square named <i>Time Slice Configuration</i>, contains the
 371 aspects related to the time-slice, including its <i>start</i> and its
 372 <i>size</i>. The gray rectangle in the bottom of this part indicates the
 373 <i>current time-slice</i> that is considered for the drawings. If the checkbox
 374 <i>Update Drawings on Sliders Change</i> is not selected, the button
 375 <i>Apply</i> must be clicked in order to inform triva that the
 376 new time-slice must be considered. The bottom part of the window, in the space
 377 indicated by the square <i>Time Slice Animation</i> can be used to advance
 378 the time-frame automatically. The user configures the amount of time that the
 379 time-frame will forward and how frequent this update will happen. Once this is
 380 configured, the user clicks the <i>Play</i> button in order to see the dynamic
 381 changes on the drawings.
 382 <center>
 383 \htmlonly
 384 <a href="triva-time_interval.png" border=0><img src="triva-time_interval.png" width="50%" border=0></a>
 385 \endhtmlonly
 386 </center>
 387 <b>Remarks:</b> when the trace has too many hosts or links, the computation to
 388 take into account a new time-slice can be expensive. When this happens, the
 389 <i>Frequency</i> parameter, but also updates caused by change on configurations
 390 when the checkbox <i>Update Drawings on Sliders
 391 Change</i> is selected will not be followed.
 392
 393 - <b>Understanding Triva - graph</b>: this part of the documention explains how
 394   to analyze the traces using the graph view of Triva, when the user executes
 395 the tool passing <em>--graph</em> as parameter. Triva opens three windows when
 396 this parameter is used: the <i>Time Interval</i> window (previously described),
 397 the <i>Graph Representation</i> window, and the <em>Graph Configuration</em>
 398 window. The Graph Representation is the window where drawings take place.
 399 Initially, it is completely white waiting for a proper graph configuration input
 400 by the user. We start the description of this type of analysis by describing the
 401 <i>Graph Configuration</i> window (depicted below). By using a particular
 402 configuration, triva
 403 can be used to customize the graph drawing according to
 404 the SimGrid trace that was created with user-specific categories. Before delving
 405 into the details of this customization, let us first explain the major parts of
 406 the graph configuration window. The buttons located in the top-right corner can
 407 be used to delete, copy and create a new configuration. The checkbox in the
 408 top-middle part of the window indicates if the configuration typed in the
 409 textfield is syntactically correct (we are using the non-XML
 410 <a href="http://en.wikipedia.org/wiki/Property_list">Property List Format</a> to
 411 describe the configuration). The pop-up button located on the top-left corner
 412 indicates the selected configuration (the user can have multiple graph
 413 configurations). The bottom-left text field contains the name of the current
 414 configuration (updates on this field must be followed by typing enter on the
 415 keyboard to take into account the name change). The bottom-right <em>Apply</em>
 416 button activates the current configuration, resulting on an update on the graph
 417 drawings.
 418 <center>
 419 \htmlonly
 420 <a href="triva-graph_configuration.png" border=0><img src="triva-graph_configuration.png" width="50%" border=0></a>
 421 \endhtmlonly
 422 </center>
 423 <b>Basic SimGrid Configuration</b>: The figure shows in the big textfield the
 424 basic configuration that should be used during the analysis of a SimGrid trace
 425 file. The basic logic of the configuration is as follows:
 426 \verbatim
 427 {
 428   node = (HOST);
 429   edge = (LINK);
 430 \endverbatim
 431 The nodes of the graph will be created based on the <i>node</i> parameter, which
 432 in this case is the different <em>"HOST"</em>s of the platform
 433 used to simulate. The <i>edge</i> parameter indicates that the edges of the
 434 graph will be created based on the <em>"LINK"</em>s of the platform. After the
 435 definition of these two parameters, the configuration must detail how
 436 <em>HOST</em>s and <em>LINK</em>s should be drawn. For that, the configuration
 437 must have an entry for each of the types used. For <em>HOST</em>, as basic
 438 configuration, we have:
 439 \verbatim
 440   HOST = {
 441     size = power;
 442     scale = global;
 443   };
 444 \endverbatim
 445 The parameter <em>size</em> indicates which variable from the trace file will be
 446 used to define the size of the node HOST in the visualization. If the simulation
 447 was executed with availability traces, the size of the nodes will be changed
 448 according to these traces. The parameter <em>scale</em> indicates if the value
 449 of the variable is <em>global</em> or <em>local</em>. If it is global, the value
 450 will be relative to the power of all other hosts, if it is local, the value will
 451 be relative locally.
 452 For <em>LINK</em> we have:
 453 \verbatim
 454   LINK = {
 455     src = source;
 456     dst = destination;
 457
 458     size = bandwidth;
 459     scale = global;
 460   };
 461 \endverbatim
 462 For the types specified in the <em>edge</em> parameter (such as <em>LINK</em>),
 463 the configuration must contain two additional parameters: <em>src</em> and
 464 <em>dst</em> that are used to properly identify which nodes this edge is
 465 connecting. The values <em>source</em> and <em>destination</em> are always present
 466 in the SimGrid trace file and should not be changed in the configuration. The
 467 parameter <em>size</em> for the LINK, in this case, is configured as the
 468 variable <em>bandwidth</em>, with a <em>global</em> scale. The scale meaning
 469 here is exactly the same used for nodes. The last parameter is the GraphViz
 470 algorithm used to calculate the position of the nodes in the graph
 471 representation.
 472 \verbatim
 473   graphviz-algorithm = neato;
 474 }
 475 \endverbatim
 476 <b>Customizing the Graph Representation</b>: triva is capable to handle
 477 a customized graph representation based on the variables present in the trace
 478 file. In the case of SimGrid, every time a category is created for tasks, two
 479 variables in the trace file are defined: one to indicate node utilization (how
 480 much power was used by that task category), and another to indicate link
 481 utilization (how much bandwidth was used by that category). For instance, if the
 482 user declares a category named <i>request</i>, there will be variables named
 483 <b>p</b><i>request</i> and a <b>b</b><i>request</i> (<b>p</b> for power and
 484 <b>b</b> for bandwidth). It is important to notice that the variable
 485 <i>prequest</i> in this case is only available for HOST, and
 486 <i>brequest</i> is only available for LINK. <b>Example</b>: suppose there are
 487 two categories for tasks: request and compute. To create a customized graph
 488 representation with a proportional separation of host and link utilization, use
 489 as configuration for HOST and LINK this:
 490 \verbatim
 491   HOST = {
 492     size = power;
 493     scale = global;
 494
 495     sep_host = {
 496       type = separation;
 497       size = power;
 498       values = (prequest, pcomputation);
 499     };
 500   };
 501
 502   LINK = {
 503     src = source;
 504     dst = destination;
 505     size = bandwidth;
 506     scale = global;
 507
 508     sep_link = {
 509       type = separation;
 510       size = bandwidth;
 511       values = (brequest, bcomputation);
 512     };
 513   };
 514 \endverbatim
 515 Where <i>sep_host</i> contains a composition of type <i>separation</i> where
 516 its max size is the <i>power</i> of the host and the variables <i>prequest</i>
 517 and <i>pcomputation</i> are drawn proportionally to the size of the HOST. And
 518 <i>sep_link</i> is also a separation where max is defined as the
 519 <i>bandwidth</i> of the link, and the variables <i>brequest</i> and
 520 <i>bcomputation</i> are drawn proportionally within a LINK.
 521 <i>This configuration enables the analysis of resource utilization by MSG tasks,
 522 and the identification of load-balancing issues, network bottlenecks, for
 523 instance.</i> \n
 524 <b>Other compositions</b>: besides <i>separation</i>, it is possible to use
 525 other types of compositions, such as gradients, and colors, like this:
 526 \verbatim
 527     gra_host = {
 528       type = gradient;
 529       scale = global;
 530       values = (numberOfTasks);
 531     };
 532     color_host = {
 533       type = color;
 534       values = (is_server);
 535     };
 536 \endverbatim
 537 Where <i>gra_host</i> creates a gradient within a node of the graph, using a
 538 global scale and using as value a variable called <i>numberOfTasks</i>, that
 539 could be declared by the user using the optional tracing functions of SimGrid.
 540 If scale is global, the max and min value for the gradient will be equal to the
 541 max and min numberOfTasks among all hosts, and if scale is local, the max and
 542 min value based on the value of numberOfTasks locally in each host.
 543 And <i>color_host</i> composition draws a square based on a positive value of
 544 the variable <i>is_server</i>, that could also be defined by the user using the
 545 SimGrid tracing functions. \n
 546 <b>The Graph Visualization</b>: The next figure shows a graph visualization of a
 547 given time-slice of the masterslave_forwarder example (present in the SimGrid
 548 sources). The red color indicates tasks from the <i>compute</i> category. This
 549 visualization was generated with the following configuration:
 550 \verbatim
 551 {
 552   node = (HOST);
 553   edge = (LINK);
 554
 555   HOST = {
 556     size = power;
 557     scale = global;
 558
 559     sep_host = {
 560       type = separation;
 561       size = power;
 562       values = (pcompute, pfinalize);
 563     };
 564   };
 565   LINK = {
 566     src = source;
 567     dst = destination;
 568     size = bandwidth;
 569     scale = global;
 570
 571     sep_link = {
 572       type = separation;
 573       size = bandwidth;
 574       values = (bcompute, bfinalize);
 575     };
 576   };
 577   graphviz-algorithm = neato;
 578 }
 579 \endverbatim
 580 <center>
 581 \htmlonly
 582 <a href="triva-graph_visualization.png" border=0><img src="triva-graph_visualization.png" width="50%" border=0></a>
 583 \endhtmlonly
 584 </center>
 585
 586 - <b>Understading Triva - colors</b>: An important issue when using Triva is how
 587   to define colors. To do that, we have to know which variables are defined in
 588 the trace file generated by the SimGrid library. The parameter <em>--list</em>
 589 lists the variables for a given trace file:
 590 \verbatim
 591 $ Triva -l masterslave_forwarder.trace
 592 iFile
 593 c  platform
 594 c    HOST
 595 v     power
 596 v     is_slave
 597 v     is_master
 598 v     task_creation
 599 v     task_computation
 600 v     pcompute
 601 v     pfinalize
 602 c    LINK
 603 v     bandwidth
 604 v     latency
 605 v     bcompute
 606 v     bfinalize
 607 c  user_type
 608 \endverbatim
 609 We can see that HOST has seven variables (from power to pfinalize) and LINK has
 610 four (from bandwidth to bfinalize). To define a red color for the
 611 <i>pcompute</i> and <i>bcompute</i> (which are defined based on user category
 612 <i>compute</i>), execute:
 613 \verbatim
 614 $ defaults write Triva 'pcompute Color' '1 0 0'
 615 $ defaults write Triva 'bcompute Color' '1 0 0'
 616 \endverbatim
 617 Where the three numbers in each line are the RGB color with values from 0 to 1.
 618
 619 \section options_modelchecking Model-Checking
 620 \subsection options_modelchecking_howto How to use it
 621 To enable the experimental SimGrid model-checking support the program should
 622 be executed with the command line argument
 623 \verbatim
 624 --cfg=model-check:1
 625 \endverbatim
 626 Properties are expressed as assertions using the function
 627 \verbatim
 628 void MC_assert(int prop);
 629 \endverbatim
 630
 631 */