A little update, since I've been playing with this recently.

First, this is about "indirect control" engines, which use an external process to run dynamics, and check the output file as it is written. These differ from "direct control" (like OpenMM) where we have an easy-to-use API to get frames on demand.

Indirect control isn't as elegant as direct control, but the first thing I hear from prospective users is that they'd like to be able to use their own favorite MD engine, and we're not going to write a direct control API for every MD engine out there.

However, I think a single indirect control API can make it easy to add new external engines. Here's the API I've implemented in this PR.

First, there are 4 required functions:

• read_frame_from_file(filename, frame_num): attempts to read frame number frame_num from filename, returns Snapshot if the frame exists, None if not, and (optionally) "partial" if it appears that the frame has been partially written.
• write_frame_to_file(filename, snapshot, mode="a"): write the snapshot to a file; mainly used to create input conditions for a trajectory
• set_filenames(number): sets the filename variables (input file, trajectory output file, anything else that changes with trajectory) for trajectory number : mainly differs because of different file extensions
• engine_command(): writes the command which would run the dynamics engine (as if doing normal MD with it)

Next, there are 2 functions which may occasionally need to be overridden:

• who_to_kill(): returns a psutil.Process object for the process to send the kill signal to (defaults to the process we launch, but in some circumstances you need to kill a child of that process, because the parent process fails to pass signals along to children)
• cleanup(): any other cleanup that needs to be done after terminating the external program (defaults to none)

There's also a class variable killsig which determines which signal to send to terminate the process. It defaults to signal.SIGTERM, but can be overridden. And, of course, other subclass-specific details can be passed as part of the __init__ function.

I may add more features (handling of stdout and stderr from the subprocess, for example) and I'm planning to add a nice trick that automatically optimizes the time spent waiting for a new frame to be written. But this is the basic idea, and I think it should make it really easy to add support for more engines.

@kyleabeauchamp : What happens if MDTraj tries to read a file that is still being written? In particular, I'm hoping it is possible to get the cases listed for read_frame_from_file: (a) here's the frame you requested; (b) no frame of that number exists; or (c) it looks like we're in the middle of writing that frame.

If that's not possible, it's also fine if case (c) returns the same response as case (b). If we can use MDTraj for the read and write files, it'll make it REALLY easy to add more engines.

I believe this will be dependent on the file type as well as the reading and writing mode.

For example, I know that pytables (our HDF5 backend) can sometimes choke when a file is being written and read at the same time.

If you have a clear need for simultaneous read / write, I think you might want to raise an issue on the MDTraj issue tracker asking for advice there. It's possible that some file formats might be feasible with only minor fixes.

Another possibility is to use a sqlite database, which is a pretty lightweight way to have concurrent read / write. Robert's Osprey code uses this for building many Markov state models in parallel and saving them in a database for evaluation (https://github.com/pandegroup/osprey/)

Thanks Kyle -- since it sounds like it'll take some more detailed consideration, I'll put an issue up on the MDTraj tracker later, but I'll hold off until I can make this a higher priority. The current status on this was just to make a proof-of-concept. This isn't part of our 1.0 roadmap, but it's something I want to complete this spring.

Since we're using an external program to generate the trajectory, we can't change the output there to sqlite. We really only need the last completed frame every time we poll the file, but the question is how to best obtain that. Anyway, I'll ask over on MDTraj when I know that I can devote more time to it!