+ You need to use one of the following options:
+ -g, --graph Graph Analysis
+ -t, --treemap Treemap Analysis
+
+ Other auxiliary options to check the trace file:
+ -c, --check Check the integrity of trace file
+ -h, --hierarchy Export the trace type hierarchy
+ -l, --list List entity types
+
+ -?, --help Give this help list
+ --usage Give a short usage message
+\endverbatim
+Triva expects that the user choose one of the available options
+(currently <em>--graph</em> or <em>--treemap</em> for a visualization analysis)
+and the trace file from the simulation.
+
+- <b>Understanding Triva - time-slice</b>: the analysis of a trace file using
+ the tool always takes into account the concept of the <em>time-slice</em>.
+This concept means that what is being visualized in the screen is always
+calculated considering a specific time frame, with its beggining and end
+timestamp. The time-slice is configured by the user and can be changed
+dynamically through the window called <em>Time Interval</em> that is opened
+whenever a trace file is being analyzed. The next figure depicts the time-slice
+configuration window.
+In the top of the window, in the space named <i>Trace Time</i>,
+the two fields show the beggining of the trace (which usually starts in 0) and
+the end (that depends on the time simulated by SimGrid). The middle of the
+window, in the square named <i>Time Slice Configuration</i>, contains the
+aspects related to the time-slice, including its <i>start</i> and its
+<i>size</i>. The gray rectangle in the bottom of this part indicates the
+<i>current time-slice</i> that is considered for the drawings. If the checkbox
+<i>Update Drawings on Sliders Change</i> is not selected, the button
+<i>Apply</i> must be clicked in order to inform triva that the
+new time-slice must be considered. The bottom part of the window, in the space
+indicated by the square <i>Time Slice Animation</i> can be used to advance
+the time-frame automatically. The user configures the amount of time that the
+time-frame will forward and how frequent this update will happen. Once this is
+configured, the user clicks the <i>Play</i> button in order to see the dynamic
+changes on the drawings.
+<center>
+\htmlonly
+<a href="triva-time_interval.png" border=0><img src="triva-time_interval.png" width="50%" border=0></a>
+\endhtmlonly
+</center>
+<b>Remarks:</b> when the trace has too many hosts or links, the computation to
+take into account a new time-slice can be expensive. When this happens, the
+<i>Frequency</i> parameter, but also updates caused by change on configurations
+when the checkbox <i>Update Drawings on Sliders
+Change</i> is selected will not be followed.
+
+- <b>Understanding Triva - graph</b>: this part of the documention explains how
+ to analyze the traces using the graph view of Triva, when the user executes
+the tool passing <em>--graph</em> as parameter. Triva opens three windows when
+this parameter is used: the <i>Time Interval</i> window (previously described),
+the <i>Graph Representation</i> window, and the <em>Graph Configuration</em>
+window. The Graph Representation is the window where drawings take place.
+Initially, it is completely white waiting for a proper graph configuration input
+by the user. We start the description of this type of analysis by describing the
+<i>Graph Configuration</i> window (depicted below). By using a particular
+configuration, triva
+can be used to customize the graph drawing according to
+the SimGrid trace that was created with user-specific categories. Before delving
+into the details of this customization, let us first explain the major parts of
+the graph configuration window. The buttons located in the top-right corner can
+be used to delete, copy and create a new configuration. The checkbox in the
+top-middle part of the window indicates if the configuration typed in the
+textfield is syntactically correct (we are using the non-XML
+<a href="http://en.wikipedia.org/wiki/Property_list">Property List Format</a> to
+describe the configuration). The pop-up button located on the top-left corner
+indicates the selected configuration (the user can have multiple graph
+configurations). The bottom-left text field contains the name of the current
+configuration (updates on this field must be followed by typing enter on the
+keyboard to take into account the name change). The bottom-right <em>Apply</em>
+button activates the current configuration, resulting on an update on the graph
+drawings.
+<center>
+\htmlonly
+<a href="triva-graph_configuration.png" border=0><img src="triva-graph_configuration.png" width="50%" border=0></a>
+\endhtmlonly
+</center>
+<b>Basic SimGrid Configuration</b>: The figure shows in the big textfield the
+basic configuration that should be used during the analysis of a SimGrid trace
+file. The basic logic of the configuration is as follows:
+\verbatim
+{
+ node = (HOST);
+ edge = (LINK);
+\endverbatim
+The nodes of the graph will be created based on the <i>node</i> parameter, which
+in this case is the different <em>"HOST"</em>s of the platform
+used to simulate. The <i>edge</i> parameter indicates that the edges of the
+graph will be created based on the <em>"LINK"</em>s of the platform. After the
+definition of these two parameters, the configuration must detail how
+<em>HOST</em>s and <em>LINK</em>s should be drawn. For that, the configuration
+must have an entry for each of the types used. For <em>HOST</em>, as basic
+configuration, we have:
+\verbatim
+ HOST = {
+ size = power;
+ scale = global;
+ };
+\endverbatim
+The parameter <em>size</em> indicates which variable from the trace file will be
+used to define the size of the node HOST in the visualization. If the simulation
+was executed with availability traces, the size of the nodes will be changed
+according to these traces. The parameter <em>scale</em> indicates if the value
+of the variable is <em>global</em> or <em>local</em>. If it is global, the value
+will be relative to the power of all other hosts, if it is local, the value will
+be relative locally.
+For <em>LINK</em> we have:
+\verbatim
+ LINK = {
+ src = SrcHost;
+ dst = DstHost;
+
+ size = bandwidth;
+ scale = global;
+ };
+\endverbatim
+For the types specified in the <em>edge</em> parameter (such as <em>LINK</em>),
+the configuration must contain two additional parameters: <em>src</em> and
+<em>dst</em> that are used to properly identify which nodes this edge is
+connecting. The values <em>SrcHost</em> and <em>DstHost</em> are always present
+in the SimGrid trace file and should not be changed in the configuration. The
+parameter <em>size</em> for the LINK, in this case, is configured as the
+variable <em>bandwidth</em>, with a <em>global</em> scale. The scale meaning
+here is exactly the same used for nodes. The last parameter is the GraphViz
+algorithm used to calculate the position of the nodes in the graph
+representation.
+\verbatim
+ graphviz-algorithm = neato;
+}
+\endverbatim
+<b>Customizing the Graph Representation</b>: triva is capable to handle
+a customized graph representation based on the variables present in the trace
+file. In the case of SimGrid, every time a category is created for tasks, two
+variables in the trace file are defined: one to indicate node utilization (how
+much power was used by that task category), and another to indicate link
+utilization (how much bandwidth was used by that category). For instance, if the
+user declares a category named <i>request</i>, there will be variables named
+<b>p</b><i>request</i> and a <b>b</b><i>request</i> (<b>p</b> for power and
+<b>b</b> for bandwidth). It is important to notice that the variable
+<i>prequest</i> in this case is only available for HOST, and
+<i>brequest</i> is only available for LINK. <b>Example</b>: suppose there are
+two categories for tasks: request and compute. To create a customized graph
+representation with a proportional separation of host and link utilization, use
+as configuration for HOST and LINK this:
+\verbatim
+ HOST = {
+ size = power;
+ scale = global;
+
+ sep_host = {
+ type = separation;
+ size = power;
+ values = (prequest, pcomputation);
+ };
+ };
+
+ LINK = {
+ src = SrcHost;
+ dst = DstHost;
+ size = bandwidth;
+ scale = global;
+
+ sep_link = {
+ type = separation;
+ size = bandwidth;
+ values = (brequest, bcomputation);
+ };
+ };
+\endverbatim
+Where <i>sep_host</i> contains a composition of type <i>separation</i> where
+its max size is the <i>power</i> of the host and the variables <i>prequest</i>
+and <i>pcomputation</i> are drawn proportionally to the size of the HOST. And
+<i>sep_link</i> is also a separation where max is defined as the
+<i>bandwidth</i> of the link, and the variables <i>brequest</i> and
+<i>bcomputation</i> are drawn proportionally within a LINK.
+<i>This configuration enables the analysis of resource utilization by MSG tasks,
+and the identification of load-balancing issues, network bottlenecks, for
+instance.</i> \n
+<b>Other compositions</b>: besides <i>separation</i>, it is possible to use
+other types of compositions, such as gradients, and colors, like this:
+\verbatim
+ gra_host = {
+ type = gradient;
+ scale = global;
+ values = (numberOfTasks);
+ };
+ color_host = {
+ type = color;
+ values = (is_server);
+ };
+\endverbatim
+Where <i>gra_host</i> creates a gradient within a node of the graph, using a
+global scale and using as value a variable called <i>numberOfTasks</i>, that
+could be declared by the user using the optional tracing functions of SimGrid.
+If scale is global, the max and min value for the gradient will be equal to the
+max and min numberOfTasks among all hosts, and if scale is local, the max and
+min value based on the value of numberOfTasks locally in each host.
+And <i>color_host</i> composition draws a square based on a positive value of
+the variable <i>is_server</i>, that could also be defined by the user using the
+SimGrid tracing functions. \n
+<b>The Graph Visualization</b>: The next figure shows a graph visualization of a
+given time-slice of the masterslave_forwarder example (present in the SimGrid
+sources). The red color indicates tasks from the <i>compute</i> category. This
+visualization was generated with the following configuration:
+\verbatim
+{
+ node = (HOST);
+ edge = (LINK);
+
+ HOST = {
+ size = power;
+ scale = global;
+
+ sep_host = {
+ type = separation;
+ size = power;
+ values = (pcompute, pfinalize);
+ };
+ };
+ LINK = {
+ src = SrcHost;
+ dst = DstHost;
+ size = bandwidth;
+ scale = global;
+
+ sep_link = {
+ type = separation;
+ size = bandwidth;
+ values = (bcompute, bfinalize);
+ };
+ };
+ graphviz-algorithm = neato;
+}
+\endverbatim
+<center>
+\htmlonly
+<a href="triva-graph_visualization.png" border=0><img src="triva-graph_visualization.png" width="50%" border=0></a>
+\endhtmlonly
+</center>
+
+- <b>Understading Triva - colors</b>: An important issue when using Triva is how
+ to define colors. To do that, we have to know which variables are defined in
+the trace file generated by the SimGrid library. The parameter <em>--list</em>
+lists the variables for a given trace file:
+\verbatim
+$ Triva -l masterslave_forwarder.trace
+iFile
+c platform
+c HOST
+v power
+v is_slave
+v is_master
+v task_creation
+v task_computation
+v pcompute
+v pfinalize
+c LINK
+v bandwidth
+v latency
+v bcompute
+v bfinalize
+c user_type
+\endverbatim
+We can see that HOST has seven variables (from power to pfinalize) and LINK has
+four (from bandwidth to bfinalize). To define a red color for the
+<i>pcompute</i> and <i>bcompute</i> (which are defined based on user category
+<i>compute</i>), execute:
+\verbatim
+$ defaults write Triva 'pcompute Color' '1 0 0'
+$ defaults write Triva 'bcompute Color' '1 0 0'
+\endverbatim
+Where the three numbers in each line are the RGB color with values from 0 to 1.
+
+\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 ( for some reason or another ) developers prefer using some kind of « easy scripts »
+ (something like … lua ? Ruby ? ...?) or a language easier to code with ( Java ? ) for their works ,
+ which avoid dealing with C errors , and sometime an important gain of time (coding-time?) .
+Besides Java Binding , Lua and Ruby bindings are available now( 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 (Moon for portuguese !) 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 ,
+ but this time , code with Lua ;) :
+ - Coding functions coresponding to each process
+ - loading the platforme/deployment XML file that describe the environment of simulation
+ - and … Running the Simulation !!!
+
+\subsubsection faq_binding_lua_example_master_slave Master/Slave Example
+ \li Master Code
+\verbatim
+function Master(...)
+ nb_task = arg[1];
+ comp_size = arg[2];
+ comm_size = arg[3];
+ slave_count = arg[4]
+ -- Dispatch the tasks
+ for i=1,nb_task do
+ tk = simgrid.Task.new("Task "..i,comp_size,comm_size);
+ alias = "slave "..(i%slave_count);
+ simgrid.info("Master sending ’" .. simgrid.Task.name(tk) .."’ To ’" .. alias .."’");
+ simgrid.Task.send(tk,alias);
+ simgrid.info("Master done sending ’".. simgrid.Task.name(tk) .."’ To ’" .. alias .."’");
+ end
+ -- Sending Finalize Message To Others
+ for i=0,slave_count-1 do
+ alias = "slave "..i;
+ simgrid.info("Master: sending finalize to "..alias);
+ finalize = simgrid.Task.new("finalize",comp_size,comm_size);
+ simgrid.Task.send(finalize,alias)
+ end
+end
+\endverbatim
+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 .
+
+\li Slave Code
+\verbatim
+function Slave(...)
+ local my_mailbox="slave "..arg[1]
+ while true do
+ local tk = simgrid.Task.recv(my_mailbox);
+ if (simgrid.Task.name(tk) == "finalize") then
+ simgrid.info("Slave ’" ..my_mailbox.."’ got finalize msg");
+ break
+ end
+ simgrid.Task.execute(tk)
+ end
+ simgrid.info("Slave ’" ..my_mailbox.."’: I’m Done . See You !!");
+end
+\endverbatim
+Here , we could see how we use simgrid.Task.recv(alias) to receive a task with a specific alias ,
+this function return directly the task recevied .
+
+\li Set Environmenet and run application
+\verbatim
+require "simgrid"
+simgrid.platform("my_platform.xml")
+simgrid.application("my_deployment.xml")
+simgrid.run()
+simgrid.info("Simulation’s over.See you.")
+simgrid.clean()
+\endverbatim
+
+\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 . Via this key the receiver could 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 Hosts
+\verbatim
+ simgrid.Host.new("Tremblay",98095000);
+ simgrid.Host.new("Jupiter",76296000);
+ simgrid.Host.new("Fafard",76296000);
+ simgrid.Host.new("Ginette",48492000);
+ simgrid.Host.new("Bourassa",48492000);
+\endverbatim
+ we use simgrid.Host.new(host_id,power) to instanciate our hosts.
+
+\li set Links
+\verbatim
+ for i=0,11 do
+ simgrid.Link.new(i,252750+ i*768,0.000270544+i*0.087); -- some crazy values ;)
+ end
+\endverbatim
+ we used simgrid.Link.new(link_id,bandwidth,latency) with a simple for loop to create all links we need ( much easier than XML hein ? )
+
+\li set Routes
+\verbatim
+-- simgrid.Route.new(src_id,des_id,links_nb,links_list)
+ simgrid.Route.new("Tremblay","Jupiter",1,{"1"});
+ simgrid.Route.new("Tremblay","Fafard",6,{"0","1","2","3","4","8"});
+ simgrid.Route.new("Tremblay","Ginette",3,{"3","4","5"});
+ simgrid.Route.new("Tremblay","Bourassa",7,{"0","1","3","2","4","6","7"});
+
+ simgrid.Route.new("Jupiter","Tremblay",1,{"1"});
+ simgrid.Route.new("Jupiter","Fafard",7,{"0","1","2","3","4","8","9"});
+ simgrid.Route.new("Jupiter","Ginette",4,{"3","4","5","9"});
+ simgrid.Route.new("Jupiter","Bourassa",8,{"0","1","2","3","4","6","7","9"});
+ ...
+\endverbatim
+ for each host you have to specify which route to choose to access to the rest of hosts connected in the grid .
+
+\li Save platform
+\verbatim
+ simgrid.register_platform();
+\endverbatim
+Don't forget to register your platform , that SURF callbacks starts their work ;)
+
+\li set application
+\verbatim
+ simgrid.Host.setFunction("Tremblay","Master",4,{"20","550000000","1000000","4"});
+ simgrid.Host.setFunction("Bourassa","Slave",1,{"0"});
+ simgrid.Host.setFunction("Jupiter","Slave",1,{"1"});
+ simgrid.Host.setFunction("Fafard","Slave",1,{"2"});
+ simgrid.Host.setFunction("Ginette","Slave",1,{"3"});
+\endverbatim
+ you don't need to use a deployment XML file , thanks to simgrid.Host.setFunction(host_id,function,args_number,args_list)
+ you can associate functions for each host with arguments if needed .
+
+\li
+\verbatim
+ simgrid.register_application();
+\endverbatim
+Yes , Here too you have to resgiter your application before running the simulation .
+
+the full example is distributed in the file examples/lua/master_slave_bypass.lua