instructions and still have some troubles, drop an e-mail to
<simgrid-user@lists.gforge.inria.fr>.
-\subsection faq_compiling Compiling SimGrid
+\subsection faq_compiling Compiling SimGrid from an archive
+First of all, you need to download the latest version of SimGrid from
+<a href="http://gforge.inria.fr/frs/?group_id=12">here</a>.
Suppose you have uncompressed SimGrid in some temporary location of
your home directory (say <tt>/home/joe/tmp/simgrid-3.0.1 </tt>). The
simplest way to use SimGrid is to install it in your home
\verbatim export LD_LIBRARY_PATH=$HOME/lib/:$LD_LIBRARY_PATH
\endverbatim
+
+\subsection faq_compiling_cvs Compiling SimGrid from the CVS
+
+The project development takes place in the cvs, where all changes are
+commited when they happen. Then every once in a while, we make sure that the
+code quality meets our standard and release an archive from the code in the
+CVS. We afterward go back to the development in the CVS. So, if you need a
+recently added feature and can afford some little problem with the stability
+of the lastest features, you may want to use the CVS version instead of a
+released one.
+
+For that, you first need to get the "simgrid" module from
+<a href="http://gforge.inria.fr/scm/?group_id=12">here</a>.
+
+You won't find any <tt>configure</tt> and a few other things
+(<tt>Makefile.in</tt>'s, documentation, ...) will be missing as well. The
+reason for that is that all these files have to be regenerated using the
+latest versions of <tt>autoconf</tt>, <tt>libtool</tt>, <tt>automake</tt>
+(>1.9) and <tt>doxygen</tt> (>1.4). To generate the <tt>configure</tt> and
+the <tt>Makefile.in</tt>'s, you just have to launch the <tt>bootstrap</tt>
+command that resides in the top of the source tree. Then just follow the
+instructions of Section \ref faq_compiling.
+
+We insist on the fact that you really need the latest versions of
+autoconf and automake. Doing this step on exotic architectures/systems
+(i.e. anything different from a recent linux distribution) may be
+... uncertain. If you want to use the CVS version on another
+architecture/system, you should do the previous steps on a perfectly
+standard box, then do a <tt>make dist</tt> that will build you a
+perfectly portable SimGrid archive.
+
+In summary, the following commands will checkout the CVS, regenerate the
+configure script and friends, configure SimGrid and build an archive you can
+use on another machine afterward.
+
+\verbatim cvs -d :pserver:anonymous@scm.gforge.inria.fr:/cvsroot/simgrid login
+cvs -d :pserver:anonymous@scm.gforge.inria.fr:/cvsroot/simgrid checkout simgrid
+cd simgrid
+./bootstrap
+./configure --enable-maintainer-mode
+make dist \endverbatim
+
\subsection faq_setting Setting up your own code
Do not build your simulator by modifying the SimGrid examples. Go
\section faq_simgrid I'm new to SimGrid. I have some questions. Where should I start?
You are at the right place... Having a look to these
-<a href="http://graal.ens-lyon.fr/~alegrand/articles/Simgrid-Introduction.pdf">slides</a>
+<a href="http://graal.ens-lyon.fr/~alegrand/articles/slides_g5k_simul.pdf">slides</a>
+(or to these
+<a href="http://graal.ens-lyon.fr/~alegrand/articles/Simgrid-Introduction.pdf">"obsolete" slides</a>)
may give you some insights on what SimGrid can help you to do and what
are its limitations. Then you definitely should read the \ref
MSG_examples. There is also a mailing list: <simgrid-user@lists.gforge.inria.fr>.
Those two things are working, but we want to make everything as clean as
possible before releasing SimGrid v.3.
-So what about those nice DAGs we used to have in SimGrid v.1.? They're not
-anymore in SimGrid v.3. Let me recall you the way SimGrid 3 is organized:
+So what about those nice DAGs we used to have in SimGrid v.1.? They're
+not anymore in SimGrid v.3. At least not in their original form... Let
+me recall you the way SimGrid 3 is organized:
\verbatim
________________
----------------
\endverbatim
-XBT is our tool box and now, you should have an idea of what the other ones
-are. As you can see, the primitive SG is not here anymore. However it could
-still be brought back if people really need it. Here is how it would fit.
+XBT is our tool box and now, you should have an idea of what the other
+ones are. As you can see, the primitive SG is not here
+anymore. However we have written a brand new and cleaner API for this
+purpose: \ref SD_API. It is built directly on top of SURF and provides
+an API rather close to the old SG:
\verbatim
______________________
| User code |
|____________________|
-| | MSG | GRAS | SG |
+| | MSG | GRAS | SD |
| -------------------|
| | SURF |
| -------------------|
----------------------
\endverbatim
-Re-implementing SG on top of SURF is really straightforward (it only
-requires a little bit of time that I really don't have right now)
-since the only thing that lacks to SURF is the DAG part. But adding it
-to SURF would slow it down and therefore slow MSG and GRAS which is
-not a good thing. However it is really not on the top of our TODO
-list because we have to work on GRAS, and its MPI counterpart, and a
-parallel task model, and ... Anyway, we finally have migrated our CVS
-to gforge so people that are interested by helping on this part will
-have the possibility to do it.
+The nice thing is that, as it is writen on top of SURF, it seamlessly
+support DAG of parallel tasks as well as complex communications
+patterns. Some old codes using SG are currently under rewrite using
+\ref SD_API to check that all needful functions are provided.
\subsection faq_SG_DAG How to implement a distributed dynamic scheduler of DAGs.
Distributed is somehow "contagious". If you start making distributed
-decisions, there is no way to handle DAGs directly anymore (unless I am
-missing something). You have to encode your DAGs in term of communicating
-process to make the whole scheduling process distributed. Believe me, it is
-worth the effort since you'll then be able to try your algorithms in a very
-wide variety of conditions. Here is an example of how you could do that.
-Assume T1 has to be done before T2.
+decisions, there is no way to handle DAGs directly anymore (unless I
+am missing something). You have to encode your DAGs in term of
+communicating process to make the whole scheduling process
+distributed. Here is an example of how you could do that. Assume T1
+has to be done before T2.
\verbatim
int your_agent(int argc, char *argv[] {
\endverbatim
If you decide that the distributed part is not that much important and that
-DAG is really the level of abstraction you want to work with (but it
-prevents you from having "realistic" platform modeling), then you should
-keep using the 2.18.5 versions until somebody has ported SG on top of SURF.
-Note however that SURF will be slower than the old SG to handle traces with
-a lots of variations (there is no trace integration anymore).
-
-\subsection faq_SG_future Will SG come back in the maintained branch one day?
-
-Sure. In fact, we already have thought about a new and cleaner API:
-\verbatim
-void* SG_link_get_data(SG_link_t link);
-void SG_link_set_data(SG_link_t link, void *data);
-const char* SG_link_get_name(SG_link_t link);
-double SG_link_get_capacity(SG_link_t link);
-double SG_link_get_current_bandwidth(SG_link_t link);
-double SG_link_get_current_latency(SG_link_t link);
-
-SG_workstation_t SG_workstation_get_by_name(const char *name);
-SG_workstation_t* SG_workstation_get_list(void);
-int SG_workstation_get_number(void);
-void SG_workstation_set_data(SG_workstation_t workstation, void *data);
-void * SG_workstation_get_data(SG_workstation_t workstation);
-const char* SG_workstation_get_name(SG_workstation_t workstation);
-SG_link_t* SG_workstation_route_get_list(SG_workstation_t src, SG_workstation_t dst);
-int SG_workstation_route_get_size(SG_workstation_t src, SG_workstation_t dst);
-double SG_workstation_get_power(SG_workstation_t workstation);
-double SG_workstation_get_available_power(SG_workstation_t workstation);
-
-SG_task_t SG_task_create(const char *name, void *data, double amount);
-int SG_task_schedule(SG_task_t task, int workstation_nb,
- SG_workstation_t **workstation_list, double *computation_amount,
- double *communication_amount, double rate);
-
-void* SG_task_get_data(SG_task_t task);
-void SG_task_set_data(SG_task_t task, void *data);
-const char* SG_task_get_name(SG_task_t task);
-double SG_task_get_amount(SG_task_t task);
-double SG_task_get_remaining_amount(SG_task_t task);
-void SG_task_dependency_add(const char *name, void *data, SG_task_t src, SG_task_t dst);
-void SG_task_dependency_remove(SG_task_t src, SG_task_t dst);
-e_SG_task_state_t SG_task_state_get(SG_task_t task); /* e_SG_task_state_t can be either SG_SCHEDULED, SG_RUNNING, SG_DONE, or SG_FAILED */
-void SG_task_watch(SG_task_t task, e_SG_task_state_t state); /* SG_simulate will stop as soon as the state of this task is the one given in argument.
- Watch-point is then automatically removed */
-void SG_task_unwatch(SG_task_t task, e_SG_task_state_t state);
-
-void SG_task_unschedule(SG_task_t task); /* change state and rerun.. */
-
-SG_task_t *SG_simulate(double how_long); /* returns a NULL-terminated array of SG_task_t whose state has changed */
-\endverbatim
-
-We're just looking for somebody to implement it... :)
+DAG is really the level of abstraction you want to work with, then you should
+give a try to \ref SD_API.
\section faq_dynamic Dynamic resources and platform building
There is several reasons which may cause the make check to fail on your
machine:
- - <b>You are using a borken compiler</b>.\n
- The symptom may be that the "make check" fails within testsuite/gras
- directory.\n
- For example, the breezy release of Ubuntu comes with a prerelease of the
- 4.0 gcc compiler. This version happens to be completely unusable, and you
- should install a gcc-3.4 compiler and change the /usr/bin/gcc link to let
- it point on /usr/bin/gcc-3.4.
- <b>You are using a borken libc (probably concerning the contextes)</b>.\n
The symptom is that the "make check" fails within the examples/msg directory.\n
By default, SimGrid uses something called ucontexts. This is part of the
concurently, but 5000 processes is still enough for most purposes, isn't
it?\n
This limitation is the reason why we insist on using this piece of ...
- software even if it's so troublesome.
+ software even if it's so troublesome.\n
+ <b>=> use --with-pthread on AMD64 architecture that do not have an
+ ultra-recent libc.</b>
+
- <b>There is a bug in SimGrid we aren't aware of</b>.\n
If none of the above apply, please drop us a mail on the mailing list so
that we can check it out.
- It was really boring to write 25,000 entries in the deployment file, so I wrote
a little script <tt>examples/gras/tokenS/make_deployment.pl</tt>, which you may
- want to adapt to your case.
+ want to adapt to your case. You could also think about hijacking
+ the SURFXML parser (have look at \ref faq_flexml_bypassing).
- The deployment file became quite big, so I had to do what is in the FAQ
entry \ref faq_flexml_limit
on your side... We have plenty of FAQ entries to redact and new
features to implement for the impenitents! ;)
+\subsection faq_big_fat_warning A BIG FAT WARNING is reported telling me that my platform and deployment files are too old.
+
+We have decided to change the units in SimGrid. Now we use Bytes, Flops and
+seconds instead of MBytes, MFlops and seconds... Units should be updated
+accordingly and the version of platform_description should be set to a
+valuer greater than 1:
+\verbatim
+ <platform_description version="1">
+\endverbatim
+You should try to use the surfxml_update.pl script that can be found
+<a href="http://gforge.inria.fr/plugins/scmcvs/cvsweb.php/contrib/platform_generation/?cvsroot=cvsroot%2Fsimgrid">here</a>.
+
\author Arnaud Legrand (arnaud.legrand::imag.fr)
\author Martin Quinson (martin.quinson::loria.fr)
