BLOGGING MEETS COMPUTATIONAL CHEMISTRY Dr Kieron Taylor University of Southampton*

Grid computing + lab notebooks

Managing concurrent jobs and handling the results.  Paper notebooks are a disaster for multiple computational jobs. Users must log file paths and job names by hand.  Simulation archive must be “synchronized” with the lab notebook.  Science is only as good as the record-keeping, particularly after significant time has elapsed.  It is easier to re-run than it is to figure out what happened to the answers!

Build a database? No!  Job management systems already exist e.g. eMinerals RMCS, but they only operate on one system. No help for trial runs on private hardware.  Chemistry simulations can generate gigabytes of data each. A complete archive is unmanageable, but we must keep the data while we process it.  Processing trajectories is often custom and not always suitable for Grids.  Management system still does not provide contextual scientific discourse.

Computational chemistry is one ongoing experiment  Simulations are not guaranteed to finish.  Parameters must be tweaked.  Surprisingly little real time is spent in “production”.  Failures often need careful examination before they can be fixed.  Data is static, but analysis and opinion can change over time. It is super-important to know what conditions a simulation was performed under.

Enter the Blog  Southampton University chemistry Bloggers attempt to extend blogging into a useful experimental tool.  Autoblogging laser rigs  Open science experimental blogs from people  Now computational chemistry too  Blogging must be worth the effort!

Blogging computational experiments  Writing a Blog entry requires thought and some presentational effort. This is irritating, but very useful in retrospect. Daily digest.  Computational jobs have input decks and result files that must be kept with the observations. Inter-Blog links do this well, but uploading files is a significant problem. Trajectories?  The Blog is useful for presenting progress to others. The work is already done.  Writing a Blog is easy. Writing a useful Blog is not.

Autoblogging eases the task  Manual Blog  User submits job  User collects results  User writes Blog entry  User uploads result files to Blog  User (maybe) assigns metadata  Autoblog  User submits job  Job submission system Blogs automatically at start.  Job submission system Blogs at end of job.

Blog-supported Grid computing Private Repository Blog API

Merits and limitations of Blogs  Blogs are stupid.  Blog posts are automatically chronological.  Writing a blog post forces the user to order their thoughts and present them on a regular basis.  Boss can easily see what people are getting up to.  Restricted access allows collaboration without global disclosure.  User defined tagging allows management of discrete experiments in addition to finding data by timestamp.

Better Blogs Blog API allows read and write, so we can write helper- tools to do additional actions for us.

The Future  Meta-Blog interface to collect together posts from different Blogs into one coherent report about an experiment.  Clever storage management on- and off-Grid. When is data truly dispensable?  Lablog 3.0, a better Blogging platform.  Easier Grid use for molecular simulations.  Researchers who can tell you what they did last year!

Acknowledgments  NGS staff: Jonathan Churchill, Gordon Brown, Keir Hawker  DL_POLY author: Dr William Smith (Daresbury)  DL_POLY user: Robert Hawtin (unknown)  Blog coder: Andrew Milsted (Southampton)