[gmx-developers] g_decorr and Multi-I/O

[Mark Abraham]

Mark Abraham wrote:
> Hi,
> 
> I'm planning to implement Lyman & Zuckerman's method for determining a 
> trajectory "decorrelation time" (recently published in J. Phys. Chem. B 
> 2007, 111, 12876-12882). I thought I'd make an initial stab at the 
> Multi-I/O developer project 
> (http://wiki.gromacs.org/index.php/Category:Development) while I was at 
> it. This aims to port the kind of functionality present in trjcat and 
> eneconv, i.e. accepting multiple trajectory files as input.
> 
> As a model, so far I've been looking at trjcat. The first complication 
> here is that the demuxing functionality built into trjcat has nothing to 
> do with the "normal" function. The clue here is that after the normal 
> initial file processing, there's an "if(bDeMux)" in trjcat.c that 
> controls the rest of the execution. So, I think this means there should 
> be a trjdemux utility. :-)
> 
> Anyway, back on point, there are two ways you could do this kind of 
> Multi-I/O thing : either
> 
> * read all of the relevant frames of the trajectory into memory (caveat 
> -b, -e and -dt) and then process, or
> 
> * loop over files and frames in them, accounting for -b, -e and -dt on 
> the fly, and using a callback function on each frame to actually do the 
> required work.
> 
> (You could implement the former as a special case of the latter, of 
> course.)

Actually, I thought of a third way tonight which is better still. From 
your actual code, you call a function to initialise the state of the 
multi-I/O, and then call a function get_next_trxframe that keeps all of 
its own state information in an argument and returns the next appointed 
frame, whatever file it was from. Easy.

Mark

Mark