-@tableofcontents
-
-@htmlonly
-<div align="center">
-@endhtmlonly
-@htmlinclude graphical-toc.svg
-@htmlonly
-</div>
-<script>
-document.getElementById("VirtualPlatform").style="opacity:0.93999999;fill:#ff0000;fill-opacity:0.1;stroke:#000000;stroke-width:0.35277778;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1";
-</script>
-@endhtmlonly
-
-As @ref starting_components "explained in the introduction," any
-SimGrid study must entail the description of the platform on which you
-want to simulate your application. You have to describe **each element
-of your platform**, such as computing hosts, clusters, each disks,
-links, etc. You must also define the **routing on your platform**, ie
-which path is taken between two hosts. Finally, you may also describe
-an **experimental scenario**, with qualitative changes (e.g.,
-bandwidth changes representing an external load) and qualitative
-changes (representing how some elements fail and restart over time).
-
-You should really separate your application from the platform
-description, as it will ease your experimental campain afterward.
-Mixing them is seen as a really bad experimental practice. The easiest
-to enforce this split is to put the platform description in a XML
-file. Many example platforms are provided in the archive, and this
-page gives all needed details to write such files, as well as some
-hints and tricks about describing your platform.
-
-On the other side, XML is sometimes not expressive enough for some
-platforms, in particular large platforms exhibiting repetitive
-patterns that are not simply expressed in XML. In practice, many
-users end up generating their XML platform files from some sort of
-scripts. It is probably preferable to rewrite your XML @ref
-platform_lua "platform using the lua scripting language" instead.
-In the future, it should be possible to describe the platform directly
-in C++, but this is not possible yet.
-
-As usual, SimGrid is a versatile framework, and you should find the
-way of describing your platform that best fits your experimental
-practice.
-
-@section pf_overview Describing the platform with XML
-
-Your platform description should follow the specification presented in
-the [simgrid.dtd](http://simgrid.gforge.inria.fr/simgrid/simgrid.dtd)
-DTD file. The same DTD is used for both the platform and deployment
-files.
-
-From time to time, this DTD evolves to introduce possibly
-backward-incompatible changes. That is why each platform desciption is
-enclosed within a @c platform tag, that have a @c version attribute.
-The current version is <b>4.1</b>. The @c simgrid_update_xml program can
-upgrade most of the past platform files to the recent formalism.
-
-@section pf_first_example First Platform Example
-
-Here is a very simple platform file, containing 3 resources (two hosts
-and one link), and explicitly giving the route between the hosts.
-
-@code{.xml}
-<?xml version='1.0'?>
-<!DOCTYPE platform SYSTEM "http://simgrid.gforge.inria.fr/simgrid/simgrid.dtd">
-<platform version="4.1">
- <zone id="first zone" routing="Full">
- <!-- the resources -->
- <host id="host1" speed="1Mf"/>
- <host id="host2" speed="2Mf"/>
- <link id="link1" bandwidth="125MBps" latency="100us"/>
- <!-- the routing: specify how the hosts are interconnected -->
- <route src="host1" dst="host2">
- <link_ctn id="link1"/>
- </route>
- </zone>
-</platform>
-@endcode
-
-As we said, the englobing @ref pf_overview "<platform>" tag is
-used to specify the dtd version used for this file.
-
-Then, every resource (specified with @ref pf_tag_host, @ref
-pf_tag_link or others) must be located within a given **networking
-zone**. Each zone is in charge of the routing between its
-resources. It means that when an host wants to communicate with
-another host of the same zone, it is the zone's duty to find the list
-of links that are involved in the communication. Here, since the @ref
-pf_tag_zone tag has **Full** as a **routing attribute**, all routes
-must be explicitely given using the @ref pf_tag_route and @ref
-pf_tag_linkctn tags (this @ref pf_rm "routing model" is both simple
-and inefficient :) It is OK to not specify the route between two
-hosts, as long as the processes located on them never try to
-communicate together.
-
-A zone can contain several zones itself, leading to a hierarchical
-decomposition of the platform. This can be more efficient (as the
-inter-zone routing gets factorized with @ref pf_tag_zoneroute), and
-allows to have more than one routing model in your platform. For
-example, you could have a coordinate-based routing for the WAN parts
-of your platforms, a full routing within each datacenter, and a highly
-optimized routing within each cluster of the datacenter. In this
-case, determining the route between two given hosts gets @ref
-routing_basics "somewhat more complex" but SimGrid still computes
-these routes for you in a time- and space-efficient manner.
-Here is an illustration of these concepts:
-
-![A hierarchy of networking zones.](AS_hierarchy.png)
-
-Circles represent processing units and squares represent network
-routers. Bold lines represent communication links. The zone "AS2"
-models the core of a national network interconnecting a small flat
-cluster (AS4) and a larger hierarchical cluster (AS5), a subset of a
-LAN (AS6), and a set of peers scattered around the world (AS7).