-/*! \page platform Describing the virtual platform
-
-@tableofcontents
-
-In order to run any simulation, SimGrid must be provided with three things:
-something to run (i.e., your code), a description of the platform on which you want to simulate your application, and
-information about the deployment of the application: Which process should be executed onto which processor/core?
-
-For the last two items, there are essentially three possible ways you can provide
-this information as an input:
-\li You can program, if you're using MSG, some of the platform and
- deployment functions. If you choose to follow this approach, check the dedicated documentation
- (\ref msg_simulation).
-\li You can use two XML files: one for the platform description and the other for the deployment.
-\li You can program the description of your platform in Lua format.
-
-For more information on SimGrid's deployment features, please refer to the \ref deployment section.
-
-The platform description may be intricate. This documentation is all about how to write this file. First, the basic
-concepts are introduced. Then, advanced options are explained. Finally, some hints and tips on how to write a better
-platform description are given.
-
-\section pf_overview Some words about XML and DTD
-
-We opted for XML not only because it is extensible but also because many tools (and plugins for existing tools) are
-available that facilitate editing and validating XML files. Furthermore, libraries that parse XML are often already
-available and very well tested.
-
-The XML checking is done based on the [simgrid.dtd](http://simgrid.gforge.inria.fr/simgrid/simgrid.dtd) Document Type
-Definition (DTD) file.
-
-If you read the DTD, you should notice the following:
-\li The platform tag has a version attribute. The current version is <b>4</b>. This attribute might be used in the
- provide backward compatibility.
-\li The DTD contains definitions for both the platform description and deployment files used by SimGrid.
-
-\section pf_basics Basic concepts
-
-It is certainly very tempting to defining how the information is
-routed in the simulated network in a way that is very similar to how
-it is defined on real network. One would have to define the routing
-tables of each routers interconnections sub-networks, just like in the
-real life. Given the daunting amount of configuration required, we
-could complete the information given by the user with classical
-protocols such as BGP and RIP. Many network simulator take such
-configuration as an input, for good reasons.
-
-This is not the way it goes in SimGrid: the network routing is defined
-in a global and compact way instead. This eases the modeling of very
-large systems, and allows highly optimized datastructures and
-algorithms in the simulator. The proposed description mechanism is
-thus much more convinient and efficient. In addition, it is more
-expressive than the classical solution based on forwarding tables on
-each host and router.
-
-The price to pay is that this representation of networks is very
-specific to SimGrid, so you will have to read further to understand
-it, even if you already know how real networks work.
-
-The central notion here are \b Networking \b Zones. NetZones represent
-network areas in which the routing is done in an homogeneous way.
-Conceptually, netzones generalize from the ideas of local networks
-(such as Ethernet switched networks) and Autonomous System. The
-network as a whole is represented as a single hierarchy of netzones,
-meaning that every netzone is part of another netzone (but the \c
-NetRoot, which is the top-level netzone).
-
-The main goal of the routing module is to provide a list of links
-traversed by a given communication and/or a latency to apply. These
-information are then used by the network model to compute the time
-that this communication takes. This information is retrieved by three
-combined algorithms: intra-zone routing, inter-zone routing, and the
-bypass mechanism.
-
-The <b>intra-zone level</b> is naturally handled by the netzones. Each
-netzone have to specify the routing algorithm it uses for that.
-@ref{FullZone} netzones have complete matrix where matrix(a,b)
-represents the full path (the list of links) between the hosts a and
-b. @ref{FloydZone} apply the Floyd-Warshall algorithm to compute the
-paths. @ref{ClusterZone} model classical switched or hub networks,
-where each component is connected through a private link onto a common
-backbone. Many other routing algorithms are provided to model the
-classical needs, but you can naturally define your own routing if the
-provided ones do not fit your needs.
-
-The <b>inter-zone algorithm</b> is used when the communication
-traverses more than one zone. The overall path goes from the source up
-in the netzones' tree, until the first common ancestor zone, and moves
-down to the destination. It crawls the differing netzones on its path
-according to the user-defined inter-zone routes, moving from gateway
-to gateway.
-
-You can also use the <b>bypass mechanism</b> to specify manually some
-shortcuts that directly provide the list of links interconnecting two
-given processes.
-
-
-\verbatim
-<AS id="netzone0" routing="Full">
-\endverbatim
-
-\remark
- Other supported values for the routing attribute can be found below, Section
- \ref pf_raf.
-
-There is also the ``<route>`` tag; this tag takes two attributes,
-``src`` (source) and ``dst`` (destination). Both source and
-destination must be valid identifiers for routers (these will be
-introduced later). Contained by the ``<route>`` are network links;
-these links must be used in order to communicate from the source to
-the destination specified in the tag. Hence, a route merely describes
-how to reach a router from another router.
-
-\remark
- More information and (code-)examples can be found in Section \ref pf_rm.
-
-A netzone can also contain itself one or more netzone; this allows you to model
-the hierarchy of your platform.
-
-### Within each AS, the following types of resources exist:
-
-%Resource | Documented in Section | Description
---------------- | --------------------- | -----------
-AS | | Every Autonomous System (AS) may contain one or more AS.
-host | \ref pf_host | This entity carries out the actual computation. For this reason, it contains processors (with potentially multiple cores).
-router | \ref pf_router | In SimGrid, routers are used to provide helpful information to routing algorithms. Routers may also act as gateways, connecting several autonomous systems with each other.
-link | \ref pf_link | In SimGrid, (network)links define a connection between two or potentially even more resources. Every link has a bandwidth and a latency and may potentially experience congestion.
-cluster | \ref pf_cluster | In SimGrid, clusters were introduced to model large and homogenous environments. They are not really a resource by themselves - technically, they are only a shortcut, as they will internally set up all the hosts, network and routing for you, i.e., using this resource, one can easily setup thousands of hosts and links in a few lines of code. Each cluster is itself an AS.
-
-As it is desirable to interconnect these resources, a routing has to
-be defined. The AS is supposed to be Autonomous, hence this has to be
-done at the AS level. The AS handles two different types of entities
-(<b>host/router</b> and <b>AS</b>). However, the user is responsible
-to define routes between those resources, otherwise entities will be
-unconnected and therefore unreachable from other entities. Although
-several routing algorithms are built into SimGrid (see \ref pf_rm),
-you might encounter a case where you want to define routes manually
-(for instance, due to specific requirements of your platform).
-
-There are three tags to use:
-\li <b>ASroute</b>: to define routes between two <b>AS</b>
-\li <b>route</b>: to define routes between two <b>host/router</b>
-\li <b>bypassRoute</b>: to define routes between two <b>AS</b> that
- will bypass default routing (as specified by the ``routing`` attribute
- supplied to ``<AS>``, see above).
-
-Here is an illustration of these concepts:
-
-![An illustration of an AS hierarchy. Here, AS1 contains 5 other ASes who in turn may contain other ASes as well.](AS_hierarchy.png)
- Circles represent processing units and squares represent network routers. Bold
- lines represent communication links. 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_pftags Resource description
-
-\subsection pf_As Platform: The <AS> tag
-
-The concept of an AS was already outlined above (Section \ref pf_basics);
-recall that the AS is so important because it groups other resources (such
-as routers/hosts) together (in fact, these resources must be contained by
-an AS).
-
-Available attributes :