Logo AND Algorithmique Numérique Distribuée

Public GIT Repository
Kill more deprecated content from the old doc
[simgrid.git] / doc / doxygen / module-index.doc
index b89f0d6..0f252d6 100644 (file)
@@ -19,13 +19,13 @@ The API enables the declaration of categories and a function to
 associate them to the tasks (MSG and SD). The tasks that are not
 classified according to a category are not traced. If no categories
 are specified, simulations can still be traced using a special
-parameter in the command line (see \ref outcomes_vizu for details).
+parameter in the command line (see @ref outcomes_vizu for details).
 */
 
 /** @defgroup ROUTING_API  Routing: Determining the communication paths
     @brief Organize the platform to determine the links used by each communication
 
-@section routing_basics Basic Concepts 
+@section routing_basics Basic Concepts
 
 The purpose of the simgrid::kernel::routing module is to retrieve the
 routing path between two points in a time- and space-efficient manner.
@@ -34,7 +34,7 @@ the created communication, and the summed latency that these links
 represent. This operation is clearly on the critical path of most
 SimGrid simulations.
 
-When defining how the information is routed in the simulated network, 
+When defining how the information is routed in the simulated network,
 it is certainly very tempting to use a formalism somehow similar to
 how it is defined on real network. One would have to define the
 routing tables of each routers interconnections sub-networks, just
@@ -47,20 +47,20 @@ This is not the way it goes in SimGrid: the network routing is defined
 in a global and compact way instead. This eases the modeling of very
 large systems, and allows highly optimized datastructures and
 algorithms in the simulator. The proposed description mechanism is
-thus much more convinient and efficient. In addition, it is more
+thus much more convenient and efficient. In addition, it is more
 expressive than the classical solution based on forwarding tables on
-each host and router. 
+each host and router.
 
 The price to pay is that this representation of networks is very
 specific to SimGrid, so you will have to read further to understand
 it, even if you already know how real networks work.
 
-The central notion here are \b Networking \b Zones. NetZones represent
+The central notion here are @b Networking @b Zones. NetZones represent
 network areas in which the routing is done in an homogeneous way.
 Conceptually, netzones generalize from the ideas of local networks
-(such as Ethernet switched networks) and Autonomous System. The 
+(such as Ethernet switched networks) and Autonomous System. The
 network as a whole is represented as a single hierarchy of netzones,
-meaning that every netzone is part of another netzone (but the \c
+meaning that every netzone is part of another netzone (but the @c
 NetRoot, which is the top-level netzone).
 
 The main goal of the routing module is to provide a list of links
@@ -72,10 +72,10 @@ bypass mechanism.
 
 The <b>intra-zone level</b> is naturally handled by the netzones. Each
 netzone have to specify the routing algorithm it uses for that.
-@ref{FullZone} netzones have complete matrix where matrix(a,b)
+@ref simgrid::kernel::routing::FullZone "FullZone" netzones have complete matrix where matrix(a,b)
 represents the full path (the list of links) between the hosts a and
-b. @ref{FloydZone} apply the Floyd-Warshall algorithm to compute the
-paths. @ref{ClusterZone} model classical switched or hub networks,
+b. @ref simgrid::kernel::routing::FloydZone "FloydZone" apply the Floyd-Warshall algorithm to compute the
+paths. @ref simgrid::kernel::routing::ClusterZone "ClusterZone" model classical switched or hub networks,
 where each component is connected through a private link onto a common
 backbone. Many other routing algorithms are provided to model the
 classical needs, but you can naturally define your own routing if the
@@ -96,35 +96,6 @@ given processes.
 
 For now, you can only declare a platform from an XML file, but we are
 working to make it possible from the C++ code (or even from bindings
-in other languages). Until then, please head to \ref platform.
+in other languages). Until then, please head to @ref platform.
 
 */
-
-/** \defgroup SIMIX_API      SIMIX
-    \brief POSIX-like interface for building simulation
-
-    This is a developer-level interface that should be useful only if you
-    plan to design a new interface for SimGrid.
-*/
-
-
-
-/**
-@defgroup SURF_API SURF
-@brief Internal kernel of all the simulators used in SimGrid, and associated models.
-
-SURF provides the core functionnalities to simulate a virtual
-platform. It is very low-level and is not intended to be used by end
-users, but rather to serve as a basis for higher-level simulators. Its
-interfaces are not frozen (and probably never will be), and the
-structure emphasis on performance over ease of use. This module
-contains the platform models. If you need a model that is not encoded
-yet, please come to the devel mailing list so that we can discuss on
-the feasibility of your idea.
-
-Please note that as it is not really intended for public use, this
-module is only partially documented.
-*/
-
-
-