Sire

Writing a program or library will always involve periods of time when you have to make critical decisions. Decisions that, once made, are pretty irreversible, and that will effect you, and everyone who uses your program and develops your program hereafter. Decisions with no clear right or wrong, but will be cursed by those that come after you as impossible and stupid mistakes that form the legacy bloat of a code, and that are held up as reasons to start again, and rewrite from scratch.

Finished the first set of documents so I am now at work coding again. It's been a while since the last time I hacked in anger, and in that time I have upgraded xcode... Oh dear... It has yet another tab interface with confusing controls. Why is it so difficult for Apple to provide a simple tabbed editor? I just want an interface where, if I open up 10 files, then they are arranged so that alt-right takes me up the list of files, and alt-left takes me down. Switching between files should be easy. But xcode has always failed to provide this.

I'm busy writing all of the documentation for the software development project. Its a lot of fun, as it is giving me the chance to put down on paper many things that have, until now, just been rattling around in my head, or buried in code. I'm writing the documentation on the other end of a dodgy internet connection (still waiting to move into my new place...), and it has got me thinking about how such documentation could be managed and shared with the community. In an ideal world, documentation would be written by a community, and edited in place and online.

I've spent the last couple of days writing the project and design documents for the software development project. Part of me just wants to get down and start coding (that's what is fun!), but I've come to see the value of document writing. It sets down the philosophy of what is being attempted, and provides a guide-rail that keeps development on track. It is also a good defence against bus-errors, or changes of management, as it means that everything is written down for easy sharing by a group.

Blogging is not my strength, and I never seem to find time to write anything about what I am up to! I think it is because I am too busy either coding, writing grant applications or papers. However, big changes are ahead for Sire. Yesterday marked the first day of a new, two-year, EPSRC-funded project that will use the code in Sire as a foundation for two new pieces of software;

(1) Aspire - an adaptive multiresolution dynamics program
(2) Acquire - a WorkPacket/WorkQueue scheduling system

Big news - I've heard that my paper that describes my new method for calculating absolute binding free energies has been accepted for publication in the Journal of Chemical Physics. I've blogged about the method before, and how the method was one of my main motivations for developing and designing Sire.

The bulk of Sire is now nearly complete, so I am now looking to the future of where the code will go next.
There are three main considerations;

(1) How can I make the code easier to install and maintain?
(2) How can I make the code easier to develop for new developers?
(3) What is the next major challenge that Sire needs to solve?

To answer points 1 or 2 I have been rewriting the underlying foundation of Sire so that
it has fewer dependencies and so that the object design is easy to understand and

Several years ago now, I had an idea of how to calculate absolute binding free energies by mutating ligands (or solutes) into water. The method would work by using two simulation boxes, one that contained just bulk water, and one that would contain the solvated protein-ligand complex. The boxes would both be connected to the same temperature, pressure and particle baths, so would both be in perfect equilibrium with one another (think Gibb's ensemble).

I realised this morning that Sire is very nearly there - by which I mean that the code is nearly at the point where it can be released. I (and others) have been using Sire for production calculations for a few months now, and the core APIs have been stable for over a year. Even the binary save file is pretty stable, and the code can do nearly everything that ProtoMS can do (and more). Before release I have a few jobs - the first is to write the amber forcefield readers, so that parameterising molecules and setting up simulations is easier.

Sire is now being used for full production simulations by several users. Again, the transition from a development code to a production code took me by surprise, but once it started working, then it was working very well. So far I have five users (including an installation at another university) and they are running a range of different simulations. What has been interesting is the ease by which they are able to modify the code to get it to do what they want.