/**
- \defgroup SimGrid_API API of SimGrid */
+ \defgroup SimGrid_API SimGrid modules */
-/** \defgroup XBT_API XBT (eXtended Bundle of tools)
- \ingroup SimGrid_API
- \brief The core toolbox of SimGrid, containing usefull datatypes,
- portability support and so on.
-*/
-/** \defgroup XBT_ground Grounding features of the XBT (logging and error reporting)
- \ingroup XBT_API */
- /** \addtogroup XBT_log
- \ingroup XBT_ground */
- /** \defgroup XBT_log_cats Existing log categories
- \ingroup XBT_log
- \brief (automatically extracted)
-
- This is the list of all existing log categories in SimGrid.
- This list was automatically extracted from the source code by
- the src/xbt_log_extract_hierarchy utility.
-
- You can thus be certain that it is uptodate, but it may somehow
- lack a final manual touch.
- Anyway, nothing's perfect ;)
- */
- /** \addtogroup XBT_error
- \ingroup XBT_ground */
-
-/** \defgroup XBT_structs Datatypes defined in the XBT
- \ingroup XBT_API */
-/** \addtogroup XBT_dict
- \ingroup XBT_structs */
-/** \addtogroup XBT_dynar
- \ingroup XBT_structs */
-/** \addtogroup XBT_fifo
- \ingroup XBT_structs */
-/** \addtogroup XBT_set
- \ingroup XBT_structs */
-/** \addtogroup XBT_swag
- \ingroup XBT_structs */
-/** \addtogroup XBT_heap
- \ingroup XBT_structs */
-
-/** \defgroup XBT_port Portability support defined in the XBT
- (you shouldn't use it directly)
- \ingroup XBT_API */
-/** \addtogroup XBT_context
- \ingroup XBT_port */
-/** \addtogroup XBT_sysdep
- \ingroup XBT_port */
-
-/** \defgroup SURF_API SURF (simulator kernel)
+/** \defgroup XBT_API XBT
\ingroup SimGrid_API
- \brief 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 as
- such but rather to serve as a basis for higher-level simulators.
- We're still working on it and the structure is a little bit
- complex. So we'll document it only when we'll be completely satisfied of
- the way it is organized.
-
- It is where platform models are encoded. If you need a model that is not
- encoded yet, please tell me (<arnaud.legrand@imag.fr>) and we'll
- see if it is feasible or not (hopefully it should be but who knows).
-
- Please note that as it is not really intended for public use,
- this module is only partially documented.
+ \brief The core toolbox of SimGrid, containing usefull datatypes,
+ portability support and so on.
+
*/
/** \defgroup MSG_API MSG
\section MSG_who Who should use this (and who shouldn't)
- You should use this model if you want to study some heuristics for a
- given problem you don't really want to implement. If you want to get a
- real implementation of your solution, have a look at the \ref GRAS_API
- programming environment. If you want to study an existing MPI program,
+ You should use this module if you want to study some heuristics for a
+ given problem you don't really want to implement.
+ If you want to use DAGs, have a look at the \ref SD_API programming
+ environment.
+ If you want to get a real (but experimental) implementation of your solution, have a look
+ at the \ref GRAS_API one. If you want to study an existing MPI program,
have a look at the \ref SMPI_API one. If none of those programming
environments fits your needs, you may consider implementing your own
directly on top of \ref SURF_API (but you probably want to contact us
before).
*/
-/** \addtogroup m_datatypes_management
- \ingroup MSG_API */
-/** \addtogroup m_process_management
- \ingroup MSG_API */
-/** \addtogroup m_host_management
- \ingroup MSG_API */
-/** \addtogroup m_task_management
- \ingroup MSG_API */
-/** \addtogroup msg_gos_functions
- \ingroup MSG_API */
-/** \addtogroup m_channel_management
- \ingroup MSG_API */
-/** \addtogroup msg_easier_life
- \ingroup MSG_API */
-/** \addtogroup msg_simulation
- \ingroup MSG_API */
+
+
+/** \defgroup SIMIX_API SIMIX
+ \ingroup SimGrid_API
+ \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 GRAS_API GRAS
\ingroup SimGrid_API
\brief Realistic programming environment (Grid Reality And Simulation)
- GRAS provide a complete API to implement distributed application on top
+ GRAS provides a complete API to implement distributed application on top
of heterogeneous plateforms. In addition to the SimGrid implementation
of this interface (allowing you to work on your application within the
comfort of the simulator), an implementation suited to real platforms is
also provided (allowing you to really use your application once you're
- done with developing it).
+ done with developing it). It may still contain rought corners as
+ GRAS is not the most used part of SimGrid, however.
GRAS thus constitute a complete grid application developement framework,
encompassing both developer helping tools (the simulator and associated
You should use this programming environment if you want to develop real
applications, ie if the final result of your work is a program which
- may eventually be distributed.
+ may eventually be distributed. Rember however that GRAS is
+ considered as experimental at this point. Help would be welcomed
+ to improve this sorry situation...
+
If you just want to study some heuristics for a given problem you don't
want to implement really (ie, if your result would be a theorem), have a
- look at the \ref MSG_API one.
+ look at the \ref MSG_API one, or the \ref SD_API one if you need to use DAGs.
If you want to study an existing MPI program, have a look at the
\ref SMPI_API one.
If none of those programming environments fits your needs, you may
consider implementing your own directly on top of \ref SURF_API (but you
probably want to contact us before).
-
- \section GRAS_funct Offered functionnalities
- - <b>Communication facilities</b>: Exchanging messages between peers
- - \ref GRAS_dd: any data which may transit on the network must be
- described beforehand so that GRAS can handle the platform
- heterogeneity and convert them if needed.
- - \ref GRAS_sock: this is how to open a communication channel to
- other processes, and retrive information about them.
- - \ref GRAS_msg: communications are message oriented. You have to
- describe all possible messages and their payload beforehand, and
- can then attach callbacks to the arrival of a given kind of message.
- - <b>Virtualization</b>: Running both on top of the simulator and on
- top of real platforms, and portability support.
- - \ref GRAS_globals: The use of globals is forbidden since the
- "processes" are threads in simulation mode. \n
- This is how to let GRAS handle your globals properly.
- - \ref GRAS_cond: How to declare specific code for the simulation mode
- or for the real mode.
- - \ref GRAS_virtu: You naturally don't want to call the
- gettimeofday(2) function in simulation mode since it would give
- you the time on the host running the simulation, not the time in
- the simulated world (you are belonging to).\n
- This a system call virtualization layer, which also acts as a
- portability layer.
-
- \section GRAS_todo TODO
- Documentation related:
- - Add an example to the \ref GRAS_msg section, at least
- - Document examples/gras/gras_stub_generator utility and how to deal
- with the fact that programs must have a main in RL and not in SG.
- - Document example/gras/ping as it uses almost all of the GRAS
- features.
-
- Code related: too long to be written here. See the TODO file
-
- @{
-*/
-
- /** \defgroup GRAS_dd Data description */
- /** \defgroup GRAS_sock Sockets */
- /** \defgroup GRAS_msg Messages */
-
- /** \defgroup GRAS_globals Globals */
- /** \defgroup GRAS_cond Conditional execution */
- /** \defgroup GRAS_virtu Syscalls */
-
-/** @} */
+*/
+
+/** \defgroup AMOK_API AMOK
+ \ingroup SimGrid_API
+ \brief Distributed toolkit built over \ref GRAS_API (Advanced Metacomputing Overlay Kit)
+
+ AMOK provides several tools useful to most applications built on top of GRAS,
+ but yet not belonging to GRAS itself. It is planned that those modules will be
+ changed to real plugins one day, allowing users to load only the needed parts at
+ run time. For now, they live in another library against which you should link your
+ programs explicitly.
+*/
/** \defgroup SMPI_API SMPI
\ingroup SimGrid_API
\brief Programming environment for the simulation of MPI applications
- Once implemented, this programming environment will allow you to study
- within the simulator any MPI application without having to modify them
- for that. In other words, it will constitute an emulation solution for
- parallel codes.
+This programming environment permits to study existing MPI application
+by emulating them on top of the SimGrid simulator. In other words, it
+will constitute an emulation solution for parallel codes. You don't
+even have to modify your code for that, although that may help, as
+detailed below.
+
+\section SMPI_who Who should use SMPI (and who shouldn't)
+
+You should use this programming environment of the SimGrid suite if
+you want to study existing MPI applications. If you want to create a
+distributed application, you may be interested in the \ref GRAS_API
+environment instead (but note that GRAS is not very actively
+maintained nowadays). If you want to study some heuristics for a given
+problem (and if your goal is to produce theorems and publications, not
+code), have a look at the \ref MSG_API environment, or the \ref SD_API
+one if you need to use DAGs. If none of those programming environments
+fits your needs, you may consider implementing your own directly on
+top of \ref SURF_API (but you probably want to contact us before).
+
+\section SMPI_what What can run within SMPI?
+
+You can run unmodified MPI applications (both C and Fortran) within
+SMPI, provided you only use MPI calls that we implemented in MPI. Our
+coverage of the interface is not bad, but will probably never be
+complete. One sided communications and I/O primitives are not targeted
+for now. The full list of not yet implemented functions is available
+in file <tt>include/smpi/smpi.h</tt> of the archive, between two lines
+containing the <tt>FIXME</tt> marker. If you really need a missing
+feature, please get in touch with us: we can guide you though the
+SimGrid code to help you implementing it, and we'd glad to integrate
+it in the main project afterward if you contribute them back.
+
+\section SMPI_adapting Adapting your MPI code to the use of SMPI
+
+As detailed in the reference article (available at
+http://hal.inria.fr/inria-00527150), you may want to adapt your code
+to improve the simulation performance. But these tricks may seriously
+hinder the result qualtity (or even prevent the app to run) if used
+wrongly. We assume that if you want to simulate an HPC application,
+you know what you are doing. Don't prove us wrong!
+
+If you get short on memory (the whole app is executed on a single node
+when simulated), you should have a look at the SMPI_SHARED_MALLOC and
+SMPI_SHARED_FREE macros. It allows to share memory areas between
+processes. For example, matrix multiplication code may want to store
+the blocks on the same area. Of course, the resulting computations
+will useless, but you can still study the application behavior this
+way. Of course, if your code is data-dependent, this won't work.
+
+If your application is too slow, try using SMPI_SAMPLE_LOCAL,
+SMPI_SAMPLE_GLOBAL and friends to indicate which computation loops can
+be sampled. Some of the loop iterations will be executed to measure
+their duration, and this duration will be used for the subsequent
+iterations. These samples are done per processor with
+SMPI_SAMPLE_LOCAL, and shared between all processors with
+SMPI_SAMPLE_GLOBAL. Of course, none of this will work if the execution
+time of your loop iteration are not stable.
+
+Yes, that's right, these macros are not documented yet, but we'll fix
+it as soon as time permits. Sorry about that -- patch welcomed!
+Meanwhile, grep for them on the examples for more information.
+
+\section SMPI_compiling Compiling your code
+
+This is very simply done with the <tt>smpicc</tt> script. If you
+already compiled any MPI code before, you already know how to use it.
+If not, you should try to get your MPI code running on top of MPI
+before giving SMPI a spin. Actually, that's very simple even if it's
+the first time you use MPI code: just use smpicc as a compiler (in
+replacement of gcc or your usual compiler), and you're set.
+
+\section SMPI_executing Executing your code on top of the simulator
+
+This is done though the <tt>smpirun</tt> script as follows.
+<tt>my_hostfile.txt</tt> is a classical MPI hostfile (that is, this
+file lists the machines on which the processes must be dispatched, one
+per line) <tt>my_platform.xml</tt> is a classical SimGrid platform
+file. Of course, the hosts of the hostfile must exist in the provided
+platform. <tt>./program</tt> is the MPI program that you want to
+simulate (must be compiled by <tt>smpicc</tt>) while <tt>-arg</tt> is
+a command-line parameter passed to this program.
+
+\verbatim
+smpirun -hostfile my_hostfile.txt -platform my_platform.xml ./program -arg
+\endverbatim
+
+smpirun accepts other parameters, such as <tt>-np</tt> if you don't
+want to use all the hosts defined in the hostfile, <tt>-map</tt> to
+display on which host each rank gets mapped of <tt>-trace</tt> to
+activate the tracing during the simulation. You can get the full list
+by running
+\verbatim
+smpirun -help
+\endverbatim
+
+
+*/
+
+
+/** \defgroup SD_API SimDag
+ \ingroup SimGrid_API
+ \brief Programming environment for DAG applications
+
+ SimDag provides some functionnalities to simulate parallel task scheduling
+ with DAGs models (Direct Acyclic Graphs).
+ The old versions of SimGrid were based on DAGs. But the DAG part (named SG)
+ was removed in SimGrid 3 because the new kernel (\ref SURF_API) was implemented. \ref SURF_API
+ was much faster and more flexible than SG and did not use DAGs.
+ SimDag is a new implementation of DAGs handling and it is built on top of \ref SURF_API.
- \section SMPI_who Who should use this (and who shouldn't)
+ \section SD_who Who should use this (and who shouldn't)
- You should use this programming environment of the SimGrid suite if you
- want to study existing MPI applications.
- If you want to work on a distributed application, have a look at the
- \ref GRAS_API environment.
- If you want to study some heuristics for a given problem (and if your
- goal is to produce theorems, not code), have a look at the \ref MSG_API
- environment.
+ You should use this programming environment of the SimGrid suite if you want
+ to study algorithms and heuristics with DAGs of parallel tasks.
+ If you don't need to use DAGs for your simulation, have a look at the
+ \ref MSG_API programming environment.
+ If you want to implement a real distributed application, have a look at the
+ \ref GRAS_API programming environment.
+ If you want to study an existing MPI program, have a look at the
+ \ref SMPI_API one.
If none of those programming environments fits your needs, you may
consider implementing your own directly on top of \ref SURF_API (but you
probably want to contact us before).
-
- */
+
+*/
+
+/**
+@defgroup SURF_API SURF
+@ingroup SimGrid_API
+@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
+interface are not frozen (and will probably never 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.
+*/
+
+
+/**
+@defgroup TRACE_API TRACE
+@ingroup SimGrid_API
+@brief Tracing mechanism and its functions.
+
+SimGrid can trace the resource (of hosts and links) utilization using
+any of its programming interfaces (MSG, SimDAG and SMPI). This means
+that the tracing will register how much power is used for each host
+and how much bandwidth is used for each link of the platform.
+
+The idea of the tracing facilities is to give SimGrid users to
+possibility to classify MSG and SimDAG tasks by category, tracing the
+platform utilization (hosts and links) for each of the categories.
+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 tracing_tracing for details).
+*/
+
