Logo AND Algorithmique Numérique Distribuée

Public GIT Repository
Merge branch 'master' of scm.gforge.inria.fr:/gitroot/simgrid/simgrid
[simgrid.git] / doc / doxygen / options.doc
index 18e8038..539c43f 100644 (file)
@@ -1,4 +1,4 @@
-/*! \page options Simgrid options and configurations
+/*! \page options Step 2: Configure SimGrid
 
 A number of options can be given at runtime to change the default
 SimGrid behavior. For a complete list of all configuration options
@@ -9,6 +9,8 @@ report so that we can fix it. Note that some of the options presented
 here may not be available in your simulators, depending on the
 @ref install_src_config "compile-time options" that you used.
 
+\tableofcontents
+
 \section options_using Passing configuration options to the simulators
 
 There is several way to pass configuration options to the simulators.
@@ -92,7 +94,7 @@ described in
   - \b LV08 (default one): Realistic network analytic model
     (slow-start modeled by multiplying latency by 10.4, bandwidth by
     .92; bottleneck sharing uses a payload of S=8775 for evaluating RTT)
-  - \b Constant: Simplistic network model where all communication
+  - \anchor options_model_select_network_constant \b Constant: Simplistic network model where all communication
     take a constant time (one second). This model provides the lowest
     realism, but is (marginally) faster.
   - \b SMPI: Realistic network model specifically tailored for HPC
@@ -118,8 +120,6 @@ If you compiled SimGrid accordingly, you can use packet-level network
 simulators as network models (see \ref pls). In that case, you have
 two extra models, described below, and some \ref options_pls "specific
 additional configuration flags".
-  - \b GTNets: Network pseudo-model using the GTNets simulator instead
-    of an analytic model
   - \b NS3: Network pseudo-model using the NS3 tcp model instead of an
     analytic model
 
@@ -254,7 +254,7 @@ deployment of processes on nodes.
 
 \subsubsection options_model_network_crosstraffic Simulating cross-traffic
 
-%As of SimGrid v3.7, cross-traffic effects can be taken into account in
+As of SimGrid v3.7, cross-traffic effects can be taken into account in
 analytical simulations. It means that ongoing and incoming
 communication flows are treated independently. In addition, the LV08
 model adds 0.05 of usage on the opposite direction for each new
@@ -263,7 +263,7 @@ phenomena such as ack compression.
 
 For that to work, your platform must have two links for each
 pair of interconnected hosts. An example of usable platform is
-available in <tt>examples/msg/gtnets/crosstraffic-p.xml</tt>.
+available in <tt>examples/platforms/crosstraffic.xml</tt>.
 
 This is activated through the \b network/crosstraffic item, that
 can be set to 0 (disable this feature) or 1 (enable it).
@@ -273,7 +273,8 @@ Note that with the default host model this option is activated by default.
 \subsubsection options_model_network_coord Coordinated-based network models
 
 When you want to use network coordinates, as it happens when you use
-an \<AS\> in your platform file with \c Vivaldi as a routing, you must
+an \<AS\> in your platform file with \c Vivaldi as a routing (see also
+Section \ref pf_routing_model_vivaldi "Vivaldi Routing Model"), you must
 set the \b network/coordinates to \c yes so that all mandatory
 initialization are done in the simulator.
 
@@ -316,19 +317,12 @@ corresponding to the ns3::TcpL4Protocol::SocketType configuration item
 in NS3. The only valid values (enforced on the SimGrid side) are
 'NewReno' or 'Reno' or 'Tahoe'.
 
-When using GTNeTS, two items exist:
- - \b gtnets/jitter, that is a double value to oscillate
-   the link latency, uniformly in random interval
-   [-latency*gtnets_jitter,latency*gtnets_jitter). It defaults to 0.
- - \b gtnets/jitter_seed, the positive seed used to reproduce jitted
-   results. Its value must be in [1,1e8] and defaults to 10.
-
 \section options_modelchecking Configuring the Model-Checking
 
-To enable the experimental SimGrid model-checking support the program should
-be executed with the command line argument
+To enable the SimGrid model-checking support the program should
+be executed using the simgrid-mc wrapper:
 \verbatim
---cfg=model-check:1
+simgrid-mc ./my_program
 \endverbatim
 
 Safety properties are expressed as assertions using the function
@@ -347,10 +341,6 @@ ltl2ba program.
 --cfg=model-check/property:<filename>
 \endverbatim
 
-Of course, specifying a liveness property enables the model-checking
-so that you don't have to give <tt>--cfg=model-check:1</tt> in
-addition.
-
 \subsection options_modelchecking_steps Going for stateful verification
 
 By default, the system is backtracked to its initial state to explore
@@ -368,9 +358,6 @@ setting for your specific system.
 --cfg=model-check/checkpoint:1
 \endverbatim
 
-Of course, specifying this option enables the model-checking so that
-you don't have to give <tt>--cfg=model-check:1</tt> in addition.
-
 \subsection options_modelchecking_reduction Specifying the kind of reduction
 
 The main issue when using the model-checking is the state space
@@ -391,10 +378,6 @@ For now, this configuration variable can take 2 values:
  * dpor: Apply Dynamic Partial Ordering Reduction. Only valid if you
    verify local safety properties.
 
-Of course, specifying a reduction technique enables the model-checking
-so that you don't have to give <tt>--cfg=model-check:1</tt> in
-addition.
-
 \subsection options_modelchecking_visited model-check/visited, Cycle detection
 
 In order to detect cycles, the model-checker needs to check if a new explored
@@ -765,7 +748,7 @@ be simulated using SMPI by calling internal smpi_execute*() functions.
 
 To disable the benchmarking/simulation of computation in the simulated
 application, the variable \b
-smpi/simulation_computation should be set to no
+smpi/simulate_computation should be set to no
 
 \subsection options_model_smpi_bw_factor smpi/bw_factor: Bandwidth factors
 
@@ -793,10 +776,10 @@ Here, MAX_BANDWIDTH denotes the bandwidth of the link.
 
 \b Default: 0 (false)
 
-Most of the time, you run MPI code through SMPI to compute the time it
-would take to run it on a platform that you don't have. But since the
+Most of the time, you run MPI code with SMPI to compute the time it
+would take to run it on a platform. But since the
 code is run through the \c smpirun script, you don't have any control
-on the launcher code, making difficult to report the simulated time
+on the launcher code, making it difficult to report the simulated time
 when the simulation ends. If you set the \b smpi/display_timing item
 to 1, \c smpirun will display this information when the simulation ends. \verbatim
 Simulation time: 1e3 seconds.
@@ -1079,9 +1062,6 @@ silently overflow on other parts of the memory.
 
 - \c exception/cutpath: \ref options_exception_cutpath
 
-- \c gtnets/jitter: \ref options_pls
-- \c gtnets/jitter_seed: \ref options_pls
-
 - \c host/model: \ref options_model_select
 
 - \c maxmin/precision: \ref options_model_precision
@@ -1138,7 +1118,7 @@ silently overflow on other parts of the memory.
 - \c smpi/privatize_global_variables: \ref options_smpi_global
 - \c smpi/running_power: \ref options_smpi_bench
 - \c smpi/send_is_detached_thresh: \ref options_model_smpi_detached
-- \c smpi/simulation_computation: \ref options_smpi_bench
+- \c smpi/simulate_computation: \ref options_smpi_bench
 - \c smpi/test: \ref options_model_smpi_test
 - \c smpi/use_shared_malloc: \ref options_model_smpi_use_shared_malloc
 - \c smpi/wtime: \ref options_model_smpi_wtime