1 /*! \page faq Frequently Asked Questions
5 \section faq_installation Installing the SimGrid library
7 Many people have been asking me questions on how to use SimGrid. Quite
8 often, the questions were not really about SimGrid but on the
9 installation process. This section is intended to help people that are
10 not familiar with compiling C files under UNIX. If you follow these
11 instructions and still have some troubles, drop an e-mail to
12 <simgrid-user@lists.gforge.inria.fr>.
14 \subsection faq_compiling Compiling SimGrid
16 Suppose you have uncompressed SimGrid in some temporary location of
17 your home directory (say <tt>/home/joe/tmp/simgrid-2.18.2 </tt>). The
18 simplest way to use SimGrid is to install it in your home
19 directory. Change your directory to
20 <tt>/home/joe/tmp/simgrid-2.18.2</tt> and type
22 \verbatim./configure --prefix=$HOME
27 If at some point, something fails, you can report me this problem but,
28 please, avoid sending a laconic mail like "There is a problem. Is it
29 normal?". Send me the config.log file which is automatically
30 generated by configure. Try to capture both the standard output and
31 the error output of the <tt>make</tt> command. There is no way for me
32 to help you if you do not give me a little bit of information.
34 Now, the following directory should have been created :
36 \li <tt>/home/joe/doc/simgrid/html/</tt>
37 \li <tt>/home/joe/lib/</tt>
38 \li <tt>/home/joe/include/</tt>
40 SimGrid is not a binary, it is a library. Both a static and a dynamic
41 version are available. Here is what you can find if you try a <tt>ls
44 \verbatim libsimgrid.a libsimgrid.la libsimgrid.so libsimgrid.so.0 libsimgrid.so.0.0.1
47 Thus, there is two ways to link your program with SimGrid:
48 \li Either you use the static version, e.g
49 \verbatim gcc libsimgrid.a -o MainProgram MainProgram.c
51 In this case, all the SimGrid functions are directly
52 included in <tt>MainProgram</tt> (hence a bigger binary).
53 \li Either you use the dynamic version (the preferred method)
54 \verbatim gcc -lsimgrid -o MainProgram MainProgram.c
56 In this case, the SimGrid functions are not included in
57 <tt>MainProgram</tt> and you need to set your environment
58 variable in such a way that <tt>libsimgrid.so</tt> will be
59 found at runtime. This can be done by adding the following
60 line in your .bashrc (if you use bash and if you have
61 installed the SimGrid libraries in your home directory):
62 \verbatim export LD_LIBRARY_PATH=$HOME/lib/:$LD_LIBRARY_PATH
65 \subsection faq_setting Setting up your own code
67 Do not build your simulator by modifying the SimGrid examples. Go
68 outside the SimGrid source tree and create your own working directory
69 (say <tt>/home/joe/SimGrid/MyFirstScheduler/</tt>).
71 Suppose your simulation has the following structure (remember it is
72 just an example to illustrate a possible way to compile everything;
73 feel free to organize it as you want).
75 \li <tt>sched.h</tt>: a description of the core of the
76 scheduler (i.e. which functions are can be used by the
77 agents). For example we could find the following functions
78 (master, forwarder, slave).
80 \li <tt>sched.c</tt>: a C file including <tt>sched.h</tt> and
81 implementing the core of the scheduler. Most of these
82 functions use the MSG functions defined in section \ref
85 \li <tt>masterslave.c</tt>: a C file with the main function, i.e.
86 the MSG initialization (MSG_global_init()), the platform
87 creation (e.g. with MSG_create_environment()), the
88 deployment phase (e.g. with MSG_function_register() and
89 MSG_launch_application()) and the call to
92 To compile such a program, we suggest to use the following
93 Makefile. It is a generic Makefile that we have used many times with
94 our students when we teach the C language.
98 masterslave: masterslave.o sched.o
100 INSTALL_PATH = $$HOME
102 PEDANTIC_PARANOID_FREAK = -O0 -Wshadow -Wcast-align \
103 -Waggregate-return -Wmissing-prototypes -Wmissing-declarations \
104 -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations \
105 -Wmissing-noreturn -Wredundant-decls -Wnested-externs \
106 -Wpointer-arith -Wwrite-strings -finline-functions
107 REASONABLY_CAREFUL_DUDE = -Wall
108 NO_PRAYER_FOR_THE_WICKED = -w -O2
109 WARNINGS = $(REASONABLY_CAREFUL_DUDE)
110 CFLAGS = -g $(WARNINGS)
112 INCLUDES = -I$(INSTALL_PATH)/include
113 DEFS = -L$(INSTALL_PATH)/lib/
114 LDADD = -lm -lsimgrid
118 $(CC) $(INCLUDES) $(DEFS) $(CFLAGS) $^ $(LIBS) $(LDADD) -o $@
121 $(CC) $(INCLUDES) $(DEFS) $(CFLAGS) -c -o $@ $<
124 rm -f $(BIN_FILES) *.o *~
130 The first two lines indicates what should be build when typing make
131 (<tt>masterslave</tt>) and of which files it is to be made of
132 (<tt>masterslave.o</tt> and <tt>sched.o</tt>). This makefile assumes
133 that you have set up correctly your <tt>LD_LIBRARY_PATH</tt> variable
134 (look, there is a <tt>LDADD = -lm -lsimgrid</tt>). If you prefer using
135 the static version, remove the <tt>-lsimgrid</tt> and add a
136 <tt>$(INSTALL_PATH)/lib/libsimgrid.a</tt> on the next line, right
137 after the <tt>LIBS = </tt>.
139 More generally, if you have never written a Makefile by yourself, type
140 in a terminal : <tt>info make</tt> and read the introduction. The
141 previous example should be enough for a first try but you may want to
142 perform some more complex compilations...
144 \section faq_simgrid I'm new to SimGrid. I have some questions. Where should I start?
146 You are at the right place... Having a look to these
147 <a href="http://graal.ens-lyon.fr/~alegrand/articles/Simgrid-Introduction.pdf">slides</a>
148 may give you some insights on what SimGrid can help you to do and what
149 are its limitations. Then you definitely should read the \ref
150 MSG_examples. There is also a mailing list: <simgrid-user@lists.gforge.inria.fr>.
152 \subsection faq_generic Building a generic simulator
154 Please read carefully the \ref MSG_examples. You'll find in \ref
155 MSG_ex_master_slave a very simple consisting of a master (that owns a bunch of
156 tasks and distributes them) , some slaves (that process tasks whenever
157 they receive one) and some forwarder agents (that simply pass the
158 tasks they receive to some slaves).
160 \subsection faq_visualization Visualizing the schedule
162 It is sometime convenient to "see" how the agents are behaving. If you
163 like colors, you can use <tt>tools/MSG_visualization/colorize.pl </tt>
164 as a filter to your MSG outputs. It works directly with INFO. Beware,
165 INFO() prints on stderr. Do not forget to redirect if you want to
166 filter (e.g. with bash):
168 ./msg_test small_platform.xml small_deployment.xml 2>&1 | ../../tools/MSG_visualization/colorize.pl
171 We also have a more graphical output. Have a look at MSG_paje_output(). It
172 generates an input to <a href="http://www-id.imag.fr/Logiciels/paje/">Paje</a>.
175 <a href="Paje_MSG_screenshot.jpg"><img src="Paje_MSG_screenshot_thn.jpg"></a>
179 \subsection faq_postmortem_analysis Online/postmortem analysis
181 Vizualization with Paje can be seen as a kind of postmortem
182 analysis. However, as soon as you start playing with big simulations,
183 you'll realize that processing such output is kind of tricky. There is
184 so much generic informations that it is hard to find the information
187 As a matter of fact, loging really depends on simulations (e.g. what
188 kind of events is important...). That is why we do not propose a big
189 dump of your whole simulation (it would slow everything down) but give
190 you neat tools to structure you logs. Have a look at \ref XBT_log. In
191 fact, rather than a post-mortem analysis, you may want to do it on the
192 fly. The process you are running can do whatever you want. Have you
193 thought about adding a global structure where you directly compute the
194 informations that are really important rather than writing everything
195 down and then processing huge files ?
197 \section faq_questions How to ....? Is there a function in the API to simply ....?
199 Here is the deal. The whole SimGrid project (MSG, SURF, GRAS, ...) is
200 meant to be kept as simple and generic as possible. We cannot add
201 functions for everybody's need when these functions can easily be
202 built from the ones already in the API. Most of the time, it is
203 possible and when it was not possible we always have upgraded the API
204 accordingly. When somebody asks us a question like "How to do that ?
205 Is there a function in the API to simply do this ?", we're always glad
206 to answer and help. However if we don't need this code for our own
207 need, there is no chance we're going to write it... it's your job! :)
208 The counterpart to our answers is that once you come up with a neat
209 implementation of this feature (task duplication, RPC, thread
210 synchronization, ...), you should send it to us and we will be glad to
211 add it to the distribution. Thus, other people will take advantage of
212 it (and we don't have to answer this question again and again ;).
214 You'll find in this section a few "Missing In Action" features. Many
215 people have asked about it and we have given hints on how to simply do
216 it with MSG. Feel free to contribute...
218 \subsection faq_examples I want some more complex examples!
220 Many people have come to ask me a more complex example and each time,
221 they have realized afterward that the basics were in the previous three
224 Of course they have often been needing more complex functions like
225 MSG_process_suspend(), MSG_process_resume() and
226 MSG_process_isSuspended() (to perform synchronization), or
227 MSG_task_Iprobe() and MSG_process_sleep() (to avoid blocking
228 receptions), or even MSG_process_create() (to design asynchronous
229 communications or computations). But the examples are sufficient to
232 We know. We should add some more examples, but not really some more
233 complex ones... We should add some examples that illustrate some other
234 functionalities (like how to simply encode asynchronous
235 communications, RPC, process migrations, thread synchronization, ...)
236 and we will do it when we will have a little bit more time. We have
237 tried to document the examples so that they are understandable. Tell
238 us if something is not clear and once again feel free to participate!
241 \subsection faq_examples_MIA_taskdup Missing in action: Task duplication/replication
243 There is no task duplication in MSG. When you create a task, you can
244 process it or send it somewhere else. As soon as a process has sent
245 this task, he doesn't have this task anymore. It's gone. The receiver
246 process has got the task. However, you could decide upon receiving to
247 create a "copy" of a task but you have to handle by yourself the
248 semantic associated to this "duplication".
250 As we already told, we prefer keeping the API as simple as
251 possible. This kind of feature is rather easy to implement by users
252 and the semantic you associate really depends on people. Having a
253 *generic* task duplication mechanism is not that trivial (in
254 particular because of the data field). That is why I would recommand
255 that you write it by yourself even if I can give you advice on how to
258 You have the following functions to get informations about a task:
259 MSG_task_get_name(), MSG_task_get_compute_duration(),
260 MSG_task_get_remaining_computation(), MSG_task_get_data_size(),
261 and MSG_task_get_data().
263 You could use a dictionnary (#xbt_dict_t) of dynars (#xbt_dict_t). If
264 you still don't see how to do it, please come back to us...
266 \subsection faq_examples_MIA_asynchronous I want to do asynchronous communications.
268 Up until now, there is no asynchronous communications in MSG. However,
269 you can create as many process as you want so you should be able to do
270 whatever you want... I've written a queue module to help implementing
271 some asynchronous communications at low cost (creating thousands of
272 process only to handle communications may be problematic in term of
273 performance at some point). I'll add it in the distribution asap.
275 \subsection faq_examples_MIA_thread_synchronization I need to synchronize my process
277 You obviously cannot use pthread_mutexes of pthread_conds. The best
278 thing would be to propose similar structures. Unfortunately, we
279 haven't found time to do it yet. However you can try to play with
280 MSG_process_suspend() and MSG_process_resume(). You can even do some
281 synchronization with fake communications (using MSG_task_get(),
282 MSG_task_put() and MSG_task_Iprobe()).
284 \section faq_SG Where has SG disappeared?!?
286 OK, it's time to explain what's happening to the SimGrid project. Let's
287 start with a little bit of history.
289 * Historically, SimGrid was a low-level toolkit for scheduling with
290 classical models such as DAGs. That was SimGrid v.1.* aka SG, written
291 by Henri Casanova. I (Arnaud) had been using it in its earliest
292 versions during an internship at UCSD.
294 Then we have realized that encoding distributed algorithm in SG was a
297 * So we have built MSG on top of SG and have released SimGrid v.2.*. MSG
298 offered a very basic API to encode a distributed application easily.
299 However encoding MSG on top of SG was not really convenient and did not
300 use the DAG part since the control of the task synchronization was done
301 on top of MSG and no more in SG. We have been playing a little bit with
302 MSG. We have realized that:
304 \li 1) the platform modeling was quite flexible and could be "almost"
305 automated (e.g. using random generator and post-annotations);
307 \li 2) SG was the bottleneck because of the way we were using
308 it. We needed to simulate concurrent transfers, complex load
309 sharing mechanisms. Many optimizations (e.g. trace integration)
310 were totally inefficient when combined with MSG and made extending SG
311 to implement new sharing policies, parallel tasks models, or failures
312 (many people were asking for these kind of features) a real pain;
314 \li 3) the application modeling was not really easy. Even though the
315 application modeling depends on people's applications, we thought
316 we could improve things here. One of our target here was realistic
317 distributed applications ranging from computer sensor networks like
318 the NWS to peer-to-peer applications;
320 * So we have been planning mainly two things for SimGrid 3:
322 \li 1) I have proposed to get rid of SG and to re-implement a new kernel
323 that would be faster and more flexible. That is what I did in the
324 end of 2004: SURF. SURF is based on a fast max-min linear solver
325 using O(1) data-structures. I have quickly replaced SG by SURF in
326 MSG and the result has been that on the MSG example, the new
327 version was more than 10 times faster while we had gain a lot of
328 flexibility. I think I could still easily make MSG faster but I
329 have to work on MSG now (e.g. using some of the O(1)
330 data-structures I've been using to build SURF) since it has become
331 the bottleneck. Some MSG functions have been removed from the API
332 but they were mainly intended to build the platform by hand (they
333 had appeared in the earliest versions of MSG) and were therefore
334 not useful anymore since we are providing a complete mechanism to
335 automatically build the platform and deploy the agents on it.;
337 \li 2) GRAS is a new project Martin and I have come up with. The idea is
338 to have a programming environment that let you program real
339 distributed applications while letting you the ability to run it in
340 the simulator without having to change the slightest line of your
341 code. From the simulation point of view, GRAS performs the
342 application modeling automatically... Up until now, GRAS works on
343 top MSG for historical reasons but I'm going to make it work
344 directly on top of SURF so that it can use all the flex and the
345 speed provided by SURF.
347 Those two things are working, but we want to make everything as clean as
348 possible before releasing SimGrid v.3.
350 So what about those nice DAGs we used to have in SimGrid v.1.? They're not
351 anymore in SimGrid v.3. Let me recall you the way SimGrid 3 is organized:
365 XBT is our tool box and now, you should have an idea of what the other ones
366 are. As you can see, the primitive SG is not here anymore. However it could
367 still be brought back if people really need it. Here is how it would fit.
370 ______________________
372 |____________________|
373 | | MSG | GRAS | SG |
374 | -------------------|
376 | -------------------|
378 ----------------------
381 Re-implementing SG on top of SURF is really straightforward (it only
382 requires a little bit of time that I really don't have right now)
383 since the only thing that lacks to SURF is the DAG part. But adding it
384 to SURF would slow it down and therefore slow MSG and GRAS which is
385 not a good thing. However it is really not on the top of our TODO
386 list because we have to work on GRAS, and its MPI counterpart, and a
387 parallel task model, and ... Anyway, we finally have migrated our CVS
388 to gforge so people that are interested by helping on this part will
389 have the possibility to do it.
391 \subsection faq_SG_DAG But I wanted to implement a distributed dynamic scheduler of DAGs... How can I do that if SG is not available anymore in the next versions?
393 Distributed is somehow "contagious". If you start making distributed
394 decisions, there is no way to handle DAGs directly anymore (unless I am
395 missing something). You have to encode your DAGs in term of communicating
396 process to make the whole scheduling process distributed. Believe me, it is
397 worth the effort since you'll then be able to try your algorithms in a very
398 wide variety of conditions.
400 If you decide that the distributed part is not that much important and that
401 DAG is really the level of abstraction you want to work with (but it
402 prevents you from having "realistic" platform modeling), then you should
403 keep using the 2.18.5 versions until somebody has ported SG on top of SURF.
404 Note however that SURF will be slower than the old SG to handle traces with
405 a lots of variations (there is no trace integration anymore).
407 \section faq_dynamic Dynamic resources and platform building
409 \subsection faq_platform Building a realistic platform
411 We can speak more than an hour on this subject and we still do not have
412 the right answer, just some ideas. You can read the following
413 <a href="http://graal.ens-lyon.fr/~alegrand/articles/Simgrid-Introduction.pdf">slides</a>.
414 It may give you some hints. You can also have a look at the
415 <tt>tools/platform_generation/</tt> directory. There is a perl-script
416 we use to annotate a Tiers generated platform.
418 \subsection faq_SURF_dynamic How can I have variable resource availability?
420 A nice feature of SimGrid is that it enables you to seamlessly have
421 resources whose availability change over time. When you build a
422 platform, you generally declare CPUs like that:
425 <cpu name="Cpu A" power="100.00"/>
428 If you want the availability of "CPU A" to change over time, the only
429 thing you have to do is change this definition like that:
432 <cpu name="Cpu A" power="100.00" availability_file="trace_A.txt" state_file="trace_A_failure.txt"/>
435 For CPUs, availability files are expressed in fraction of available
436 power. Let's have a look at what "trace_A.txt" may look like:
445 At time 0, our CPU will deliver 100 Mflop/s. At time 11.0, it will
446 deliver only 50 Mflop/s until time 20.0 where it will will start
447 delivering 90 Mflop/s. Last at time 21.0 (20.0 plus the periodicity
448 1.0), we'll be back to the beginning and it will deliver 100Mflop/s.
450 Now let's look at the state file:
457 A negative value means "off" while a positive one means "on". At time
458 1.0, the CPU is on. At time 1.0, it is turned off and at time 2.0, it
459 is turned on again until time 12 (2.0 plus the periodicity 10.0). It
460 will be turned on again at time 13.0 until time 23.0, and so on.
462 Now, let's look how the same kind of thing can be done for network
463 links. A usual declaration looks like:
466 <network_link name="LinkA" bandwidth="10.0" latency="0.2"/>
469 You have at your disposal the following options: bandwidth_file,
470 latency_file and state_file. The only difference with CPUs is that
471 bandwidth_file and latency_file do not express fraction of available
472 power but are expressed directly in Mb/s and seconds.
474 \subsection faq_host_load Where is the get_host_load function hidden in MSG?
476 There is no such thing because its semantic wouldn't be really clear. Of
477 course, it is something about the amount of host throughput, but there is as
478 many definition of "host load" as people asking for this function.
480 It may be instantaneous value or an average one. Moreover it may be only the
481 power of the computer, or may take the background load into account, or may
482 even take the currently running tasks into account. In some SURF models,
483 communications have an influence on computational power. Should it be taken
486 So, we decided not to include such a function into MSG and let people do it
487 thereselves so that they get the value matching exactly what they mean. One
488 possibility is to run active measurement as in next code snippet. It is very
489 close from what you would have to do out of the simulator, and thus gives
490 you information that you could also get in real settings to not hinder the
491 realism of your simulation.
494 double get_host_load() {
495 m_task_t task = MSG_task_create("test", 0.001, 0, NULL);
496 double date = MSG_get_clock();
498 MSG_task_execute(task);
499 date = MSG_get_clock() - date;
500 MSG_task_destroy(task);
505 Of course, it may not match your personal definition of "host load". In this
506 case, please detail what you mean on the mailing list, and we will extend
507 this FAQ section to fit your taste if possible.
509 \subsection faq_flexml_bypassing How could I have some C functions do what the platform and deployment files do?
511 So you want to bypass the XML files parser, uh? Maybe doin some parameter
512 sweep experiments on your simulations or so? This is possible, but it's not
513 really easy. Here is how it goes.
515 For this, you have to first remember that the XML parsing in SimGrid is done
516 using a tool called FleXML. Given a DTD, this gives a flex-based parser. If
517 you want to bypass the parser, you need to provide some code mimicking what
518 it does and replacing it in its interactions with the SURF code. So, let's
519 have a look at these interactions.
521 FleXML parser are close to classical SAX parsers. It means that a
522 well-formed SimGrid platform XML file might result in the following
525 - start "platform_description"
526 - start "cpu" with attributes name="host1" power="1.0"
528 - start "cpu" with attributes name="host2" power="2.0"
530 - start "network_link" with ...
532 - start "route" with ...
534 - start "route" with ...
536 - end "platform_description"
538 The communication from the parser to the SURF code uses two means:
539 Attributes get copied into some global variables, and a surf-provided
540 function gets called by the parser for each event. For example, the event
541 - start "cpu" with attributes name="host1" power="1.0"
543 let the parser do the equivalent of:
545 strcpy("host1",A_cpu_name);
550 In SURF, we attach callbacks to the different events by initializing the
551 pointer functions to some the right surf functions. Example in
552 workstation_KCCFLN05.c (surf_parse_open() ends up calling surf_parse()):
554 // Building the routes
555 surf_parse_reset_parser();
556 STag_route_fun=parse_route_set_endpoints;
557 ETag_route_element_fun=parse_route_elem;
558 ETag_route_fun=parse_route_set_route;
559 surf_parse_open(file);
560 xbt_assert1((!surf_parse()),"Parse error in %s",file);
564 So, to bypass the FleXML parser, you need to write your own version of the
565 surf_parse function, which should do the following:
566 - Call the corresponding STag_<tag>_fun function to simulate tag start
567 - Fill the A_<tag>_<attribute> variables with the wanted values
568 - Call the corresponding ETag_<tag>_fun function to simulate tag end
569 - (do the same for the next set of values, and loop)
571 Then, tell SimGrid that you want to use your own "parser" instead of the stock one:
573 surf_parse = surf_parse_bypass;
574 MSG_create_environment(NULL);
577 An example of this trick is distributed in the file examples/msg/msg_test_surfxml_bypassed.c
579 \section faq_troubleshooting Troubleshooting
581 \subsection faq_context_1000 I want thousands of simulated processes
583 SimGrid can use either pthreads library or the UNIX98 contextes. On most
584 systems, the number of pthreads is limited and then your simulation may be
585 limited for a stupid reason. This is especially true with the current linux
586 pthreads, and I cannot get more than 2000 simulated processes with pthreads
587 on my box. The UNIX98 contexts allow me to raise the limit to 25,000
588 simulated processes on my laptop.
590 The <tt>--with-context</tt> option of the <tt>./configure</tt> script allows
591 you to choose between UNIX98 contextes (<tt>--with-context=ucontext</tt>)
592 and the pthread version ( (<tt>--with-context=pthread</tt>). The default
593 value is ucontext when the script detect a working UNIX98 context
594 implementation. On Windows boxes, the provided value is discarded and an
595 adapted version is picked up.
597 We experienced some issues with contextes on some rare systems (solaris 8
598 and lower comes to mind). The main problem is that the configure script
599 detect the contextes as being functional when it's not true. If you happen
600 to use such a system, switch manually to the pthread version, and provide us
601 with a good patch for the configure script so that it is done automatically ;)
603 \subsection faq_context_10000 I want hundred thousands of simulated processes
605 As explained above, SimGrid can use UNIX98 contextes to represent and handle
606 the simulated processes. Thanks to this, the main limitation to the number
607 of simulated processes becomes the available memory.
609 Here are some tricks I had to use in order to run a token ring between
610 25,000 processes on my laptop (1Gb memory, 1.5Gb swap).
612 - First of all, make sure your code runs for a few hundreds processes
613 before trying to push the limit. Make sure it's valgrind-clean, ie that
614 valgrind does not report neither memory error nor memory leaks. Indeed,
615 numerous simulated processes result in *fat* simulation hindering debugging.
617 - It was really boring to write 25,000 entries in the deployment file, so I wrote
618 a little script <tt>examples/gras/tokenS/make_deployment.pl</tt>, which you may
619 want to adapt to your case.
621 - The deployment file became quite big, so I had to do what is in the FAQ
622 entry \ref faq_flexml_limit
624 - Each UNIX98 context has its own stack entry. As debugging this is quite
625 hairly, the default value is a bit overestimated so that user don't get
626 into trouble about this. You want to tune this size to increse the number
627 of processes. This is the <tt>STACK_SIZE</tt> define in
628 <tt>src/xbt/context_private.h</tt>, which is 128kb by default.
629 Reduce this as much as you can, but be warned that if this value is too
630 low, you'll get a segfault. The token ring example, which is quite simple,
631 runs with 40kb stacks.
633 \subsection faq_flexml_limit I get the message "surf_parse_lex: Assertion `next<limit' failed."
635 This is because your platform file is too big for the parser.
637 Actually, the message comes directly from FleXML, the technology on top of
638 which the parser is built. FleXML has the bad idea of fetching the whole
639 document in memory before parsing it. And moreover, the memory buffer size
640 must be determinded at compilation time.
642 We use a value which seems big enough for our need without bloating the
643 simulators footprints. But of course your mileage may vary. In this case,
644 just edit src/surf/surfxml.l modify the definition of
645 FLEXML_BUFFERSTACKSIZE. E.g.
648 #define FLEXML_BUFFERSTACKSIZE 1000000000
651 Then recompile and everything should be fine, provided that your version of
652 Flex is recent enough (>= 2.5.31). If not the compilation process should
655 A while ago, we worked on FleXML to reduce a bit its memory consumtion, but
656 these issues remain. There is two things we should do:
658 - use a dynamic buffer instead of a static one so that the only limit
659 becomes your memory, not a stupid constant fixed at compilation time
660 (maybe not so difficult).
661 - change the parser so that it does not need to get the whole file in
662 memory before parsing
663 (seems quite difficult, but I'm a complete newbe wrt flex stuff).
665 These are changes to FleXML itself, not SimGrid. But since we kinda hijacked
666 the development of FleXML, I can grant you that any patches would be really
667 welcome and quickly integrated.
669 \author Arnaud Legrand (arnaud.legran::imag.fr)
670 \author Martin Quinson (martin.quinson::loria.fr)