2 \defgroup SimGrid_API API of SimGrid */
4 /** \defgroup XBT_API XBT (eXtended Bundle of tools)
6 \brief The core toolbox of SimGrid, containing usefull datatypes,
7 portability support and so on.
9 /** \defgroup XBT_ground Grounding features of the XBT (logging and error reporting)
11 /** \addtogroup XBT_log
12 \ingroup XBT_ground */
13 /** \defgroup XBT_log_cats Existing log categories
15 \brief (automatically extracted)
17 This is the list of all existing log categories in SimGrid.
18 This list was automatically extracted from the source code by
19 the src/xbt_log_extract_hierarchy utility.
21 You can thus be certain that it is uptodate, but it may somehow
22 lack a final manual touch.
23 Anyway, nothing's perfect ;)
25 /** \addtogroup XBT_error
26 \ingroup XBT_ground */
28 /** \defgroup XBT_structs Datatypes defined in the XBT
30 /** \addtogroup XBT_dict
31 \ingroup XBT_structs */
32 /** \addtogroup XBT_dynar
33 \ingroup XBT_structs */
34 /** \addtogroup XBT_fifo
35 \ingroup XBT_structs */
36 /** \addtogroup XBT_set
37 \ingroup XBT_structs */
38 /** \addtogroup XBT_swag
39 \ingroup XBT_structs */
40 /** \addtogroup XBT_heap
41 \ingroup XBT_structs */
43 /** \defgroup XBT_port Portability support defined in the XBT
44 (you shouldn't use it directly)
46 /** \addtogroup XBT_context
48 /** \addtogroup XBT_sysdep
51 /** \defgroup SURF_API SURF (simulator kernel)
53 \brief Kernel of all the simulators used in SimGrid, and associated models.
55 SURF provides the core functionnalities to simulate a virtual
56 platform. It is very low-level and is not intended to be used as
57 such but rather to serve as a basis for higher-level simulators.
58 We're still working on it and the structure is a little bit
59 complex. So we'll document it only when we'll be completely satisfied of
60 the way it is organized.
62 It is where platform models are encoded. If you need a model that is not
63 encoded yet, please tell me (<arnaud.legrand@imag.fr>) and we'll
64 see if it is feasible or not (hopefully it should be but who knows).
66 Please note that as it is not really intended for public use,
67 this module is only partially documented.
70 /** \defgroup MSG_API MSG
72 \brief Simple programming environment
74 MSG was the first distributed programming environment provided within
75 SimGrid. While almost realistic, it remains quite simple (simplistic?).
77 \section MSG_who Who should use this (and who shouldn't)
79 You should use this model if you want to study some heuristics for a
80 given problem you don't really want to implement. If you want to get a
81 real implementation of your solution, have a look at the \ref GRAS_API
82 programming environment. If you want to study an existing MPI program,
83 have a look at the \ref SMPI_API one. If none of those programming
84 environments fits your needs, you may consider implementing your own
85 directly on top of \ref SURF_API (but you probably want to contact us
88 /** \addtogroup m_datatypes_management
90 /** \addtogroup m_process_management
92 /** \addtogroup m_host_management
94 /** \addtogroup m_task_management
96 /** \addtogroup msg_gos_functions
98 /** \addtogroup m_channel_management
100 /** \addtogroup msg_easier_life
102 /** \addtogroup msg_simulation
106 /** \defgroup GRAS_API GRAS
108 \brief Realistic programming environment (Grid Reality And Simulation)
110 GRAS provide a complete API to implement distributed application on top
111 of heterogeneous plateforms. In addition to the SimGrid implementation
112 of this interface (allowing you to work on your application within the
113 comfort of the simulator), an implementation suited to real platforms is
114 also provided (allowing you to really use your application once you're
115 done with developing it).
117 GRAS thus constitute a complete grid application developement framework,
118 encompassing both developer helping tools (the simulator and associated
119 tools) and an efficient while portable execution runtime.
121 \section GRAS_who Who should use this (and who shouldn't)
123 You should use this programming environment if you want to develop real
124 applications, ie if the final result of your work is a program which
125 may eventually be distributed.
126 If you just want to study some heuristics for a given problem you don't
127 want to implement really (ie, if your result would be a theorem), have a
128 look at the \ref MSG_API one.
129 If you want to study an existing MPI program, have a look at the
131 If none of those programming environments fits your needs, you may
132 consider implementing your own directly on top of \ref SURF_API (but you
133 probably want to contact us before).
135 \section GRAS_funct Offered functionnalities
136 - <b>Communication facilities</b>: Exchanging messages between peers
137 - \ref GRAS_dd: any data which may transit on the network must be
138 described beforehand so that GRAS can handle the platform
139 heterogeneity and convert them if needed.
140 - \ref GRAS_sock: this is how to open a communication channel to
141 other processes, and retrive information about them.
142 - \ref GRAS_msg: communications are message oriented. You have to
143 describe all possible messages and their payload beforehand, and
144 can then attach callbacks to the arrival of a given kind of message.
145 - <b>Virtualization</b>: Running both on top of the simulator and on
146 top of real platforms, and portability support.
147 - \ref GRAS_globals: The use of globals is forbidden since the
148 "processes" are threads in simulation mode. \n
149 This is how to let GRAS handle your globals properly.
150 - \ref GRAS_cond: How to declare specific code for the simulation mode
151 or for the real mode.
152 - \ref GRAS_virtu: You naturally don't want to call the
153 gettimeofday(2) function in simulation mode since it would give
154 you the time on the host running the simulation, not the time in
155 the simulated world (you are belonging to).\n
156 This a system call virtualization layer, which also acts as a
159 \section GRAS_todo TODO
160 Documentation related:
161 - Add an example to the \ref GRAS_msg section, at least
162 - Document examples/gras/gras_stub_generator utility and how to deal
163 with the fact that programs must have a main in RL and not in SG.
164 - Document example/gras/ping as it uses almost all of the GRAS
167 Code related: too long to be written here. See the TODO file
172 /** \defgroup GRAS_dd Data description */
173 /** \defgroup GRAS_sock Sockets */
174 /** \defgroup GRAS_msg Messages */
176 /** \defgroup GRAS_globals Globals */
177 /** \defgroup GRAS_cond Conditional execution */
178 /** \defgroup GRAS_virtu Syscalls */
182 /** \defgroup SMPI_API SMPI
184 \brief Programming environment for the simulation of MPI applications
186 Once implemented, this programming environment will allow you to study
187 within the simulator any MPI application without having to modify them
188 for that. In other words, it will constitute an emulation solution for
191 \section SMPI_who Who should use this (and who shouldn't)
193 You should use this programming environment of the SimGrid suite if you
194 want to study existing MPI applications.
195 If you want to work on a distributed application, have a look at the
196 \ref GRAS_API environment.
197 If you want to study some heuristics for a given problem (and if your
198 goal is to produce theorems, not code), have a look at the \ref MSG_API
200 If none of those programming environments fits your needs, you may
201 consider implementing your own directly on top of \ref SURF_API (but you
202 probably want to contact us before).