/*! @page platform Describing the virtual platform
-
-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_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 "https://simgrid.org/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
-
-
-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:
-
-
-
-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
If you want to represent an entity like a switch, you must use ``<link>`` (see section). Routers are used
to run some routing algorithm and determine routes (see Section @ref pf_routing for details).
-@subsubsection pf_tag_link <link>
-
-Network links can represent one-hop network connections. They are
-characterized by their id and their bandwidth; links can (but may not) be subject
-to latency.
-
-#### Attributes ####
-
-Attribute name | Mandatory | Values | Description
---------------- | --------- | ------ | -----------
-id | yes | string | The identifier of the link to be used when referring to it.
-bandwidth | yes | string | Maximum bandwidth for this link, along with its unit.
-latency | no | double (default: 0.0) | Latency for this link.
-sharing_policy | no | @ref sharing_policy_shared "SHARED"@|@ref pf_sharing_policy_fatpipe "FATPIPE"@|@ref pf_sharing_policy_splitduplex "SPLITDUPLEX" (default: SHARED) | Sharing policy for the link.
-bandwidth_file | no | string | Allows you to use a file as input for bandwidth.
-latency_file | no | string | Allows you to use a file as input for latency.
-state_file | no | string | Allows you to use a file as input for states.
-
-
-#### Possible shortcuts for ``latency`` ####
-
-When using the latency attribute, you can specify the latency by using the scientific
-notation or by using common abbreviations. For instance, the following three tags
-are equivalent:
-
-@verbatim
- <link id="LINK1" bandwidth="125000000" latency="5E-6"/>
- <link id="LINK1" bandwidth="125000000" latency="5us"/>
- <link id="LINK1" bandwidth="125000000" latency="0.000005"/>
-@endverbatim
-
-Here, the second tag uses "us", meaning "microseconds". Other shortcuts are:
-
-Name | Abbreviation | Time (in seconds)
----- | ------------ | -----------------
-Week | w | 7 * 24 * 60 * 60
-Day | d | 24 * 60 * 60
-Hour | h | 60 * 60
-Minute | m | 60
-Second | s | 1
-Millisecond | ms | 0.001 = 10^(-3)
-Microsecond | us | 0.000001 = 10^(-6)
-Nanosecond | ns | 0.000000001 = 10^(-9)
-Picosecond | ps | 0.000000000001 = 10^(-12)
-
-#### Sharing policy ####
-
-@anchor sharing_policy_shared
-By default a network link is @b SHARED, i.e., if two or more data flows go
-through a link, the bandwidth is shared fairly among all data flows. This
-is similar to the sharing policy TCP uses.
-
-@anchor pf_sharing_policy_fatpipe
-On the other hand, if a link is defined as a @b FATPIPE,
-each flow going through this link will be provided with the complete bandwidth,
-i.e., no sharing occurs and the bandwidth is only limiting each flow individually.
-Please note that this is really on a per-flow basis, not only on a per-host basis!
-The complete bandwidth provided by this link in this mode
-is ``number_of_flows*bandwidth``, with at most ``bandwidth`` being available per flow.
-
-Using the FATPIPE mode allows to model backbones that won't affect performance
-(except latency).
-
-@anchor pf_sharing_policy_splitduplex
-The last mode available is @b SPLITDUPLEX. This means that SimGrid will
-automatically generate two links (one carrying the suffix _UP and the other the
-suffix _DOWN) for each ``<link>`` tag. This models situations when the direction
-of traffic is important.
-
-@remark
- Transfers from one side to the other will interact similarly as
- TCP when ACK returning packets circulate on the other direction. More
- discussion about it is available in the description of link_ctn description.
-
-In other words: The SHARED policy defines a physical limit for the bandwidth.
-The FATPIPE mode defines a limit for each application,
-with no upper total limit.
-
-@remark
- Tip: By using the FATPIPE mode, you can model big backbones that
- won't affect performance (except latency).
-
-#### Example ####
-
-@verbatim
- <link id="SWITCH" bandwidth="125000000" latency="5E-5" sharing_policy="FATPIPE" />
-@endverbatim
-
-#### Expressing dynamism and failures ####
-
-Similar to hosts, it is possible to declare links whose state, bandwidth
-or latency changes over time (see Section @ref pf_host_dynamism for details).
-
-In the case of network links, the ``bandwidth`` and ``latency`` attributes are
-replaced by the ``bandwidth_file`` and ``latency_file`` attributes.
-The following XML snippet demonstrates how to use this feature in the platform
-file. The structure of the files "link1.bw" and "link1.lat" is shown below.
-
-@verbatim
-<link id="LINK1" state_file="link1.fail" bandwidth="80000000" latency=".0001" bandwidth_file="link1.bw" latency_file="link1.lat" />
-@endverbatim
-
-@note
- Even if the syntax is the same, the semantic of bandwidth and latency
- trace files differs from that of host availability files. For bandwidth and
- latency, the corresponding files do not
- express availability as a fraction of the available capacity but directly in
- bytes per seconds for the bandwidth and in seconds for the latency. This is
- because most tools allowing to capture traces on real platforms (such as NWS)
- express their results this way.
-
-##### Example of "link1.bw" file #####
-
-~~~{.py}
-PERIODICITY 12.0
-4.0 40000000
-8.0 60000000
-~~~
-
-In this example, the bandwidth changes repeatedly, with all changes
-being repeated every 12 seconds.
-
-At the beginning of the the simulation, the link's bandwidth is 80,000,000
-B/s (i.e., 80 Mb/s); this value was defined in the XML snippet above.
-After four seconds, it drops to 40 Mb/s (line 2), and climbs
-back to 60 Mb/s after another 4 seconds (line 3). The value does not change any
-more until the end of the period, that is, after 12 seconds have been simulated).
-At this point, periodicity kicks in and this behavior is repeated: Seconds
-12-16 will experience 80 Mb/s, 16-20 40 Mb/s etc.).
-
-##### Example of "link1.lat" file #####
-
-~~~{.py}
-PERIODICITY 5.0
-1.0 0.001
-2.0 0.01
-3.0 0.001
-~~~
-
-In this example, the latency varies with a period of 5 seconds.
-In the xml snippet above, the latency is initialized to be 0.0001s (100µs). This
-value will be kept during the first second, since the latency_file contains
-changes to this value at second one, two and three.
-At second one, the value will be 0.001, i.e., 1ms. One second later it will
-be adjusted to 0.01 (or 10ms) and one second later it will be set again to 1ms. The
-value will not change until second 5, when the periodicity defined in line 1
-kicks in. It then loops back, starting at 100µs (the initial value) for one second.
-
-#### The ``<prop/>`` tag ####
-
-Similar to the ``<host>`` tag, a link may also contain the ``<prop/>`` tag; see the host
-documentation (Section @ref pf_tag_host) for an example.
-
-
@subsubsection pf_backbone <backbone/>
@note
@subsection pf_tag_zone <zone>
-Before SimGrid v3.16, networking zones used to be called Autonomous
-Systems, but this was misleading as zones may include other zones in a
-hierarchical manner. If you find any remaining reference to network
-zones, please report this as a bug.
-
-Attribute | Value | Description
------------ | ------------------------------------------------- | ----------------------------------------------
-id | String (mandatory) | The identifier of this zone (must be unique)
-routing | One of the existing routing algorithm (mandatory) | See Section @ref pf_rm for details.
-
-<b>Example:</b>
-@code
-<zone id="zone0" routing="Full">
- <host id="host1" speed="1000000000"/>
- <host id="host2" speed="1000000000"/>
- <link id="link1" bandwidth="125000000" latency="0.000100"/>
- <route src="host1" dst="host2"><link_ctn id="link1"/></route>
-</zone>
-@endcode
-
-In this example, zone0 contains two hosts (host1 and host2). The route
-between the hosts goes through link1.
-
@subsection pf_rm Routing models
For each network zone, you must define explicitly which routing model will
pass through link1, and get into zone2 by being received by router2.
router1 must belong to zone1 and router2 must belong to zone2.
-@subsubsection pf_tag_linkctn <link_ctn>
-
-This entity has only one purpose: Refer to an already existing
-@ref pf_tag_link "<link/>" when defining a route, i.e., it
-can only occur as a child of @ref pf_tag_route "<route/>"
-
-| Attribute name | Mandatory | Values | Description |
-| --------------- | --------- | ------ | ----------- |
-| id | yes | String | The identifier of the link that should be added to the route. |
-| direction | maybe | UP@|DOWN | If the link referenced by @c id has been declared as @ref pf_sharing_policy_splitduplex "SPLITDUPLEX", this indicates which direction the route traverses through this link: UP or DOWN. If you don't use SPLITDUPLEX, do not use this attribute or SimGrid will not find the right link.
-
-#### Example Files ####
-
-This is an automatically generated list of example files that use the @c <link_ctn/>
-entity (the path is given relative to SimGrid's source directory):
-
-@verbinclude example_filelist_xmltag_linkctn
-
@subsubsection pf_tag_zoneroute <zoneRoute>
The purpose of this entity is to define a route between two
- @ref pf_tag_config passes configuration options, e.g. to change the network model;
- @ref pf_tag_prop gives user-defined properties to various elements
-@subsection pf_tag_config <config>
-
-Adding configuration flags into the platform file is particularly
-useful when the described platform is best used with specific
-flags. For example, you could finely tune SMPI in your platform file directly.
-
-| Attribute | Values | Description |
-| ---------- | ------------------- | ---------------------------------------------- |
-| id | String (optional) | This optional identifier is ignored by SimGrid |
-
-* **Included tags:** @ref pf_tag_prop to specify a given configuration item (see @ref options).
-
-Any such configuration must be given at the very top of the platform file.
-
-* **Example**
-
-@verbatim
-<?xml version='1.0'?>
-<!DOCTYPE platform SYSTEM "https://simgrid.org/simgrid.dtd">
-<platform version="4">
-<config>
- <prop id="maxmin/precision" value="0.000010" />
- <prop id="cpu/optim" value="TI" />
- <prop id="network/model" value="SMPI" />
- <prop id="smpi/bw-factor" value="65472:0.940694;15424:0.697866;9376:0.58729" />
-</config>
-
-<zone id="zone0" routing="Full">
-...
-@endverbatim
-
-@subsection pf_tag_prop <prop>
-
-Defines a user-defined property, identified with a name and having a
-value. You can specify such properties to most kind of resources:
-@ref pf_tag_zone, @ref pf_tag_host, @ref pf_tag_storage,
-@ref pf_tag_cluster and @ref pf_tag_link. These values can be retrieved
-at runtime with MSG_zone_property() or simgrid::s4u::NetZone::property(),
-or similar functions.
-
-| Attribute | Values | Description |
-| --------- | ---------------------- | ----------------------------------------------------------------------------------------- |
-| id | String (mandatory) | Identifier of this property. Must be unique for a given property holder, eg host or link. |
-| value | String (mandatory) | Value of this property; The semantic is completely up to you. |
-
-* **Included tags:** none.
-
-#### Example ####
-
-@code{.xml}
-<prop id="Operating System" value="Linux" />
-@endcode
-
-
@subsection pf_trace trace and trace_connect
Both tags are an alternate way to pass files containing information on
