BLOGGING MEETS COMPUTATIONAL CHEMISTRYDr Kieron TaylorUniversity 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

http://blogs.chem.soton.ac.uk/shg Open science experimental blogs from

peoplehttp://blogs.chem.soton.ac.uk/neutral_drift

Now computational chemistry toohttp://blogs.chem.soton.ac.uk/kierons_flog

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 RepositoryBlog 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 BlogsBlog 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)