-
-@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 4.1. 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}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-@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:
-
-
-
-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)
-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}
-
-
-
-
-
-@endcode
-
-@anchor pf_host_dynamism
-### Expressing dynamism ###
-
-SimGrid provides mechanisms to change a hosts' availability over
-time, using the ``availability_file`` attribute to the ``@`` tag
-and a separate text file whose syntax is exemplified below.
-
-#### Adding a trace file ####
-
-@verbatim
-
-
-
-@endverbatim
-
-#### Example of "bob.trace" file ####
-
-~~~~~~~~~~~~~~{.py}
-PERIODICITY 1.0
- 0.0 1.0
- 11.0 0.5
- 20.0 0.8
-~~~~~~~~~~~~~~
-
-Let us begin to explain this example by looking at line 2. (Line 1 will become clear soon).
-The first column describes points in time, in this case, time 0. The second column
-describes the relative amount of power this host is able to deliver (relative
-to the maximum performance specified in the ``@`` tag). (Clearly, the
-second column needs to contain values that are not smaller than 0 and not larger than 1).
-In this example, our host will deliver 500 Mflop/s at time 0, as 500 Mflop/s is the
-maximum performance of this host. At time 11.0, it will
-deliver half of its maximum performance, i.e., 250 Mflop/s until time 20.0 when it will
-will start delivering 80@% of its power. In this example, this amounts to 400 Mflop/s.
-
-Since the periodicity in line 1 was set to be 1.0, i.e., 1 timestep, this host will
-continue to provide 500 Mflop/s from time 21. From time 32 it will provide 250 MFlop/s and so on.
@subsubsection pf_tag_cluster <cluster>
@@ -338,40 +159,6 @@ The hosts generated in the above example are named host-1.cluster, host-2.cluste
etc.
-@subsubsection pf_peer <peer> (Vivaldi netzones only)
-
-This tag represents a peer, as in Peer-to-Peer (P2P) networks. This
-can only be used in Vivaldi NetZones. It creates the following
-resources to the NetZone:
-
-@li A host
-@li Two links: One for download and one for upload. This is
- convenient to use and simulate stuff under the last mile model (e.g., ADSL peers).
-@li It connects the two links to the host
-
-#### Attributes ####
-
-Attribute name | Mandatory | Values | Description
---------------- | --------- | ------ | -----------
-id | yes | string | The identifier of the peer. Facilitates referring to this peer.
-speed | yes | int | See the description of the ``host`` tag for this attribute
-bw_in | yes | int | Bandwidth of the private downstream link
-bw_out | yes | int | Bandwidth of the private upstream link
-coordinates | no | string | Coordinates of the gateway for this peer. Example value: 12.8 14.4 6.4
-sharing_policy | no | SHARED@|SPLITDUPLEX (default: SPLITDUPLEX) | Sharing policy for links. See link description for details.
-availability_file| no | string | Availability file for the peer. Same as host availability file. See host description for details.
-state_file | no | string | State file for the peer. Same as host state file. See host description for details.
-
-
-The communication latency between an host A=(xA,yA,zA) and an host
-B=(xB,yB,zB) is computed as follows:
-
- latency = sqrt( (xA-xB)² + (yA-yB)² ) + zA + zB
-
-See the documentation of simgrid::kernel::routing::VivaldiZone for
-details on how the latency is computed from the coordinate, and on the
-the up and down bandwidth are used.
-
@subsection pf_ne Network equipments
There are two tags at all times available to represent network entities and
@@ -398,24 +185,6 @@ several other tags that are available only in certain contexts.
If you want to represent an entity like a switch, you must use ```` (see section). Routers are used
to run some routing algorithm and determine routes (see Section @ref pf_routing for details).
-@subsubsection pf_router <router/>
-
-As said before, router is used only to give some information
-for routing algorithms. So, it does not have any attributes except:
-
-#### Attributes ####
-
-Attribute name | Mandatory | Values | Description
---------------- | --------- | ------ | -----------
-id | yes | string | The identifier of the router to be used when referring to it.
-coordinates | no | string | Must be provided when choosing the Vivaldi, coordinate-based routing model for the network zone the router belongs to. More details can be found in the Section @ref pf_P2P_tags.
-
-#### Example ####
-
-@verbatim
-
-@endverbatim
-
@subsubsection pf_tag_link <link>
Network links can represent one-hop network connections. They are
@@ -870,29 +639,6 @@ the shortest paths.
@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.
-
-Example:
-@code
-
-
-
-
-
-
-@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
@@ -1448,7 +1194,7 @@ Any such configuration must be given at the very top of the platform file.
@verbatim
-
+
@@ -1663,7 +1409,7 @@ complicated in using it, here is an example:
@verbatim
-
+
@@ -1690,7 +1436,7 @@ Note that the previous example defines a routing directly between hosts but it c
That is for example what is commonly done when using peers (see Section @ref pf_peer).
@verbatim
-
+