Sire

I've made a lot of progress over the last week. With Sire, I have worked out the design for the System, Simulation and Processor classes. The design solves the problem of using implicitly shared and easy to copy System / ForceField classes with the single-instance Simulation and Processor classes. The problem is that while I can copy ForceField until the cows come home, I cannot copy Processor (as this may be a unique link to a single remote resource, e.g. a molpro server). I think that the design now is quite elegant - you set up a System, which is copyable and editable etc. Then you place the System on a Simulation, which itself can contain named Processors. The Simulation will extract from System everything that it will need, and will place the ForceFields in the System onto different Processors, according to their name (and what the user has specified). A Simulation is non-copyable, and has its own internal copy of the System and Forcefields. This means that the user is free to modify the original System and put it in other Simulations without worrying about messing up the currently running Simulation (which itself could have been placed on another Processor on in another Thread). As the Simulation is working on its own copies of the data, it also doesn't have to worry about using mutexes etc. to lock access to that data.

The (perhaps obvious) reason for me to be thinking about this now is that I have just about finished the molpro interface. I have already now used the interface to run a primitive QM Monte Carlo simulation of a water dimer from Python using Sire to provide all of the molecule machinery (e.g. writing a molecule to a PDB file, translating a molecule etc). I have written C, C++ and Python bindings for the molpro client library, and am happy now that I understand how RPC works, and that the client-server link is working well. Initial benchmarks suggest that the use of RPC speeds up the interface by about an order of magnitude compared to writing input files, using system(molpro) and parsing the output file. Of course this speed up is system-size dependent, but its not too bad ;-). I'm currently working on exposing the lattice points functionality of molpro, so that I can add 'sparkles' to the calculation (thus allowing QM/MM to run through the inteface). The good thing so far is that my benchmarks have shown that a QM/MM Monte Carlo simulation using this interface is tractable, and indeed is not as slow as I was originally worrying. I am thus now very confident that I can use my existing methods of speeding up the QM/MM MC move with this interface to create a very snappy, ab-initio QM/MM MC simulation.