1 /*! \page options Simgrid options and configurations
3 \htmlinclude .options.doc.toc
5 \section options_simgrid_configuration Changing SimGrid's behavior
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
11 \subsection options_simgrid_configuration_fullduplex Using Fullduplex
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:
16 simgrid_svn_sources/exemples/msg/gtnets/fullduplex-p.xml
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.
24 Running a fullduplex example:
26 cd simgrid_svn_sources/exemples/msg/gtnets
27 ./gtnets fullduplex-p.xml fullduplex-d.xml --cfg=fullduplex:1
30 \subsection options_simgrid_configuration_gtnets Using GTNetS
32 It is possible to use a packet-level network simulator
33 instead of the default flow-based simulation. You may want to use such
34 an approach if you have doubts about the validity of the default model
35 or if you want to perform some validation experiments. At the moment,
36 we support the GTNetS simulator (it is still rather experimental
37 though, so leave us a message if you play with it).
41 To enable GTNetS model inside SimGrid it is needed to patch the GTNetS simulator source code
42 and build/install it from scratch
45 - <b>Download and enter the recent downloaded GTNetS directory</b>
48 svn checkout svn://scm.gforge.inria.fr/svn/simgrid/contrib/trunk/GTNetS/
53 - <b>Use the following commands to unzip and patch GTNetS package to work within SimGrid.</b>
56 unzip gtnets-current.zip
57 tar zxvf gtnets-current-patch.tgz
59 cat ../00*.patch | patch -p1
62 - <b>OPTIONALLY</b> you can use a patch for itanium 64bit processor family.
65 cat ../AMD64-FATAL-Removed-DUL_SIZE_DIFF-Added-fPIC-compillin.patch | patch -p1
68 - <b>Compile GTNetS</b>
70 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.
74 ln -sf Makefile.linux Makefile
80 - <b>NOTE</b> A lot of warnings are expected but the application should compile
81 just fine. If the makefile insists in compiling some QT libraries
82 please try a make clean before asking for help.
85 - <b>To compile optimized version</b>
92 - <b>Installing GTNetS</b>
94 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.
97 ln -sf /<absolute_path>/gtnets_current/libgtsim-debug.so /<userhome>/usr/lib/libgtnets.so
98 export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/<userhome>/usr/lib/libgtnets.so
99 mkdir /<userhome>/usr/include/gtnets
100 cp -fr SRC/*.h /<userhome>/usr/include/gtnets
104 - <b>Enable GTNetS support in SimGrid</b>
106 In order to enable gtnets with simgrid you have to give where is gtnets. (path to \<gtnets_path\>/lib and \<gtnets_path\>/include)
109 Since v3.4 (with cmake)
110 cmake . -Dgtnets_path=/<userhome>/usr
112 Until v3.4 (with autotools)
113 ./configure --with-gtnets=/<userhome>/usr
116 - <b>Once you have followed all the instructions for compiling and
117 installing successfully you can activate this feature at
118 runntime with the following options:</b>
121 Since v3.4 (with cmake)
126 Until v3.4 (with autotools)
127 cd simgrid/example/msg/
133 - <b>Or try the GTNetS model dogbone example with</b>
136 gtnets/gtnets gtnets/onelink-p.xml gtnets/onelink-d.xml --cfg=network_model:GTNets
140 A long version of this <a href="http://gforge.inria.fr/docman/view.php/12/6283/GTNetS HowTo.html">HowTo</a> it is available
143 More about GTNetS simulator at <a href="http://www.ece.gatech.edu/research/labs/MANIACS/GTNetS/index.html">GTNetS Website</a>
147 The patches provided by us worked successfully with GTNetS found
148 <a href="http://www.ece.gatech.edu/research/labs/MANIACS/GTNetS/software/gtnets-current.zip">here</a>,
149 dated from 12th June 2008. Due to the discontinuing development of
150 GTNetS it is impossible to precise a version number. We STRONGLY recommend you
151 to download and install the GTNetS version found in SimGrid repository as explained above.
156 \subsection options_simgrid_configuration_alternate_network Using alternative flow models
158 The default simgrid network model uses a max-min based approach as
159 explained in the research report
160 <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>.
161 Other models have been proposed and implemented since then (see for example
162 <a href="http://mescal.imag.fr/membres/arnaud.legrand/articles/simutools09.pdf">Accuracy Study and Improvement of Network Simulation in the SimGrid Framework</a>)
163 and can be activated at runtime. For example:
165 ./mycode platform.xml deployment.xml --cfg=workstation/model:compound --cfg=network/model:LV08 -cfg=cpu/model:Cas01
168 Possible models for the network are currently "Constant", "CM02",
169 "LegrandVelho", "GTNets", Reno", "Reno2", "Vegas". Others will
170 probably be added in the future and many of the previous ones are
171 experimental and are likely to disappear without notice... To know the
172 list of the currently implemented models, you should use the
173 --help-models command line option.
176 ./masterslave_forwarder ../small_platform.xml deployment_masterslave.xml --help-models
177 Long description of the workstation models accepted by this simulator:
178 CLM03: Default workstation model, using LV08 and CM02 as network and CPU
179 compound: Workstation model allowing you to use other network and CPU models
180 ptask_L07: Workstation model with better parallel task modeling
181 Long description of the CPU models accepted by this simulator:
182 Cas01_fullupdate: CPU classical model time=size/power
183 Cas01: Variation of Cas01_fullupdate with partial invalidation optimization of lmm system. Should produce the same values, only faster
184 CpuTI: Variation of Cas01 with also trace integration. Should produce the same values, only faster if you use availability traces
185 Long description of the network models accepted by this simulator:
186 Constant: Simplistic network model where all communication take a constant time (one second)
187 CM02: Realistic network model with lmm_solve and no correction factors
188 LV08: Realistic network model with lmm_solve and these correction factors: latency*=10.4, bandwidth*=.92, S=8775
189 Reno: Model using lagrange_solve instead of lmm_solve (experts only)
190 Reno2: Model using lagrange_solve instead of lmm_solve (experts only)
191 Vegas: Model using lagrange_solve instead of lmm_solve (experts only)
194 \section options_tracing Tracing Simulations for Visualization
196 The trace visualization is widely used to observe and understand the behavior
197 of parallel applications and distributed algorithms. Usually, this is done in a
198 two-step fashion: the user instruments the application and the traces are
199 analyzed after the end of the execution. The visualization itself can highlights
200 unexpected behaviors, bottlenecks and sometimes can be used to correct
201 distributed algorithms. The SimGrid team has instrumented the library
202 in order to let users trace their simulations and analyze them. This part of the
203 user manual explains how the tracing-related features can be enabled and used
204 during the development of simulators using the SimGrid library.
206 \subsection options_tracing_howitworks How it works
208 For now, the SimGrid library is instrumented so users can trace the <b>platform
209 utilization</b> using the MSG, SimDAG and SMPI interface. This means that the tracing will
210 register how much power is used for each host and how much bandwidth is used for
211 each link of the platform. The idea with this type of tracing is to observe the
212 overall view of resources utilization in the first place, especially the
213 identification of bottlenecks, load-balancing among hosts, and so on.
215 The idea of the tracing facilities is to give SimGrid users to possibility to
216 classify MSG and SimDAG tasks by category, tracing the platform utilization
217 (hosts and links) for each of the categories. For that,
218 the tracing interface enables the declaration of categories and a function to
219 mark a task with a previously declared category. <em>The tasks that are not
220 classified according to a category are not traced</em>. Even if the user
221 does not specify any category, the simulations can still be traced in terms
222 of resource utilization by using a special parameter that is detailed below.
224 \subsection options_tracing_enabling Enabling using CMake
226 With the sources of SimGrid, it is possible to enable the tracing
227 using the parameter <b>-Denable_tracing=ON</b> when the cmake is executed.
228 The section \ref options_tracing_functions describes all the functions available
229 when this Cmake options is activated. These functions will have no effect
230 if SimGrid is configured without this option (they are wiped-out by the
234 $ cmake -Denable_tracing=ON .
238 \subsection options_tracing_functions Tracing Functions
240 \li <b>\c TRACE_category (const char *category)</b>: This function should be used
241 to define a user category. The category can be used to differentiate the tasks
242 that are created during the simulation (for example, tasks from server1,
243 server2, or request tasks, computation tasks, communication tasks).
244 All resource utilization (host power and link bandwidth) will be
245 classified according to the task category. Tasks that do not belong to a
246 category are not traced. The color for the category that is being declared
247 is random (use next function to specify a color).
249 \li <b>\c TRACE_category_with_color (const char *category, const char *color)</b>: Same
250 as TRACE_category, but let user specify a color encoded as a RGB-like string with
251 three floats from 0 to 1. So, to specify a red color, the user can pass "1 0 0" as
252 color parameter. A light-gray color can be specified using "0.7 0.7 0.7" as color.
254 \li <b>\c TRACE_msg_set_task_category (m_task_t task, const char *category)</b>:
255 This function should be called after the creation of a MSG task, to define the
256 category of that task. The first parameter \c task must contain a task that was
257 created with the function \c MSG_task_create. The second parameter
258 \c category must contain a category that was previously defined by the function
261 \li <b>\c TRACE_sd_set_task_category (SD_task_t task, const char *category)</b>:
262 This function should be called after the creation of a SimDAG task, to define the
263 category of that task. The first parameter \c task must contain a task that was
264 created with the function \c MSG_task_create. The second parameter
265 \c category must contain a category that was previously defined by the function
268 \li <b>\c TRACE_[host|link]_variable_declare (const char *variable)</b>:
269 Declare a user variable that will be associated to host/link. A variable can
270 be used to trace user variables such as the number of tasks in a server,
271 the number of clients in an application (for hosts), and so on.
273 \li <b>\c TRACE_[host|link]_variable_[set|add|sub] (const char *[host|link], const char *variable, double value)</b>:
274 Set the value of a given user variable for a given host/link. The value
275 of this variable is always associated to the host/link. The host/link
276 parameters should be its name as the one listed in the platform file.
278 \li <b>\c TRACE_[host|link]_variable_[set|add|sub]_with_time (double time, const char *[host|link], const char *variable, double value)</b>:
279 Same as TRACE_[host|link]_variable_[set|add|sub], but let user specify
280 the time used to trace it. Users can specify a time that is not the
281 simulated clock time as defined by the core simulator. This allows
282 a fine-grain control of time definition, but should be used with
283 caution since the trace can be inconsistent if resource utilization
284 traces are also traced.
286 \li <b>\c TRACE_link_srcdst_variable_[set|add|sub] (const char *src, const char *dst, const char *variable, double value)</b>:
287 Same as TRACE_link_variable_[set|add|sub], but now users specify a source and
288 destination hosts (as the names from the platform file). The tracing library
289 will get the corresponding route that connects those two hosts (src and dst) and
290 [set|add|sub] the value's variable for all the links of the route.
292 \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>:
293 Same as TRACE_link_srcdst_variable_[set|add|sub], but user specify a time different from the simulated time.
295 \subsection options_tracing_options Tracing configuration Options
297 These are the options accepted by the tracing system of SimGrid:
302 Safe switch. It activates (or deactivates) the tracing system.
303 No other tracing options take effect if this one is not activated.
308 Register the simulation platform in the trace file.
313 By default, the tracing system uses all routes in the platform file
314 to re-create a "graph" of the platform and register it in the trace file.
315 This option let the user tell the tracing system to use only the routes
316 that are composed with just one link.
321 It activates the categorized resource utilization tracing. It should
322 be enabled if tracing categories are used by this simulator.
325 tracing/uncategorized
327 It activates the uncategorized resource utilization tracing. Use it if
328 this simulator do not use tracing categories and resource use have to be
334 A file with this name will be created to register the simulation. The file
335 is in the Paje format and can be analyzed using Triva or Paje visualization
336 tools. More information can be found in these webpages:
337 <a href="http://triva.gforge.inria.fr/">http://triva.gforge.inria.fr/</a>
338 <a href="http://paje.sourceforge.net/">http://paje.sourceforge.net/</a>
343 This option only has effect if this simulator is SMPI-based. Traces the MPI
344 interface and generates a trace that can be analyzed using Gantt-like
345 visualizations. Every MPI function (implemented by SMPI) is transformed in a
346 state, and point-to-point communications can be analyzed with arrows.
351 This option only has effect if this simulator is SMPI-based. The processes
352 are grouped by the hosts where they were executed.
357 This option only has effect if this simulator is MSG-based. It traces the
358 behavior of all categorized MSG tasks, grouping them by hosts.
363 This option only has effect if this simulator is MSG-based. It traces the
364 behavior of all categorized MSG processes, grouping them by hosts. This option
365 can be used to track process location if this simulator has process migration.
369 triva/categorized:graph_categorized.plist
371 This option generates a graph configuration file for Triva considering
372 categorized resource utilization.
375 triva/uncategorized:graph_uncategorized.plist
377 This option generates a graph configuration file for Triva considering
378 uncategorized resource utilization.
380 \subsection options_tracing_example Example of Instrumentation
382 A simplified example using the tracing mandatory functions.
385 int main (int argc, char **argv)
387 MSG_global_init (&argc, &argv);
389 //(... after deployment ...)
391 //note that category declaration must be called after MSG_create_environment
392 TRACE_category_with_color ("request", "1 0 0");
393 TRACE_category_with_color ("computation", "0.3 1 0.4");
394 TRACE_category ("finalize");
396 m_task_t req1 = MSG_task_create("1st_request_task", 10, 10, NULL);
397 m_task_t req2 = MSG_task_create("2nd_request_task", 10, 10, NULL);
398 m_task_t req3 = MSG_task_create("3rd_request_task", 10, 10, NULL);
399 m_task_t req4 = MSG_task_create("4th_request_task", 10, 10, NULL);
400 TRACE_msg_set_task_category (req1, "request");
401 TRACE_msg_set_task_category (req2, "request");
402 TRACE_msg_set_task_category (req3, "request");
403 TRACE_msg_set_task_category (req4, "request");
405 m_task_t comp = MSG_task_create ("comp_task", 100, 100, NULL);
406 TRACE_msg_set_task_category (comp, "computation");
408 m_task_t finalize = MSG_task_create ("finalize", 0, 0, NULL);
409 TRACE_msg_set_task_category (finalize, "finalize");
418 \subsection options_tracing_analyzing Analyzing the SimGrid Traces
420 The SimGrid library, during an instrumented simulation, creates a trace file in
421 the Paje file format that contains the platform utilization for the simulation
422 that was executed. The visualization analysis of this file is performed with the
423 visualization tool <a href="http://triva.gforge.inria.fr">Triva</a>, with
424 special configurations tunned to SimGrid needs. This part of the documentation
425 explains how to configure and use Triva to analyse a SimGrid trace file.
427 - <b>Installing Triva</b>: the tool is available in the INRIAGforge,
428 at <a href="http://triva.gforge.inria.fr">http://triva.gforge.inria.fr</a>.
429 Use the following command to get the sources, and then check the file
430 <i>INSTALL</i>. This file contains instructions to install
431 the tool's dependencies in a Ubuntu/Debian Linux. The tool can also
432 be compiled in MacOSes natively, check <i>INSTALL.mac</i> file.
434 $ svn checkout svn://scm.gforge.inria.fr/svn/triva
439 - <b>Executing Triva</b>: a binary called <i>Triva</i> is available after the
440 installation (you can execute it passing <em>--help</em> to check its
441 options). If the triva binary is not available after following the
442 installation instructions, you may want to execute the following command to
443 initialize the GNUstep environment variables. We strongly recommend that you
444 use the latest GNUstep packages, and not the packages available through apt-get
445 in Ubuntu/Debian packaging systems. If you install GNUstep using the latest
446 available packages, you can execute this command:
448 $ source /usr/GNUstep/System/Library/Makefiles/GNUstep.sh
450 You should be able to see this output after the installation of triva:
452 $ ./Triva.app/Triva --help
453 Usage: Triva [OPTIONS...] TRACE0 [TRACE1]
454 Trace Analysis through Visualization
457 --ti_frequency {double} Animation: frequency of updates
458 --ti_hide Hide the TimeInterval window
459 --ti_forward {double} Animation: value to move time-slice
460 --ti_apply Apply the configuration
461 --ti_update Update on slider change
462 --ti_animate Start animation
463 --ti_start {double} Start of time slice
464 --ti_size {double} Size of time slice
466 --comparison Compare Trace Files (Experimental)
467 --graph Configurable Graph
468 --list Print Trace Type Hierarchy
469 --hierarchy Export Trace Type Hierarchy (dot)
470 --stat Trace Statistics and Memory Utilization
471 --instances List All Trace Entities
472 --linkview Link View (Experimental)
473 --treemap Squarified Treemap
474 --merge Merge Trace Files (Experimental)
475 --check Check Trace File Integrity
477 --gc_conf {file} Graph Configuration in Property List Format
478 --gc_apply Apply the configuration
479 --gc_hide Hide the GraphConfiguration window
481 Triva expects that the user choose one of the available options
482 (currently <em>--graph</em> or <em>--treemap</em> for a visualization analysis)
483 and the trace file from the simulation.
485 - <b>Understanding Triva - time-slice</b>: the analysis of a trace file using
486 the tool always takes into account the concept of the <em>time-slice</em>.
487 This concept means that what is being visualized in the screen is always
488 calculated considering a specific time frame, with its beggining and end
489 timestamp. The time-slice is configured by the user and can be changed
490 dynamically through the window called <em>Time Interval</em> that is opened
491 whenever a trace file is being analyzed. The next figure depicts the time-slice
492 configuration window.
493 In the top of the window, in the space named <i>Trace Time</i>,
494 the two fields show the beggining of the trace (which usually starts in 0) and
495 the end (that depends on the time simulated by SimGrid). The middle of the
496 window, in the square named <i>Time Slice Configuration</i>, contains the
497 aspects related to the time-slice, including its <i>start</i> and its
498 <i>size</i>. The gray rectangle in the bottom of this part indicates the
499 <i>current time-slice</i> that is considered for the drawings. If the checkbox
500 <i>Update Drawings on Sliders Change</i> is not selected, the button
501 <i>Apply</i> must be clicked in order to inform triva that the
502 new time-slice must be considered. The bottom part of the window, in the space
503 indicated by the square <i>Time Slice Animation</i> can be used to advance
504 the time-frame automatically. The user configures the amount of time that the
505 time-frame will forward and how frequent this update will happen. Once this is
506 configured, the user clicks the <i>Play</i> button in order to see the dynamic
507 changes on the drawings.
510 <a href="triva-time_interval.png" border=0><img src="triva-time_interval.png" width="50%" border=0></a>
513 <b>Remarks:</b> when the trace has too many hosts or links, the computation to
514 take into account a new time-slice can be expensive. When this happens, the
515 <i>Frequency</i> parameter, but also updates caused by change on configurations
516 when the checkbox <i>Update Drawings on Sliders
517 Change</i> is selected will not be followed.
519 - <b>Understanding Triva - graph</b>: this part of the documention explains how
520 to analyze the traces using the graph view of Triva, when the user executes
521 the tool passing <em>--graph</em> as parameter. Triva opens three windows when
522 this parameter is used: the <i>Time Interval</i> window (previously described),
523 the <i>Graph Representation</i> window, and the <em>Graph Configuration</em>
524 window. The Graph Representation is the window where drawings take place.
525 Initially, it is completely white waiting for a proper graph configuration input
526 by the user. We start the description of this type of analysis by describing the
527 <i>Graph Configuration</i> window (depicted below). By using a particular
529 can be used to customize the graph drawing according to
530 the SimGrid trace that was created with user-specific categories. Before delving
531 into the details of this customization, let us first explain the major parts of
532 the graph configuration window. The buttons located in the top-right corner can
533 be used to delete, copy and create a new configuration. The checkbox in the
534 top-middle part of the window indicates if the configuration typed in the
535 textfield is syntactically correct (we are using the non-XML
536 <a href="http://en.wikipedia.org/wiki/Property_list">Property List Format</a> to
537 describe the configuration). The pop-up button located on the top-left corner
538 indicates the selected configuration (the user can have multiple graph
539 configurations). The bottom-left text field contains the name of the current
540 configuration (updates on this field must be followed by typing enter on the
541 keyboard to take into account the name change). The bottom-right <em>Apply</em>
542 button activates the current configuration, resulting on an update on the graph
546 <a href="triva-graph_configuration.png" border=0><img src="triva-graph_configuration.png" width="50%" border=0></a>
549 <b>Basic SimGrid Configuration</b>: The figure shows in the big textfield the
550 basic configuration that should be used during the analysis of a SimGrid trace
551 file. The basic logic of the configuration is as follows:
557 The nodes of the graph will be created based on the <i>node</i> parameter, which
558 in this case is the different <em>"HOST"</em>s of the platform
559 used to simulate. The <i>edge</i> parameter indicates that the edges of the
560 graph will be created based on the <em>"LINK"</em>s of the platform. After the
561 definition of these two parameters, the configuration must detail how
562 <em>HOST</em>s and <em>LINK</em>s should be drawn. For that, the configuration
563 must have an entry for each of the types used. For <em>HOST</em>, as basic
564 configuration, we have:
571 The parameter <em>size</em> indicates which variable from the trace file will be
572 used to define the size of the node HOST in the visualization. If the simulation
573 was executed with availability traces, the size of the nodes will be changed
574 according to these traces. The parameter <em>scale</em> indicates if the value
575 of the variable is <em>global</em> or <em>local</em>. If it is global, the value
576 will be relative to the power of all other hosts, if it is local, the value will
578 For <em>LINK</em> we have:
588 For the types specified in the <em>edge</em> parameter (such as <em>LINK</em>),
589 the configuration must contain two additional parameters: <em>src</em> and
590 <em>dst</em> that are used to properly identify which nodes this edge is
591 connecting. The values <em>source</em> and <em>destination</em> are always present
592 in the SimGrid trace file and should not be changed in the configuration. The
593 parameter <em>size</em> for the LINK, in this case, is configured as the
594 variable <em>bandwidth</em>, with a <em>global</em> scale. The scale meaning
595 here is exactly the same used for nodes. The last parameter is the GraphViz
596 algorithm used to calculate the position of the nodes in the graph
599 graphviz-algorithm = neato;
602 <b>Customizing the Graph Representation</b>: triva is capable to handle
603 a customized graph representation based on the variables present in the trace
604 file. In the case of SimGrid, every time a category is created for tasks, two
605 variables in the trace file are defined: one to indicate node utilization (how
606 much power was used by that task category), and another to indicate link
607 utilization (how much bandwidth was used by that category). For instance, if the
608 user declares a category named <i>request</i>, there will be variables named
609 <b>p</b><i>request</i> and a <b>b</b><i>request</i> (<b>p</b> for power and
610 <b>b</b> for bandwidth). It is important to notice that the variable
611 <i>prequest</i> in this case is only available for HOST, and
612 <i>brequest</i> is only available for LINK. <b>Example</b>: suppose there are
613 two categories for tasks: request and compute. To create a customized graph
614 representation with a proportional separation of host and link utilization, use
615 as configuration for HOST and LINK this:
624 values = (prequest, pcomputation);
637 values = (brequest, bcomputation);
641 Where <i>sep_host</i> contains a composition of type <i>separation</i> where
642 its max size is the <i>power</i> of the host and the variables <i>prequest</i>
643 and <i>pcomputation</i> are drawn proportionally to the size of the HOST. And
644 <i>sep_link</i> is also a separation where max is defined as the
645 <i>bandwidth</i> of the link, and the variables <i>brequest</i> and
646 <i>bcomputation</i> are drawn proportionally within a LINK.
647 <i>This configuration enables the analysis of resource utilization by MSG tasks,
648 and the identification of load-balancing issues, network bottlenecks, for
650 <b>Other compositions</b>: besides <i>separation</i>, it is possible to use
651 other types of compositions, such as gradients, and colors, like this:
656 values = (numberOfTasks);
660 values = (is_server);
663 Where <i>gra_host</i> creates a gradient within a node of the graph, using a
664 global scale and using as value a variable called <i>numberOfTasks</i>, that
665 could be declared by the user using the optional tracing functions of SimGrid.
666 If scale is global, the max and min value for the gradient will be equal to the
667 max and min numberOfTasks among all hosts, and if scale is local, the max and
668 min value based on the value of numberOfTasks locally in each host.
669 And <i>color_host</i> composition draws a square based on a positive value of
670 the variable <i>is_server</i>, that could also be defined by the user using the
671 SimGrid tracing functions. \n
672 <b>The Graph Visualization</b>: The next figure shows a graph visualization of a
673 given time-slice of the masterslave_forwarder example (present in the SimGrid
674 sources). The red color indicates tasks from the <i>compute</i> category. This
675 visualization was generated with the following configuration:
688 values = (pcompute, pfinalize);
700 values = (bcompute, bfinalize);
703 graphviz-algorithm = neato;
708 <a href="triva-graph_visualization.png" border=0><img src="triva-graph_visualization.png" width="50%" border=0></a>
712 - <b>Understading Triva - colors</b>: An important issue when using Triva is how
713 to define colors. To do that, we have to know which variables are defined in
714 the trace file generated by the SimGrid library. The parameter <em>--list</em>
715 lists the variables for a given trace file:
717 $ Triva -l masterslave_forwarder.trace
735 We can see that HOST has seven variables (from power to pfinalize) and LINK has
736 four (from bandwidth to bfinalize). To define a red color for the
737 <i>pcompute</i> and <i>bcompute</i> (which are defined based on user category
738 <i>compute</i>), execute:
740 $ defaults write Triva 'pcompute Color' '1 0 0'
741 $ defaults write Triva 'bcompute Color' '1 0 0'
743 Where the three numbers in each line are the RGB color with values from 0 to 1.
745 \section options_modelchecking Model-Checking
746 \subsection options_modelchecking_howto How to use it
747 To enable the experimental SimGrid model-checking support the program should
748 be executed with the command line argument
752 Properties are expressed as assertions using the function
754 void MC_assert(int prop);