src/modules.doc

   1 /**
   2   \defgroup SimGrid_API  API of SimGrid */
   3
   4 /** \defgroup XBT_API      XBT (eXtended Bundle of tools)
   5        \ingroup SimGrid_API
   6        \brief The core toolbox of SimGrid, containing usefull datatypes,
   7        portability support and so on.
   8 */
   9 /**    \defgroup XBT_ground Grounding features of the XBT (logging and error reporting)
  10        \ingroup XBT_API        */
  11 /**       \addtogroup  XBT_log
  12           \ingroup XBT_ground  */
  13 /**       \addtogroup  XBT_error
  14           \ingroup XBT_ground  */
  15
  16 /**    \defgroup XBT_structs  Datatypes defined in the XBT
  17        \ingroup XBT_API        */
  18 /**       \addtogroup XBT_dict
  19           \ingroup XBT_structs */
  20 /**       \addtogroup XBT_dynar
  21           \ingroup XBT_structs */
  22 /**       \addtogroup XBT_fifo
  23           \ingroup XBT_structs */
  24 /**       \addtogroup XBT_set
  25           \ingroup XBT_structs */
  26 /**        \addtogroup XBT_swag
  27           \ingroup XBT_structs */
  28 /**       \addtogroup XBT_heap
  29           \ingroup XBT_structs */
  30
  31 /**    \defgroup XBT_port     Portability support defined in the XBT
  32                               (you shouldn't use it directly)
  33        \ingroup XBT_API        */
  34 /**       \addtogroup XBT_context
  35           \ingroup XBT_port    */
  36 /**       \addtogroup XBT_sysdep
  37           \ingroup XBT_port    */
  38
  39 /** \defgroup SURF_API       SURF (simulator kernel)
  40     \ingroup SimGrid_API
  41     \brief Kernel of all the simulators used in SimGrid, and associated models.
  42
  43       SURF provides the core functionnalities to simulate a virtual
  44       platform. It is very low-level and is not intended to be used as
  45       such but rather to serve as a basis for higher-level simulators.
  46       We're still working on it and the structure is a little bit
  47       complex. So we'll document it only when we'll be completely satisfied of
  48       the way it is organized.
  49
  50       It is where platform models are encoded. If you need a model that is not
  51       encoded yet, please tell me (<arnaud.legrand@imag.fr>) and we'll
  52       see if it is feasible or not (hopefully it should be but who knows).
  53
  54       Please note that as it is not really intended for public use,
  55       this module is only partially documented.
  56 */
  57
  58 /** \defgroup MSG_API      MSG
  59     \ingroup SimGrid_API
  60     \brief Simple programming environment
  61
  62       MSG was the first distributed programming environment provided within
  63       SimGrid. While almost realistic, it remains quite simple (simplistic?).
  64
  65       You should use this model if you want to study some heuristics for a
  66       given problem you don't really want to implement. If you want to get a
  67       real implementation of your solution, have a look at the \ref GRAS_API
  68       programming environment. If you want to study an existing MPI program,
  69       have a look at the \ref SMPI_API one. If none of those programming
  70       environments fits your needs, you may consider implementing your own
  71       directly on top of \ref SURF_API (but you probably want to contact us
  72       before).
  73 */
  74 /**     \addtogroup m_datatypes_management
  75         \ingroup MSG_API  */
  76 /**     \addtogroup m_process_management
  77         \ingroup MSG_API  */
  78 /**     \addtogroup m_host_management
  79         \ingroup MSG_API  */
  80 /**     \addtogroup m_task_management
  81         \ingroup MSG_API  */
  82 /**     \addtogroup msg_gos_functions
  83         \ingroup MSG_API  */
  84 /**     \addtogroup m_channel_management
  85         \ingroup MSG_API  */
  86 /**     \addtogroup msg_easier_life
  87         \ingroup MSG_API  */
  88 /**     \addtogroup msg_simulation
  89         \ingroup MSG_API  */
  90
  91
  92 /** \defgroup GRAS_API      GRAS
  93     \ingroup SimGrid_API
  94     \brief Realistic programming environment (Grid Reality And Simulation)
  95
  96     GRAS provide a complete API to implement distributed application on top
  97     of heterogeneous plateforms. In addition to the SimGrid implementation
  98     of this interface (allowing you to work on your application within the
  99     comfort of the simulator), an implementation suited to real platforms is
 100     also provided (allowing you to really use your application once you're
 101     done with developing it).
 102
 103     GRAS thus constitute a complete grid application developement framework,
 104     encompassing both developer helping tools (the simulator and associated
 105     tools) and an efficient while portable execution runtime.
 106
 107     You should use this programming environment if you want to develop real
 108     applications, ie if the final result of your work is a program which
 109     may eventually be distributed.
 110     If you just want to study some heuristics for a given problem you don't
 111     want to implement really (ie, if your result would be a theorem), have a
 112     look at the \ref MSG_API one.
 113     If you want to study an existing MPI program, have a look at the
 114     \ref SMPI_API one.
 115     If none of those programming environments fits your needs, you may
 116     consider implementing your own directly on top of \ref SURF_API (but you
 117     probably want to contact us before).
 118
 119     The user visibile features tend to offer several kind of functionnalities:
 120      - <b>Communication facilities</b>: Exchanging messages between peers
 121      - <b>Virtualization</b>: Running both on top of the simulator and on
 122        top of real platforms, and portability support.
 123 */
 124 /**    \addtogroup GRAS_implem
 125        \ingroup GRAS_API
 126
 127        Internals of GRAS (forget it) */
 128 /**    \addtogroup GRAS_dd
 129        \ingroup GRAS_API */
 130 /**    \addtogroup GRAS_dd_implem
 131        \ingroup GRAS_implem */
 132 /**    \defgroup GRAS_sock   Sockets
 133        \ingroup GRAS_API
 134        \brief Open/close sockets, and get info on peer (Communication facility). */
 135 /**    \defgroup GRAS_msg    Messages
 136        \ingroup GRAS_API
 137        \brief Defining messages and callbacks, and sending/receiving messages (Communication facility).
 138                                  */
 139 /**    \defgroup GRAS_globals Globals
 140        \ingroup GRAS_API
 141        \brief Handling global variables so that it works on simulator (Virtualization).
 142
 143        In GRAS, using globals is forbidden since the "processes" will
 144        sometimes run as a thread inside the same process (namely, in
 145        simulation mode). So, you have to put all globals in a structure, and
 146        let GRAS handle it.
 147
 148        Use the \ref gras_userdata_new macro to create a new user data (or malloc it
 149        and use \ref gras_userdata_set yourself), and \ref gras_userdata_get to
 150        retrive a reference to it. */
 151
 152 /**    \defgroup GRAS_virtu Syscalls
 153        \ingroup GRAS_API
 154        \brief System call abstraction layer (Virtualization). */
 155
 156 /** \defgroup SMPI_API      SMPI
 157     \ingroup SimGrid_API
 158     \brief Programming environment for the simulation of MPI applications
 159
 160     Once implemented, this programming environment will allow you to study
 161     within the simulator any MPI application without having to modify them
 162     for that. In other words, it will constitute an emulation solution for
 163     parallel codes.
 164
 165     You should use this programming environment of the SimGrid suite if you
 166     want to study existing MPI applications.
 167     If you want to work on a distributed application, have a look at the
 168     \ref GRAS_API environment.
 169     If you want to study some heuristics for a given problem (and if your
 170     goal is to produce theorems, not code), have a look at the \ref MSG_API
 171     environment.
 172     If none of those programming environments fits your needs, you may
 173     consider implementing your own directly on top of \ref SURF_API (but you
 174     probably want to contact us before).
 175
 176  */