@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
bb_bw | no | int | Bandwidth for backbone (if any). See <b>link</b> section for syntax/details. If bb_bw and bb_lat (see below) attributes are omitted, no backbone is created (alternative cluster architecture <b>described before</b>).
bb_lat | no | int | Latency for backbone (if any). See <b>link</b> section for syntax/details. If bb_lat and bb_bw (see above) attributes are omitted, no backbone is created (alternative cluster architecture <b>described before</b>).
bb_sharing_policy | no | string | Sharing policy for the backbone (if any). See <b>link</b> section for syntax/details.
-limiter_link | no | int | Bandwidth for limiter link (if any). This adds a specific link for each node, to set the maximum bandwidth reached when communicating in both directions at the same time. In theory this value should be 2*bw for
fullduplex links, but in reality this might be less. This value will depend heavily on the communication model, and on the cluster's hardware, so no default value can be set, this has to be measured. More details can be obtained in <a href="https://hal.inria.fr/hal-00919507/"> "Toward Better Simulation of MPI Applications on Ethernet/TCP Networks"</a>
+limiter_link | no | int | Bandwidth for limiter link (if any). This adds a specific link for each node, to set the maximum bandwidth reached when communicating in both directions at the same time. In theory this value should be 2*bw for
splitduplex links, but in reality this might be less. This value will depend heavily on the communication model, and on the cluster's hardware, so no default value can be set, this has to be measured. More details can be obtained in <a href="https://hal.inria.fr/hal-00919507/"> "Toward Better Simulation of MPI Applications on Ethernet/TCP Networks"</a>
loopback_bw | no | int | Bandwidth for loopback (if any). See <b>link</b> section for syntax/details. If loopback_bw and loopback_lat (see below) attributes are omitted, no loopback link is created and all intra-node communication will use the main network link of the node. Loopback link is a \ref pf_sharing_policy_fatpipe "\b FATPIPE".
loopback_lat | no | int | Latency for loopback (if any). See <b>link</b> section for syntax/details. See loopback_bw for more info.
topology | no | FLAT\|TORUS\|FAT_TREE\|DRAGONFLY (default: FLAT) | Network topology to use. SimGrid currently supports FLAT (with or without backbone, as described before), <a href="http://en.wikipedia.org/wiki/Torus_interconnect">TORUS </a>, FAT_TREE, and DRAGONFLY attributes for this tag.
\note
Please note that as of now, it is impossible to change attributes such as,
amount of cores (always set to 1), the initial state of hosts/links
- (always set to ON), the sharing policy of the links (always set to \ref pf_sharing_policy_fullduplex "FULLDUPLEX").
+ (always set to ON), the sharing policy of the links (always set to \ref pf_sharing_policy_splitduplex "SPLITDUPLEX").
#### Example ####
etc.
-\subsubsection pf_peer \<peer\> (Vivaldi netzones only)
+\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
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\|FULLDUPLEX (default: FULLDUPLEX) | Sharing policy for links. See <b>link</b> description for details.
+sharing_policy | no | SHARED\|SPLITDUPLEX (default: SPLITDUPLEX) | Sharing policy for links. See <b>link</b> description for details.
availability_file| no | string | Availability file for the peer. Same as host availability file. See <b>host</b> description for details.
state_file | no | string | State file for the peer. Same as host state file. See <b>host</b> description for details.
\subsubsection pf_router <router/>
As said before, <b>router</b> is used only to give some information
-for routing algorithms. So, it does not have any attributes except :
+for routing algorithms. So, it does not have any attributes except:
#### Attributes ####
id | yes | string | The identifier of the link to be used when referring to it.
bandwidth | yes | int | Maximum bandwidth for this link, given in bytes/s
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_fullduplex "FULLDUPLEX" (default: SHARED) | Sharing policy for the 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.
state | no | ON\|OFF (default: ON) | Allows you to to turn this link on or off (working / not working)
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.
Using the FATPIPE mode allows to model backbones that won't affect performance
(except latency).
-\anchor pf_sharing_policy_fullduplex
-The last mode available is \b FULLDUPLEX. This means that SimGrid will
+\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.
Entity name | Description
--------------- | -----------
\ref pf_storage_entity_storage_type "storage_type" | Defines a template for a particular kind of storage (such as a hard-drive) and specifies important features of the storage, such as capacity, performance (read/write), contents, ... Different models of hard-drives use different storage_types (because the difference between an SSD and an HDD does matter), as they differ in some specifications (e.g., different sizes or read/write performance).
-\ref pf_storage_entity_storage "storage" | Defines an actual instance of a storage type (disk, RAM, ...); uses a ``storage_type`` template (see line above) so that you don't need to re-specify the same details over and over again.
+\ref pf_tag_storage "storage" | Defines an actual instance of a storage type (disk, RAM, ...); uses a ``storage_type`` template (see line above) so that you don't need to re-specify the same details over and over again.
\ref pf_tag_mount "mount" | Must be wrapped by a \ref pf_tag_host tag; declares which storage(s) this host has mounted and where (i.e., the mountpoint).
| Attribute | Mandatory | Values | Description |
| ----------- | ----------- | -------- | ------------- |
-| id | yes | string | Refers to a \ref pf_storage_entity_storage "<storage>" entity that will be mounted on that computer |
+| id | yes | string | Refers to a \ref pf_tag_storage "<storage>" entity that will be mounted on that computer |
| name | yes | string | Path/location to/of the logical reference (mount point) of this disk
This tag must be enclosed by a \ref pf_tag_host tag. It then specifies where the mountpoint of a given storage device (defined by the ``id`` attribute)
This example is quite interesting, as the same device, called "Disk2", is mounted by
two hosts at the same time! Note, however, that the host called ``alice`` is actually
-attached to this storage, as can be seen in the \ref pf_storage_entity_storage "<storage>"
+attached to this storage, as can be seen in the \ref pf_tag_storage "<storage>"
tag. This means that ``denise`` must access this storage through the network, but SimGrid automatically takes
care of that for you.
\endverbatim
An easy way to model this scenario is to setup and define the RAM via the
-\ref pf_storage_entity_storage "storage" and \ref pf_storage_entity_storage_type "storage type"
+\ref pf_tag_storage "storage" and \ref pf_storage_entity_storage_type "storage type"
entities and attach it to a remote dummy host; then, every host can have their own links
to this host (modelling for instance certain scenarios, such as PCIe ...)
\verbinclude example_filelist_routing_dijkstra
-Dijkstra example :
+Dijkstra example:
\verbatim
<zone id="zone_2" routing="Dijkstra">
<host id="zone_2_host1" speed="1000000000"/>
\anchor pf_routing_model_full
### Full ###
-Full example :
+Full example:
\verbatim
<zone id="zone0" routing="Full">
<host id="host1" speed="1000000000"/>
| 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_fullduplex "FULLDUPLEX", this indicates which direction the route traverses through this link: UP or DOWN. If you don't use FULLDUPLEX, do not use this attribute or SimGrid will not find the right link.
+| 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 ####
<b>bypasszoneroute</b> is the tag you're looking for. It allows to
bypass routes defined between already defined between zone (if you want
to bypass route for a specific host, you should just use byPassRoute).
-The principle is the same as zoneroute : <b>bypasszoneroute</b> contains
+The principle is the same as zoneroute: <b>bypasszoneroute</b> contains
list of links that are in the path between src and dst.
#### Attributes ####
As said before, once you choose
a model, it (most likely; the constant network model, for example, doesn't) calculates routes for you. But maybe you want to
define some of your routes, which will be specific. You may also want
-to bypass some routes defined in lower level zone at an upper stage :
+to bypass some routes defined in lower level zone at an upper stage:
<b>bypassRoute</b> is the tag you're looking for. It allows to bypass
routes defined between <b>host/router</b>. The principle is the same
-as route : <b>bypassRoute</b> contains list of links references of
+as route: <b>bypassRoute</b> contains list of links references of
links that are in the path between src and dst.
#### Attributes ####
defined inside zone_Big. If you choose some shortest-path model,
this route will be computed automatically.
-As said before, there are mainly 2 tags for routing :
+As said before, there are mainly 2 tags for routing:
\li <b>zoneroute</b>: to define routes between two <b>zone</b>
\li <b>route</b>: to define routes between two <b>host/router</b>
routing (as we don't want to bother with defining all routes). As
we're using some shortest path algorithms to route into zone_2, we'll
then have to define some <b>route</b> to gives some topological
-information to SimGrid. Here is a file doing it all :
+information to SimGrid. Here is a file doing it all:
\verbatim
<zone id="zone_Big" routing="Dijkstra">
\subsection pf_exit_zone Exit Zone: why and how
Users that have looked at some of our platforms may have notice a
-non-intuitive schema ... Something like that :
+non-intuitive schema ... Something like that:
\verbatim
Choosing wisely the routing model to use can significantly fasten your
simulation/save your time when writing the platform/save tremendous
disk space. Here is the list of available model and their
-characteristics (lookup : time to resolve a route):
+characteristics (lookup: time to resolve a route):
\li <b>Full</b>: Full routing data (fast, large memory requirements,
fully expressive)
