|
Overview Check also the general FAQ and the Simulator005 FAQ. I already submitted a number of results-files, but nothing seems to happen. Do I compute for nothing? Multiprocessing: How to run simulations on multiple parallel CPUs? How do I know, if a simulator has completed all simulations? Do simulators disturb normal operation of the computer during work?
How do I start a simulation with these run-files? What if several people use the same run-file? What run-file should I choose? Are results lost if my computer crashes? How often do I submit results? What is the simulators folder? Security: Running the simulator at weekends... What do I do if I have problems with the simulator?
I already submitted a number of results-files, but nothing seems to happen. Do I compute for nothing?
No. All results-files you submit are being evaluated. However, as the automated
analysis modules have not yet been fully implemented, there are no high-scores statistics or other signs to show you progress. All run-files you find in the net still need further
computation. If you have further questions about this, email to info@evolutionary-research.net
. Multiprocessing: How to run simulations on multiple parallel CPUs?
The simulator uses only one CPU and is not aware of a multiprocessor system. If you want
to engage each CPU in a multiprocessor system, you have to start a process on each CPU. The following check-list may help you.
-
Make a seperate folder for each CPU. The simulator works heavily with its folder to check for break-files, read run-files, write progress-files, results-files and most critically
IntermediateResults files. The latter are needed to save intermediate results in case of a crash. If now several simulators would share one folder, several conflicts would arise:
- The IntermediateResult file belongs to the simulator that saved its latest version. All intermediate results of other simulators are lost completely. In case
of a crash, thus only the work of one CPU is saved.
- Different simulators may access the same run-file or results-file at the same time. This will lead to unpredicted situations, as the simulators have not been
programmed to handle this. In case of such a conflict, most probably one result to be saved gets lost and the simulator may terminate.
-
Check RAM-limitations: If you have a 2-way CPU with 512MB of shared memory, the maximum size of simulations is about 250 MB, if you want to busy both processors
with simulations of equal size. Of course you may use unequal distributions. In any case it is highly recommended, that you set corresponding RAM limits in the
preferences file to avoid accidental erroneous staring of simulations that need virtual memory. (This slows down simulator and system performance excessively, a lose-lose situation)
-
Avoid identical starttime of identical run-files: Each run-file needs to be computed several times, to repeat runs with different random seeds. The seeds, however, are
computed automatically from the systems ANSI-clock with a seconds precision. Now, if you have a series of folders with the same run-file and start the simulators
automatically via script, then most of them are likely to get the same start-time and thus RND-seed. This would make the run-files lead to identical results and thus not
help to estimate variance of the results. To avoid this you may
-
Use different run-files for CPUs starting exactly at the same time.
-
Split up run-files to smaller run-files: You may split anywhere between the basic units recognized by the simulator (i.e. ã&simulate ...<some numbers>
#ä). Everything between & and # is interpreted as a command. this may help to choose good split points.
-
Edit run-file copies manually: Move one simulate-command from the beginning of run-file copy 2 to the end. In run-file copy 3 you do that with the
first 2 simulate commands, .... Thus each simulator starts with a different simulation from the (originally same) run-file. Then identical seeds do not matter.
If you want to start many simulators over the network, this is generally possible. However, check for the simulators performance. As the simulators folder (somewhere else in the net) is
heavily used, performance may decrease drastically. To decrease simulators-folder access to a minimum, change the following entries in the preferences file to values like those listed below:
-
InterruptSlow: Check for break-file after so many individuals. Use current performance to estimate the number of seconds: with 0.2 MINDS, 200 000 * 600 =
every 10 minutes with a value of 120 000 000. (largest possible = 2 000 000 000: default = one check about every 2 seconds)
-
WriteProgressFileIntervallSec (Write one "eProgress.txt" file after how many seconds): 3600 => one such file every hour instead of every 2 minutes.
-
WriteLastParametersListFileIntervallMin (write a new ParametersList print out to file after how many minutes): 60 (minutes instead of 10)
- You may or may not want to increase the frequency of recording intermediate results: Write-intervall for intermediate results to disk in minutes = 60 = default.
If you notice any other thing that should be mentioned here, contact us. How do I know, if a simulator has completed all simulations?
After computing all the simulations stored in a run-file, the simulator quits and renames the run-file to completed-run-file.
Do simulators disturb normal operation of the computer during work? No, not really. As the priority of the process that needs computing time is set to the lowest possible level
under Windows, it completely backs of, if another application needs the CPU. However, when that is no longer the case, the CPU is used again for continuting the simulations. Thus you
should notice nothing during your normal work. However, as all simulators up to release 5 (of S005) do not make any pauses, the CPU is allways used up to nearly 100%. This may lead
to small delays of some operations on some computers, as Windows apparently needs some time to give processes with higher priorities everything they need.
Under MacOS, control is given back to the Finder about 100 times per second by default (release 5). You can change that value in the preferences by setting the number of individuals
computed every time the simulator gets control. If you increase the value you increase performance, if you decrease it, you increase responsiveness of the system. In daily use you
would not notice operation of the simulator with default interrupt behaviour, except when you use processor-intense applications like e.g. image processing or background printing of PDF
files to a ink-jet printer. In these situations, stop the simulator to get performance back to normal levels. How do I start a simulation with these run-files?
Just get the run-file you want in your browsers window, then save it under the name ãrunä as a text-file in your simulators folder. Then start the simulator. (If you did not enter the
preferences yet, then do it now.) What if several people use the same run-file? That is very good. The simulations computed by the simulator depend very much on
chance. Therefore each simulation is started with a unique random seed and starting the same set of parameters thus leads to different results. While the first run of a new parameter
combination leads allows one only to get a very rough feeling for the results, all other repeats are neccessary to compute mean and variance of the output-parameters. The larger the
variance the more simulations are needed to get accurate estimates. The more repeats are available, the higher is the accuracy of the statistics computed.
If you currently get no Internet connection, but your run-file has been completed, you may also rename it back to ãrunä and start it again. However, if possible, get fresh run-files from
this site, because keys that have been computed often enough are being removed from the runfiles to prevent excessive repetition of the first three run-files. What run-file should I choose? Generally, choose those run-files that need little less RAM than the maximum you can afford.
Furthermore, chose those files with the longest computing times you can imagine your computer to handle. And, please do not chose the first three run-files (as probably a lot of
people are going to do). Are results lost if my computer crashes? Yes, but only minimally. Each simulate-command from the run-file stands for a single run
whose results are stored to harddisk after it has been completed. So, such results are not lost by a crash. If you start a run that needs very long time, then each hour an intermediate
results-file is generated. For very long runs these intermediate can be very valuable, as it can be hard to complete the whole simulation. However, final results are always better. If evolution
is interrupted very often (due to a crash or other reasons), please choose run-files with simulations that need less time than the interrupts intervall. How often do I submit results? That is up to you. However, we suggest the following:
- whenever a run file has been completed
- after 2-4 weeks, if the run-file does not finish earier
- If a single simulation needs more than that, then submit results, whenever you see that this simulation has generated a real results file (=S005_RESULTS.txt, please do not submit IntermediateResults).
To submit results, remove the file ãS005_RESULTS.txtä from your simulators folder and email it as an attachment to simulator005@evolution-at-home.net . Then either delete it or store it
wherever you want, but not in the simulators folder! What is the simulators folder? Simply the folder, where the simulator program is stored on your hard disk. We suggest you
use something like ãevolution@homeä on your desktop to have everything easily accessible. Do not start the simulator in a folder that is not completely dedicated to evolution@home, as
it reads and writes in this folder as it wants. Security: Running the simulator at weekends...
Currently, the simulator needs to be started as any other program. This means that you need
an open user account to start the simulator automatically or manually. However, if you logoff, the simulator will be closed, as all other programs. If you now leave for weekend and want
your simulator to continue to run, you have to either
- Lock the door of the room with the computer with a key no untrusted person has access to
- Hide / encrypt all critical data on your disk in such a way that nobody can make use of it
- Have a screen saver with a good password and boot-protection (This however, is likely to reduce simulator performance)
If you can do neither, we suggest you stop the simulator and close your user account to make sure your data remains secure. What do I do if I have problems with the simulator? Look for a solution on the Problems
page or the specific simulators FAQ (S005). If nothing helps, contact bugs@evolution-at-home.net with a precise description of your problem. |