+\subsection options_model_smpi_lat_factor smpi/lat_factor: Latency factors
+
+The motivation and syntax for this option is identical to the motivation/syntax
+of smpi/bw_factor, see \ref options_model_smpi_bw_factor for details.
+
+There is an important difference, though: While smpi/bw_factor \a reduces the
+actual bandwidth (i.e., values between 0 and 1 are valid), latency factors
+increase the latency, i.e., values larger than or equal to 1 are valid here.
+
+This is the default value:
+
+\verbatim
+65472:11.6436;15424:3.48845;9376:2.59299;5776:2.18796;3484:1.88101;1426:1.61075;732:1.9503;257:1.95341;0:2.01467
+\endverbatim
+
+\note
+ The SimGrid-Team has developed a script to help you determine these
+ values. You can find more information and the download here:
+ 1. http://simgrid.gforge.inria.fr/contrib/smpi-calibration-doc.html
+ 2. http://simgrid.gforge.inria.fr/contrib/smpi-saturation-doc.html
+
+\subsection options_smpi_global smpi/privatize_global_variables: Automatic privatization of global variables
+
+MPI executables are meant to be executed in separated processes, but SMPI is
+executed in only one process. Global variables from executables will be placed
+in the same memory zone and shared between processes, causing hard to find bugs.
+To avoid this, several options are possible :
+ - Manual edition of the code, for example to add __thread keyword before data
+ declaration, which allows the resulting code to work with SMPI, but only
+ if the thread factory (see \ref options_virt_factory) is used, as global
+ variables are then placed in the TLS (thread local storage) segment.
+ - Source-to-source transformation, to add a level of indirection
+ to the global variables. SMPI does this for F77 codes compiled with smpiff,
+ and used to provide coccinelle scripts for C codes, which are not functional anymore.
+ - Compilation pass, to have the compiler automatically put the data in
+ an adapted zone.
+ - Runtime automatic switching of the data segments. SMPI stores a copy of
+ each global data segment for each process, and at each context switch replaces
+ the actual data with its copy from the right process. This mechanism uses mmap,
+ and is for now limited to systems supporting this functionnality (all Linux
+ and some BSD should be compatible).
+ Another limitation is that SMPI only accounts for global variables defined in
+ the executable. If the processes use external global variables from dynamic
+ libraries, they won't be switched correctly. To avoid this, using static
+ linking is advised (but not with the simgrid library, to avoid replicating
+ its own global variables).
+
+ To use this runtime automatic switching, the variable \b smpi/privatize_global_variables
+ should be set to yes
+
+
+
+\subsection options_model_smpi_detached Simulating MPI detached send
+
+This threshold specifies the size in bytes under which the send will return
+immediately. This is different from the threshold detailed in \ref options_model_network_asyncsend
+because the message is not effectively sent when the send is posted. SMPI still waits for the
+correspondant receive to be posted to perform the communication operation. This threshold can be set
+by changing the \b smpi/send_is_detached item. The default value is 65536.
+
+\subsection options_model_smpi_collectives Simulating MPI collective algorithms
+
+SMPI implements more than 100 different algorithms for MPI collective communication, to accurately
+simulate the behavior of most of the existing MPI libraries. The \b smpi/coll_selector item can be used
+ to use the decision logic of either OpenMPI or MPICH libraries (values: ompi or mpich, by default SMPI
+uses naive version of collective operations). Each collective operation can be manually selected with a
+\b smpi/collective_name:algo_name. Available algorithms are listed in \ref SMPI_collective_algorithms .
+
+\subsection options_model_smpi_iprobe smpi/iprobe: Inject constant times for calls to MPI_Iprobe
+
+\b Default value: 0.0001
+
+The behavior and motivation for this configuration option is identical with \a smpi/test, see
+Section \ref options_model_smpi_test for details.
+
+\subsection options_model_smpi_ois smpi/ois: Inject constant times for asynchronous send operations
+
+This configuration option works exactly as \a smpi/os, see Section \ref options_model_smpi_os.
+Of course, \a smpi/ois is used to account for MPI_Isend instead of MPI_Send.
+
+\subsection options_model_smpi_os smpi/os: Inject constant times for send operations
+
+In several network models such as LogP, send (MPI_Send, MPI_Isend) and receive (MPI_Recv)
+operations incur costs (i.e., they consume CPU time). SMPI can factor these costs in as well, but the
+user has to configure SMPI accordingly as these values may vary by machine.
+This can be done by using smpi/os for MPI_Send operations; for MPI_Isend and
+MPI_Recv, use \a smpi/ois and \a smpi/or, respectively. These work exactly as
+\a smpi/ois.
+
+\a smpi/os can consist of multiple sections; each section takes three values, for example:
+
+\verbatim
+ 1:3:2;10:5:1
+\endverbatim
+
+Here, the sections are divided by ";" (that is, this example contains two sections).
+Furthermore, each section consists of three values.
+
+1. The first value denotes the minimum size for this section to take effect;
+ read it as "if message size is greater than this value (and other section has a larger
+ first value that is also smaller than the message size), use this".
+ In the first section above, this value is "1".
+
+2. The second value is the startup time; this is a constant value that will always
+ be charged, no matter what the size of the message. In the first section above,
+ this value is "3".
+
+3. The third value is the \a per-byte cost. That is, it is charged for every
+ byte of the message (incurring cost messageSize*cost_per_byte)
+ and hence accounts also for larger messages. In the first
+ section of the example above, this value is "2".
+
+Now, SMPI always checks which section it should take for a given message; that is,
+if a message of size 11 is sent with the configuration of the example above, only
+the second section will be used, not the first, as the first value of the second
+section is closer to the message size. Hence, a message of size 11 incurs the
+following cost inside MPI_Send:
+
+\verbatim
+ 5+11*1
+\endverbatim
+
+%As 5 is the startup cost and 1 is the cost per byte.
+
+\note
+ The order of sections can be arbitrary; they will be ordered internally.
+
+\subsection options_model_smpi_or smpi/or: Inject constant times for receive operations
+
+This configuration option works exactly as \a smpi/os, see Section \ref options_model_smpi_os.
+Of course, \a smpi/or is used to account for MPI_Recv instead of MPI_Send.
+
+\subsection options_model_smpi_test smpi/test: Inject constant times for calls to MPI_Test
+
+\b Default value: 0.0001
+
+By setting this option, you can control the amount of time a process sleeps
+when MPI_Test() is called; this is important, because SimGrid normally only
+advances the time while communication is happening and thus,
+MPI_Test will not add to the time, resulting in a deadlock if used as a
+break-condition.
+
+Here is an example:
+
+\code{.unparsed}
+ while(!flag) {
+ MPI_Test(request, flag, status);
+ ...
+ }
+\endcode
+
+\note
+ Internally, in order to speed up execution, we use a counter to keep track
+ on how often we already checked if the handle is now valid or not. Hence, we
+ actually use counter*SLEEP_TIME, that is, the time MPI_Test() causes the process
+ to sleep increases linearly with the number of previously failed testk.
+
+
+\subsection options_model_smpi_use_shared_malloc smpi/use_shared_malloc: Use shared memory
+
+\b Default: 1
+
+SMPI can use shared memory by calling shm_* functions; this might speed up the simulation.
+This opens or creates a new POSIX shared memory object, kept in RAM, in /dev/shm.
+
+If you want to disable this behavior, set the value to 0.
+
+\subsection options_model_smpi_wtime smpi/wtime: Inject constant times for calls to MPI_Wtime
+
+\b Default value: 0
+
+By setting this option, you can control the amount of time a process sleeps
+when MPI_Wtime() is called; this is important, because SimGrid normally only
+advances the time while communication is happening and thus,
+MPI_Wtime will not add to the time, resulting in a deadlock if used as a
+break-condition.
+
+Here is an example:
+
+\code{.unparsed}
+ while(MPI_Wtime() < some_time_bound) {
+ ...
+ }
+\endcode
+
+If the time is never advanced, this loop will clearly never end as MPI_Wtime()
+always returns the same value. Hence, pass a (small) value to the smpi/wtime
+option to force a call to MPI_Wtime to advance the time as well.
+
+