Blogging meets Computational Chemistry

1. Blogging meets Computational Chemistry Dr Kieron TaylorUniversity of Southampton*

2. Grid computing + lab notebooks

3. 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!

4. 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.

5. 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.

6. Enter the Blog • Southampton University chemistry Bloggers attempt to extend blogging into a useful experimental tool. • Autoblogging laser rigshttp://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!

7. 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.

8. 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.

9. Blog-supported Grid computing Private Repository Blog API

10. 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.

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

12. 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!

13. 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)