X-Git-Url: http://info.iut-bm.univ-fcomte.fr/pub/gitweb/simgrid.git/blobdiff_plain/d8eb62b207b566949a0d9ce649a7b21e226b9168..390f07ace843ed23ed4d2a1d26f90148d07836ad:/doc/doxygen/module-surf.doc

diff --git a/doc/doxygen/module-surf.doc b/doc/doxygen/module-surf.doc
index d041a49bf3..4cc3c6cae0 100644
--- a/doc/doxygen/module-surf.doc
+++ b/doc/doxygen/module-surf.doc
@@ -1,4 +1,4 @@
-/** @addtogroup SURF_API
+/** @addtogroup SURF_API
   
   @section SURF_doc Surf documentation
    Surf is composed several components:
@@ -56,7 +56,7 @@
     Some functions of the @ref SURF_host_interface and similar can give
     you some information about:
 	- a host: get_speed(), get_available_speed();
-	- a network link: get_link_name(), get_link_latency(), get_link_bandwith();
+	- a network link: get_link_name(), get_link_latency(), get_link_bandwidth();
 	- a route: get_route(), get_route_size().
 
     During the simulation, call @a surf_host_model->execute() to schedule a
@@ -72,8 +72,6 @@
     extract them from @a surf_host_model->common_public->states.done_action_set.
     Depending on these results, you can schedule other tasks and call surf_solve() again.
 
-    When the simulation is over, just call surf_exit() to clean the memory.
-
     Have a look at the implementation of @ref MSG_API "MSG" and @ref SD_API "Simdag" to see how these module
     interact with SURF. But if you want to create a new API on top of SURF,
     we strongly recommend you to contact us before anyway.