-/*! \page platform Describing the virtual platform
-
-@tableofcontents
-
-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).
-
-\section pf_res Resource description
-
-\subsection pf_res_computing Computing Resources
-
-\subsubsection pf_tag_host <host>
-
-An host is the computing resource on which an actor can execute.
-
-Attribute | Values | Description
------------------ | -------------------------------------- | -----------
-id | String (mandatory) | The identifier of the host. facilitates referring to this AS.
-speed | double (mandatory) | Computational power of every core of this host in FLOPS (must be positive)
-core | int (defaults to 1) | Number of cores (see @ref howto_multicore)
-state | optionally "OFF" | If set to OFF, the host is initially turned off.
-availability_file | File name (optional) | (Relative or absolute) filename to use as input; must contain availability traces for this host. The syntax of this file is defined below.
-state_file | File name (optional) | File to use as a state profile (see @ref howto_churn)
-coordinates | String (mandatory when using Vivaldi routing) | The coordinates of this host (see @ref pf_P2P_tags).
-pstate | Double (Defaults to 0) | FIXME: Not yet documented.
-
-#### Included tags ####
-
- - @ref pf_tag_mount Specifies the storages mounted on that host
- - @ref pf_tag_prop Specifies a user-defined property of that host, that you can retrieve with MSG_host_get_property_value() or simgrid::s4u::Host::property().
-
-#### Examples ####
-
-\code{.xml}
-<host id="host1" speed="1000000000"/>
-<host id="host2" speed="1000000000">
- <prop id="color" value="blue"/>
- <prop id="rendershape" value="square"/>
-</host>
-\endcode