-Typical Study based on SimGrid
-------------------------------
-
-Any SimGrid study entails the following components:
-
- - The studied **Application**. This can be either a distributed
- algorithm described in our simple APIs, or a full featured real
- parallel application using for example the MPI interface
- :ref:`(more info) <application>`.
-
- - The **Simulated Platform**. This is a description of a given
- distributed system (machines, links, disks, clusters, etc). Most of
- the platform files are written in XML although a Lua interface is
- under development. SimGrid makes it easy to augment the Simulated
- Platform with a Dynamic Scenario where for example the links are
- slowed down (because of external usage) or the machines fail. You
- even have support to specify the applicative workload that you want
- to feed to your application
- :ref:`(more info) <platform>`.
-
- - The application's **Deployment Description**. In SimGrid
- terminology, the application is an inert set of source files and
- binaries. To make it run, you have to describe how your application
- should be deployed on the simulated platform. You need to specify
- which process is mapped onto which machine, along with their parameters
- :ref:`(more info) <scenario>`.
-
- - The **Platform Models**. They describe how the simulated platform
- reacts to the actions of the application. For example, they compute
- the time taken by a given communication on the simulated platform.
- These models are already included in SimGrid, and you only need to
- pick one and maybe tweak its configuration to get your results
- :ref:`(more info) <models>`.
-
-These components are put together to run a **simulation**, that is an
-experiment or a probe. The result of one or many simulation provides
-an **outcome** (logs, visualization, or statistical analysis) that help
-answering the **question** targeted by this study.
-
-Here are some questions on which SimGrid is particularly relevant:
-
- - **Compare an Application to another**. This is the classical use
- case for scientists, who use SimGrid to test how the solution that
- they contribute to compares to the existing solutions from the
- literature.
-
- - **Design the best [Simulated] Platform for a given Application.**
- Tweaking the platform file is much easier than building a new real
- platform for testing purpose. SimGrid also allows for the co-design
- of the platform and the application by modifying both of them.
-
- - **Debug Real Applications**. With real systems, is sometimes
- difficult to reproduce the exact run leading to the bug that you
- are tracking. With SimGrid, you are *clairvoyant* about your
- *reproducible experiments*: you can explore every part of the
- system, and your probe will not change the simulated state. It also
- makes it easy to mock some parts of the real system that are not
- under study.
-
-Depending on the context, you may see some parts of this process as
-less important, but you should pay close attention if you want to be
-confident in the results coming out of your simulations. In
-particular, you should not blindly trust your results but always
-strive to double-check them. Likewise, you should question the realism
-of your input configuration, and we even encourage you to doubt (and
-check) the provided performance models.
-
-To ease such questioning, you really should logically separate these
-parts in your experimental setup. It is seen as a very bad practice to
-merge the application, the platform, and the deployment all together.
-SimGrid is versatile and your mileage may vary, but you should start
-with your Application specified as a C++ or Java program, using one of
-the provided XML platform file, and with your deployment in a separate
-XML file.
-
-SimGrid Execution Modes
------------------------