[gmx-developers] g_decorr and Multi-I/O
David van der Spoel
spoel at xray.bmc.uu.se
Thu Nov 15 14:34:44 CET 2007
Mark Abraham wrote:
> Mark Abraham wrote:
>> 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
> 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
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
More information about the gromacs.org_gmx-developers