X-Git-Url: http://info.iut-bm.univ-fcomte.fr/pub/gitweb/simgrid.git/blobdiff_plain/c7b463c9c17665403d001fc59cb649551e93d950..04623b43371d801573dc06771538af1057db6e41:/doc/user_guide/doxygen/platform.doc

diff --git a/doc/user_guide/doxygen/platform.doc b/doc/user_guide/doxygen/platform.doc
index f4f4eab8c3..e33d8d9f08 100644
--- a/doc/user_guide/doxygen/platform.doc
+++ b/doc/user_guide/doxygen/platform.doc
@@ -11,35 +11,9 @@ to its doc. (you can also  check the section  \ref pf_flexml_bypassing but this
 \li You can use two XML files: a platform description file and a deployment
 description one.
 
-As the second one (deployment description) just consists of saying which
-process runs where and which arguments it should take as input, the easier way to
-understand how to write it is just to take a look at the examples. Here is an example of it:
+For the deployment stuff, please takea look at \ref deployment
 
-\verbatim
-<?xml version='1.0'?>
-<!DOCTYPE platform SYSTEM "http://simgrid.gforge.inria.fr/simgrid.dtd">
-<platform version="3">
-  <!-- The master process (with some arguments) -->
-  <process host="Tremblay" function="master">
-     <argument value="20"/>       <!-- Number of tasks -->
-     <argument value="50000000"/>  <!-- Computation size of tasks -->
-     <argument value="1000000"/>   <!-- Communication size of tasks -->
-     <argument value="Jupiter"/>  <!-- First slave -->
-     <argument value="Fafard"/>   <!-- Second slave -->
-     <argument value="Ginette"/>  <!-- Third slave -->
-     <argument value="Bourassa"/> <!-- Last slave -->
-     <argument value="Tremblay"/> <!-- Me! I can work too! -->
-  </process>
-  <!-- The slave processes (with no argument) -->
-  <process host="Tremblay" function="slave"/>
-  <process host="Jupiter" function="slave"/>
-  <process host="Fafard" function="slave"/>
-  <process host="Ginette" function="slave"/>
-  <process host="Bourassa" function="slave"/>
-</platform>
-\endverbatim
-
-The platform description is slightly more complicated. This documentation is all about how to write this file: what are the basic concept it relies on, what possibilities are offered, and some hints and tips on how to write a good platform description.
+The platform description may be complicated. This documentation is all about how to write this file: what are the basic concept it relies on, what possibilities are offered, and some hints and tips on how to write a good platform description.
 
 \section pf_overview Some words about XML and DTD
 
@@ -159,10 +133,6 @@ It is also possible to seamlessly declare a host whose
 availability changes over time using the availability_file
 attribute and a separate text file whose syntax is exemplified below.
 
-
-<b>IMPORTANT NOTE:</b> the numeric separator in both trace and availability depends on your system locale. Examples below holds for LC_NUMERIC=C.
-
-
 <b>Adding a trace file</b>
 \verbatim
     <platform version="1">
@@ -277,13 +247,13 @@ The principle is the same, except we don't have the backbone. The way to obtain
 \li <b>bw (mandatory)</b>: bandwidth for the links between nodes and backbone (if any). See <b>link</b> section for syntax/details.
 \li <b>lat (mandatory)</b>: latency for the links between nodes and backbone (if any). See <b>link</b> section for syntax/details.
 \li <b>sharing_policy</b>: sharing policy for the links between nodes and backbone (if any). See <b>link</b> section for syntax/details.
-\li <b>bb_bw </b>: bandwidth for backbone (if any). See <b>link</b> section for syntax/details. If both bb_* attributes are ommited, no backbone is create (alternative cluster architecture described before).
-\li <b>bb_lat </b>: latency for backbone (if any). See <b>link</b> section for syntax/details. If both bb_* attributes are ommited, no backbone is create (alternative cluster architecture described before).
+\li <b>bb_bw </b>: bandwidth for backbone (if any). See <b>link</b> section for syntax/details. If both bb_* attributes are ommited, no backbone is created (alternative cluster architecture described before).
+\li <b>bb_lat </b>: latency for backbone (if any). See <b>link</b> section for syntax/details. If both bb_* attributes are ommited, no backbone is created (alternative cluster architecture described before).
 \li <b>bb_sharing_policy</b>: sharing policy for the backbone (if any). See <b>link</b> section for syntax/details.
 \li <b>availability_file</b>: Allow you to use a file as input for availability. Similar to <b>hosts</b> attribute.
 \li <b>state_file</b>: Allow you to use a file as input for states. Similar to <b>hosts</b> attribute.
 
-the router name is defined as the resulting String in the following java line of code: router_name = prefix + "router_ + suffix ;
+the router name is defined as the resulting String in the following java line of code: router_name = prefix + clusterId + router_ + suffix ;
 
 
 <b>cluster example</b>
@@ -294,6 +264,14 @@ the router name is defined as the resulting String in the following java line of
   		radical="0-99"	power="1000000000"    bw="125000000"     lat="5E-5"
         bb_bw="2250000000" bb_lat="5E-4"/>
 \endverbatim
+The second examples creates 100 machines, which names are the following:
+\verbatim
+c-0.my_cluster_1.me
+c-1.my_cluster_1.me
+c-2.my_cluster_1.me
+...
+c-99.my_cluster_1.me
+\endverbatim
 
 \subsubsection pf_peer peer
 A <b>peer</b> represents a peer, as in Peer-to-Peer (P2P). Basically, as cluster, <b>A PEER IS INTERNALLY INTERPRETED AS AN \<AS\></b>. It's just a kind of shortcut that does the following :