./msg_test small_platform.xml small_deployment.xml 2>&1 | ../../tools/MSG_visualization/colorize.pl
\endverbatim
-We also have a more graphical output. Have a look at MSG_paje_output(). It
-generates an input to <a href="http://www-id.imag.fr/Logiciels/paje/">Paje</a>.
-<center>
-\htmlonly
- <a href="Paje_MSG_screenshot.jpg"><img src="Paje_MSG_screenshot_thn.jpg"></a>
-\endhtmlonly
-</center>
-
-Visualization with Paje can be seen as a kind of postmortem
-analysis. However, as soon as you start playing with big simulations,
-you'll realize that processing such output is kind of tricky. There is
-so much generic information that it is hard to find the information
-you are looking for.
-
-As a matter of fact, logging really depends on simulations (e.g. what
-kind of events is important...). That is why we do not propose a big
-dump of your whole simulation (it would slow everything down) but give
-you neat tools to structure you logs. Have a look at \ref XBT_log. In
-fact, rather than a post-mortem analysis, you may want to do it on the
-fly. The process you are running can do whatever you want. Have you
-thought about adding a global structure where you directly compute the
-information that are really important rather than writing everything
-down and then processing huge files?
+We also have a more graphical output. Have a look at section \ref faq_tracing.
\subsection faq_C Argh! Do I really have to code in C?
\verbatim
"cmake -D[name]=[value] ... ./"
-[name] disable_gtnets [value] ON/OFF or TRUE/FALSE or 1/0
- disable_java ON/OFF or TRUE/FALSE or 1/0
- disable_lua ON/OFF or TRUE/FALSE or 1/0
- disable_ruby ON/OFF or TRUE/FALSE or 1/0
-
+[name] enable_gtnets [value] ON/OFF or TRUE/FALSE or 1/0
+ enable_java ON/OFF or TRUE/FALSE or 1/0
+ enable_lua ON/OFF or TRUE/FALSE or 1/0
+ enable_ruby ON/OFF or TRUE/FALSE or 1/0
enable_compile_optimizations ON/OFF or TRUE/FALSE or 1/0
enable_compile_warnings ON/OFF or TRUE/FALSE or 1/0
enable_maintainer_mode ON/OFF or TRUE/FALSE or 1/0
\subsubsection faq_cmakeoption2 Options explaination
- \li disable_gtnets : set to true implie that user doesn't want to use gtnets.
+ \li enable_gtnets : set to true implie that user wants to use gtnets.
- \li disable_java : set to true implie that user doesn't want to add java langage into simgrid compilation.
+ \li enable_java : set to true implie that user wants to add java langage into simgrid compilation.
- \li disable_lua : set to true implie that user doesn't want to add lua langage into simgrid compilation.
+ \li enable_lua : set to true implie that user wants to add lua langage into simgrid compilation.
- \li disable_ruby : set to true implie that user doesn't want to add ruby langage into simgrid compilation.
+ \li enable_ruby : set to true implie that user wants to add ruby langage into simgrid compilation.
\li enable_compile_optimizations : add flags "-O3 -finline-functions -funroll-loops -fno-strict-aliasing"
Those options are initialized the first time you launch \"cmake ./\" whithout specified option.
\verbatim
-disable_gtnets off
-disable_java off
-disable_lua off
-disable_ruby off
-
+enable_gtnets on
+enable_lua on
+enable_ruby on
+enable_java off
enable_compile_optimizations off
enable_compile_warnings off
enable_maintainer_mode off
<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
+./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...
+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
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
\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.
+
\section faq_troubleshooting Troubleshooting
\subsection faq_trouble_lib_compil SimGrid compilation and installation problems
