.. _application:
+Describing your Application
+***************************
+
.. raw:: html
<object id="TOC" data="graphical-toc.svg" width="100%" type="image/svg+xml"></object>
<br/>
<br/>
-Describing your Application
-***************************
-
Every SimGrid simulation entails a distributed application, that
-virtually executes on the simulated platform. This application can
-be either an existing MPI program (if you use the SMPI interface), or
-a program specifically written to execute within SimGrid, using one of
-the dedicated APIs.
-
-.. _S4U_doc:
-
-The S4U Interface
-=================
-
-The S4U interface (SimGrid for you) mixes the full power of SimGrid
-with the full power of C++. This is the prefered interface to describe
-abstract algorithms in the domains of Cloud, P2P, HPC, IoT and similar
-settings.
-
-Main Concepts
--------------
-
-A typical SimGrid simulation is composed of several |Actors|_, that
-execute user-provided functions. The actors have to explicitly use the
-S4U interface to express their computation, communication, disk usage
-and other |Activities|_, so that they get reflected within the
-simulator. These activities take place on resources: |Hosts|_,
-|Links|_, |Storages|_ and |VirtualMachines|_. SimGrid predicts the
-time taken by each activity and orchestrates accordingly the actors
-waiting for the completion of these activities.
-
-
-Each actor executes a user-provided function on a simulated |Host|_,
-with which it can interact using the :ref:`simgrid::s4u::this_actor
-<namespace_simgrid__s4u__this_actor>` namespace. **Communications**
-are not directly sent to actors, but posted onto a |Mailbox|_ that
-serve as rendez-vous point between communicating actors. Actors can
-also interact through **classical synchronization mechanisms** such as
-|Barrier|_, |Semaphore|_, |Mutex|_ and |ConditionVariable|_.
-
-.. todo:: Add NetZone
-
-.. |Actors| replace:: **Actors**
-.. _Actors: api/classsimgrid_1_1s4u_1_1Actor.html
-
-.. |Activities| replace:: **Activities**
-.. _Activities: api/classsimgrid_1_1s4u_1_1Activity.html
-
-.. |Hosts| replace:: **Hosts**
-.. _Hosts: api/classsimgrid_1_1s4u_1_1Host.html
-
-.. |Links| replace:: **Links**
-.. _Links: api/classsimgrid_1_1s4u_1_1Link.html
-
-.. |Storages| replace:: **Storages**
-.. _Storages: api/classsimgrid_1_1s4u_1_1Storage.html
-
-.. |VirtualMachines| replace:: **VirtualMachines**
-.. _VirtualMachines: api/classsimgrid_1_1s4u_1_1VirtualMachine.html
-
-.. |Host| replace:: **Host**
-.. _Host: api/classsimgrid_1_1s4u_1_1Host.html
-
-.. |Mailbox| replace:: **Mailbox**
-.. _Mailbox: api/classsimgrid_1_1s4u_1_1Mailbox.html
-
-.. |Barrier| replace:: **Barrier**
-.. _Barrier: api/classsimgrid_1_1s4u_1_1Barrier.html
-
-.. |ConditionVariable| replace:: **ConditionVariable**
-.. _ConditionVariable: api/classsimgrid_1_1s4u_1_1ConditionVariable.html
-
-.. |Mutex| replace:: **Mutex**
-.. _Mutex: api/classsimgrid_1_1s4u_1_1Mutex.html
-
-
-.. include:: app_smpi.rst
-
-.. include:: app_legacy.rst
+virtually executes on the simulated platform. You can express this
+application using one of the following interfaces. It is even possible
+to mix several interfaces in the same simulation.
+
+ - :ref:`Describing Algorithms with the S4U interface <S4U_doc>` (in C++)
+ - :ref:`Simulating existing MPI programs with the SMPI toolsuite <SMPI_doc>`
+ (in C, C++, or Fortran)
+ - In some cases, you may want to replay an execution trace in the simulator. This
+ trace lists the events of your application or of your workload, and
+ your application is decomposed as a list of event handlers that are
+ fired according to the trace. SimGrid comes with a build-in support
+ for MPI traces (with solutions to import traces captured by several
+ MPI profilers). You can reuse this mecanism for any kind of trace
+ that you want to replay, for example to study how a P2P DHT overlay
+ reacts to a given workload.
+ - Simulating algorithms with one of the legacy interfaces: :ref:`MSG
+ for distributed algorithms <MSG_doc>` (in :ref:`C <MSG_doc>` or
+ :ref:`Java <Java_doc>`) and SimDAG for
+ centralized algorithms (in C). SimGrid was founded in 1998, and
+ many interfaces were proposed along the way. MSG (introduced
+ around 2002) and SimDag (introduced before 2000), are still present
+ in SimGrid. They do not evolve anymore, but given their popularity,
+ they will not be removed until at least 2020. That being said, our
+ goal is to make S4U so useful that these legacy APIs become useless
+ and obsolete.
+ - We are currently working on the ability to modify any existing
+ application so that it can run on top of SimGrid. This project,
+ called `Remote-SimGrid
+ <git@framagit.org:simgrid/remote-simgrid.git>`_, is highly
+ experimental at this point.
+
+As you can see, SimGrid is very modular and can be used in many
+ways. We are working to improve it along two main directions. First,
+we plan to further increase the modularity of the simulator so that
+users can invent the specific API or DSL they need for their usage. We
+call this project BYOS: Build Your Own Simulator.
+
+Executing existing applications within the simulator is another
+long-term goal. SMPI and Remote-SimGrid already allow you to execute some
+applications, but our long term goal would be to allow for the execution
+of any legacy application, with absolutely no modification. We call it
+SimOS, even if it will not become usable before several years of
+additional work.
+
+.. The old documentation of the obsolete MSG replay module was removed in
+.. https://github.com/simgrid/simgrid/commit/e05361c201fb95d2b7605e59001cd0a49a489739
