X-Git-Url: http://bilbo.iut-bm.univ-fcomte.fr/pub/gitweb/simgrid.git/blobdiff_plain/07bbfcd413a23fc08a64cda92000b045c6db8e60..639c6962daa378323864a53174e0e7fe2fcaef1e:/docs/source/application.rst?ds=sidebyside

diff --git a/docs/source/application.rst b/docs/source/application.rst
index fc1eb63136..499465af93 100644
--- a/docs/source/application.rst
+++ b/docs/source/application.rst
@@ -1,8 +1,11 @@
 .. _application:
 
+Describing your Application
+***************************
+
 .. raw:: html
 
-   <object id="TOC" data="graphical-toc.svg" width="100%" type="image/svg+xml"></object>
+   <object id="TOC" data="graphical-toc.svg" type="image/svg+xml"></object>
    <script>
    window.onload=function() { // Wait for the SVG to be loaded before changing it
      var elem=document.querySelector("#TOC").contentDocument.getElementById("ApplicationBox")
@@ -12,136 +15,37 @@
    <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
-:ref:`computation <exhale_class_classsimgrid_1_1s4u_1_1Exec>`,
-:ref:`communication <exhale_class_classsimgrid_1_1s4u_1_1Comm>`,
-:ref:`disk usage <exhale_class_classsimgrid_1_1s4u_1_1Io>`,
-and other |Activities|_, so that they get reflected within the
-simulator. These activities take place on resources such as |Hosts|_,
-|Links|_ and |Storages|_. SimGrid predicts the time taken by each
-activity and orchestrates accordingly the actors waiting for the
-completion of these activities.
-
-
-When **communicating**, data is not directly sent to other actors but
-posted onto a |Mailbox|_ that serve as rendez-vous point between
-communicating actors. This means that you don't need to know who you
-are talking to, you just put your communication `Send` request in a
-mailbox, and it will be matched with a complementary `Receive`
-request.  Alternatively, actors can interact through **classical
-synchronization mechanisms** such as |Barrier|_, |Semaphore|_,
-|Mutex|_ and |ConditionVariable|_.
-
-Each actor is located on a simulated |Host|_. Each host is located
-itself in a |NetZone|_, that route communications through the
-links. Each NetZone is included in another one, forming a tree of
-NetZones which root zone contains the whole platform.
-
-The :ref:`simgrid::s4u::this_actor
-<namespace_simgrid__s4u__this_actor>` namespace provides many helper
-functions to simplify the code of actors.
-
-- **Global Classes**
-
-  - :ref:`class s4u::Actor <exhale_class_classsimgrid_1_1s4u_1_1Actor>`:
-    Active entities executing your application.
-  - :ref:`class s4u::Engine <exhale_class_classsimgrid_1_1s4u_1_1Engine>`
-    Simulation engine (singleton).
-  - :ref:`class s4u::Mailbox <exhale_class_classsimgrid_1_1s4u_1_1Mailbox>`
-    Communication rendez-vous.
-
-- **Platform Elements**
-
-  - :ref:`class s4u::Host <exhale_class_classsimgrid_1_1s4u_1_1Host>`:
-    Actor location, providing computational power.
-  - :ref:`class s4u::Link <exhale_class_classsimgrid_1_1s4u_1_1Link>`
-    Interconnecting hosts.
-  - :ref:`class s4u::NetZone <exhale_class_classsimgrid_1_1s4u_1_1NetZone>`:
-    Sub-region of the platform, containing resources (Hosts, Link, etc).
-  - :ref:`class s4u::Storage <exhale_class_classsimgrid_1_1s4u_1_1Storage>`
-    Resource on which actors can write and read data.
-  - :ref:`class s4u::VirtualMachine <exhale_class_classsimgrid_1_1s4u_1_1VirtualMachine>`:
-    Execution containers that can be moved between Hosts.
-
-- **Activities** (:ref:`class s4u::Activity <exhale_class_classsimgrid_1_1s4u_1_1Activity>`):
-  The things that actors can do on resources
-
-  - :ref:`class s4u::Comm <exhale_class_classsimgrid_1_1s4u_1_1Comm>`
-    Communication activity, started on Mailboxes and consuming links.
-  - :ref:`class s4u::Exec <exhale_class_classsimgrid_1_1s4u_1_1Exec>`
-    Computation activity, started on Host and consuming CPU resources.
-  - :ref:`class s4u::Io <exhale_class_classsimgrid_1_1s4u_1_1Io>`
-    I/O activities, started on and consumming Storages.
-
-- **Synchronization Mechanisms**: Classical IPC that actors can use
-
-  - :ref:`class s4u::Barrier <exhale_class_classsimgrid_1_1s4u_1_1Barrier>`
-  - :ref:`class s4u::ConditionVariable <exhale_class_classsimgrid_1_1s4u_1_1ConditionVariable>`
-  - :ref:`class s4u::Mutex <exhale_class_classsimgrid_1_1s4u_1_1Mutex>`
-  - :ref:`class s4u::Semaphore <exhale_class_classsimgrid_1_1s4u_1_1Semaphore>`
-
-
-.. |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
-
-.. |NetZone| replace:: **NetZone**
-.. _NetZone: api/classsimgrid_1_1s4u_1_1NetZone.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++ or Python)
+ - :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 built-in support
+   for MPI traces (with solutions to import traces captured by several
+   MPI profilers). You can reuse this mechanism for any kind of trace
+   that you want to replay, for example to study how a P2P DHT overlay
+   reacts to a given workload.
+ - A prototypal tool is intended to allow the modification of any existing
+   application so that it can run on top of SimGrid. This project,
+   called `Remote-SimGrid
+   <https://framagit.org/simgrid/remote-simgrid>`_, is somewhat
+   experimental but should be already usable.
+
+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.