\htmlonly
<div align="center">
\endhtmlonly
-\htmlinclude doc-toc.svg
+\htmlinclude graphical-toc.svg
\htmlonly
</div>
<script>
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
\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 ####
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"/>
<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)
