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

[David van der Spoel]

Mark Abraham wrote:
> 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.
That is more the traditional gromacs style of doing everything under 
water. However we are trying to move away from having global static 
variables, and hence it would be better to make a combination of your 
second and third proposals.

Instead of using an integer designator for the file we could use a 
pointer to an abstract structure which can not be dereferenced in the 
calling functions because they don't have the type definition. Then all 
the dirty work still happens under the surface, and there is a minimal 
change to the API, however large enough such that the compiler will tell 
you.

About trjdemux, yes that could be an idea, however, it would also be 
good to consolidate some of the tools, such that one does not have to 
remember so many commands.


-- 
David van der Spoel, Ph.D.
Molec. Biophys. group, Dept. of Cell & Molec. Biol., Uppsala University.
Box 596, 75124 Uppsala, Sweden. Phone:	+46184714205. Fax: +4618511755.
spoel at xray.bmc.uu.se	spoel at gromacs.org   http://folding.bmc.uu.se