We're looking for more developers. Want to contribute? Join the Mailing List and introduce yourself, or contact Bruce Damer directly.
Latest News
ALife XII CompOrigins call for papers.

Prototype2009: Components

From The EvoGrid: The Evolution Technology Grid

Jump to: navigation, search

Contents

Simulation Manager

This component acts as the central data distribution point for the batch processing. This uses HTTP for communication, and provides either human targeted XHTML or machine readable JSON.

The Simulation Manager accepts, stores and provides:

  • Specification for pending simulation jobs
  • Histories of completed simulations, for processing by analyzer functions
  • Statistics generation by analyzer functions, for processing by searching functions
  • Scores generated by both analyzer functions and searching functions.

Due to the amount of data being stored and transmitted, the hardware requirements for a Simulation Manager include disk for file storage, and database storage.

The Simulation Manager provides a method for daemons to request “pending” variations on data to be processed. This allows the Simulation Manager to choose what order data should be processed in, particularly simulation specifications.

To date, the selection method used is ordering by the “priority” property, then random selection from items with the highest priority.

Statistics and scores are currently accepted in an open manner, in that any statistic or score name can be used, and this will be automatically added to the storage database.

If there are no pending simulation specifications, then the Simulation Manager generates new ones, by providing random parameters. The random parameters include the number of atom types present in the simulation. Currently, this seed generation is the only point capable of varying the number of atom types present. The current search function implementation does not alter this.

Simulator

The Simulator component retrieves pending simulation job specifications from the Simulation Manager, performs these jobs and submits the history back to the Simulation Manager.

This is a multiple stage process.

  1. The daemon executable retrieves a JSON formatted specification for the simulation.
  2. The daemon generates any data not specified in the JSON specification. This includes atom position, velocity and type, based on information that must be in the JSON specification.
  3. The daemon produces a GROMACS format simulation specification file. This is specified in the GROMACS binary TPR format. The Energy Minimization option is specified, which instructs GROMACS to remove any overlapping or impossible placement of atoms, due to random generation.
  4. GROMACS is executed, with the TPR file for configuration.
  5. The daemon reads the produced TRJ file, merging the energy minimized atom positions into the simulation specification.
  6. The daemon produces a GROMACS TPR file, with Molecular Dynamics enabled.
  7. GROMACS is executed, with the TPR file for configuration.
  8. The daemon reads the produced TRJ file. The atom positions and velocities are extracted.
  9. Bond formation is performed by the daemon.
  10. History data in EvoGrid format is written to disk.
  11. Steps 6 through 10 are repeated, until the number of repetitions specified in the JSON specification has been completed.
  12. History data is submitted to the Simulation Manager.

Specific Details

GROMACS 3.3 is used. The TPR file specifies only a single processor to be used, for simplicity.

The run/stop/process usage of GROMACS is inefficient, but was the simplest way to implement the bond formation. This method of bond formation was chosen as the Quantum Mechanics features of GROMACS (which performs the same functionality) was not understood at the time. Part way through development it was realized that using QM would be a much better implementation, however it was decided to continue with implementing the current basic method to allow development to continue on the other parts of the system as soon as possible.

Analysis Daemon

This daemon retrieves simulation histories then performs per-frame analysis on the data. Each analysis produces a single floating point value, specified per frame.

Once per-frame analysis is completed, score analysis is performed by processing the per-frame statistics. Each score analysis produces a single floating point value, that describes the simulation history as a whole.

The per-frame statistics and simulation scores are submitted to the Simulation Manager.

Search Daemon

This daemon retrieves simulation scores and performs analysis on these to produce a single floating point score. This score is relevant to the particular search being performed.

The search daemon submits the specifications of any additional simulations it requires, to be queued for later simulation. The submitted specifications include the “parent simulation” property, which specifies which simulation result was used to produce the new simulation specification, and the “priority” property, which is set to the search score.

Personal tools