- 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
+ the platform files are written in XML but a new C++ programmatic
+ interface has recently been introduced. 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
- **Design the best [Simulated] Platform for a given Application.**
Tweaking the platform file is much easier than building a new real
- platform for testing purposes. SimGrid also allows for the co-design
+ platform for testing purposes. 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
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.
+strive to double-check them. Likewise, :ref:`you should question the
+realism of your input configuration <howto_calibration>`, and we even
+encourage you to :ref:`doubt (and check) the provided performance models
+<howto_science>`.
To ease such questioning, you really should logically separate these
parts in your experimental setup. It is seen as a very bad practice to
possible platforms that you could imagine (and more).
You just provide the application and its deployment (number of
-processes and parameters), and the model checker will
+processes and parameters), and the model checker will
explore all possible outcomes by testing all possible message
interleavings: if at some point a given process can either receive the
message A first or the message B depending on the platform
SimGrid was cited in over 3,000 scientific papers (according to Google
Scholar). Among them,
-`over 500 publications <https://simgrid.org/Usages.html>`_
+`over 500 publications <https://simgrid.org/usages.html>`_
(written by hundreds of individuals) use SimGrid as a scientific
instrument to conduct their experimental evaluation. These
numbers do not include the articles contributing to SimGrid.
`Network Architecture <http://dx.doi.org/10.1109/TPDS.2016.2613043>`_,
`Fog Computing <http://ieeexplore.ieee.org/document/7946412/>`_, or
`Batch Scheduling <https://hal.archives-ouvertes.fr/hal-01333471>`_
-`(more info) <https://simgrid.org/Usages.html>`_.
+`(more info) <https://simgrid.org/usages.html>`_.
If your platform description is accurate enough (see
`here <http://hal.inria.fr/hal-00907887>`_ or
Some of these applications enjoy large user communities themselves.
.. LocalWords: SimGrid
-
