Sire

Big developments this week. At last, after much development and design, I finally now have a MonteCarlo class! So ok, how have I survived until now without having a MonteCarlo class? Well Python does go a long way to filling in missing functionality. But it can't beat finely crafted design. MonteCarlo is part of the Move hierarchy, which provides a way for pretty much all of the simulation moves that I can think of to operate on Systems when they are either local, or even dispersed over a cluster. Moves operate of groups of Molecules (MoleculeGroups). MonteCarlo moves use Samplers to randomly select molecules, residues or atoms from those groups (the Sampler class is also polymorphic). Moves can be nested (e.g. a MonteCarlo move can contain several MolecularDynamics moves or other MonteCarlo moves) and they can operate on arbitrary components or functions of the forcefield (which itself may contain several different energy representations of the system). What\'s more, the Moves can be placed into a group, which when run, can be interupted by another thread (play, pause, stop, restart) and snapshots of the current system and moves can be taken so that the simulation can be moved between processors, or streamed to a binary file for archive or later running. (and here you were thinking that MonteCarlo would just involve making random moves and accepting or rejecting via the Metropolis test..?)

One of the key design decisions that I took in the design of these Moves were that Move data was independent of System data. The reason for this is that there could be multiple different types of move operating on the same system and they shouldn't trample over one another. Also, it is pretty impossible for the System to "know" what data is required by a move, and how best to store that data so that it can be accessed efficiently, yet is also memory efficient. In contrast, moving all of the move data into the Move object itself means that the Move object can "own" the data, and therefore has complete freedom to optimise its storage and access, can know that the data is not going to be touched by other moves, and (obviously) knows exactly what data is required. So all fine and good? Just about. The biggest conceptual problem I had with this decision was that atom velocities are move data, and therefore should be part of the MolecularDynamics move and not part of the System. It took me a while to really accept that that was the right decision, as coordinates and velocities are nearly always placed together in other simulation codes. However, it is the right decision. Atom velocities only make sense for MD moves, and indeed a System is an inanimate, static object. It is the combination of a System with some Moves that make a Simulation.