[Evogrid-dev] Current state and needs

[Bruce Damer]

Great summary and progress Peter, perhaps you could send the request  
for resources to John Graham?

Bruce
(on his iPhone)

On Jul 23, 2010, at 6:14 AM, Peter Newman  
<peter.newman at digitalspace.com> wrote:

>  We now have all the branching algorithms we planned implemented.
> - heat goes up / down
> - bond breaking
> - washes
> - random charge changes
> - no change
>
> Currently these produce approximately 18 branches per simulation run
> completed. This number will increase as complexity increases, since  
> each
> bond made is submitted as potentially broken.
>
> In my own "local" grid, of one simulator/analysis/branching machine  
> and
> one web server (simulation manager), I've completed 5 jobs so far.  
> Each
> takes approximately 7 hours, by my off the cuff estimation (25 seconds
> per loop, 1000 loops).
>
> We have currently implemented only one search function - number of
> molecules consisting of 2 or more atoms. We still intend to implement:
> - large molecules (even one of, chains, or things with lots of  
> branches
> etc)
> - many types (lots of variety)
> - frequently occurring single type (doesn't care what type it is, but
> that it happens a lot)
> - look for two frequently occurring types
>
> Each of these searches runs as a separate search tree - referred to as
> an individual "experiment".
>
> We have discussed (off list) what can be used as a testing control for
> the EvoGrid system at large. We've considered having a no-branching
> experiment, but this really means the control would not match against
> the experiment. We've also considered halting the branching after a
> period of time, and simulating all the pending branches already added,
> but it occurs to me this would not really be ideal. It occured to me
> just now that we can implement a "search" that does all the same
> branching, but always returns 0 as a fitness value. This will make the
> system simply choose randomly from the available branches. This  
> seems to
> me to be the fairest comparison, comparing an undirected branching  
> tree
> against the directed branching trees.
>
> With this in mind, this means we would be running a minimum of 6
> experiments simultaneously. To give a good number of generations, and
> chances for back-tracking, we need a large number of simulations, with
> more always being better.
>
> If doing 100 simulations, 6 experiments, taking 7 hours of computer  
> time
> each, we need 4200 hours of computer time. To give a scale to this,
> there is approximately 630 hours (26 days) until ALife12, where it  
> would
> be good to be able to discuss actual results. While we can discuss
> results to date, longer search trees are obviously better. Note that  
> if
> the simulation machine is shut down during a run, the simulation  
> manager
> reports the simulation as a failure, assuming the simulator crashed
> before completing the 1000 frames of simulation. (This needs  
> improving.)
> This prevents that branch being followed.
>
> My immediate goal is to implement the remaining search functions, then
> package this up into a distributable Debian package format. It is my
> hope that we will be able to get some donated computer time, on  
> machines
> either running Debian, or virtual machines running on Windows hosts.
> However, before this should be distributed, we will need a central
> internet-based simulation manager. Splitting this off into separate
> mini-grids will fragment the simulation hours, as well as the stored
> results. The simulation manager is a straight forward PHP/MySQL  
> system,
> but will need bandwidth and storage for the simulation histories.  
> Using
> the above numbers of 100 simulations for 6 experiments, and the data
> already produced, I estimate approximately 41GB of storage will be
> required for histories alone. (The system supports this being  
> compressed
> by approximately 50% for storage, but does not currently do it
> automatically.)
>
> So, there's the current state and needs laid out on the table.
>
> Peter N
> _______________________________________________
> Evogrid-dev mailing list
> Evogrid-dev at lists.digitalspace.com
> http://lists.digitalspace.com/cgi-bin/mailman/listinfo/evogrid-dev