[gmx-developers] multiple xtc output files (optionally in chunks)

[Mark Abraham]

Bert de Groot wrote:
>>> Multiple xtc files for different groups could in be useful, but I have
>>> never
>>> had a need for this, nor did I get any requests.
> 
> It would save reading/processing of parts (e.g. solvent) in which one might not
> be interested but which you still want to have just in case. It would also allow
> writing subset (protein?) coordinates with a higher frequency than others.

The work-around when running batch-style is to save everything you want 
at the highest frequency, and set up trjconv runs between processing 
runs to form your subset trajectories at whatever frequency you want, 
dumping the excess data afterwards. These trjconv runs can also be done 
off-line, depending on your file system configuration and stuff. This is 
not as efficient as doing it all on-line (because you're doing I/O on 
everything you want to save more often than you need to) but doing it 
on-line also come with the cost of having to do lots of tests for group 
membership and the loss of processor pipelining efficiency there. I 
suspect the latter is much less expensive than the former.

>>> I think chopping up files is useless.
>>> The much easier solution here is to chop up your whole simulation in
>>> parts
>>> and use tpbconv to continue runs, just like when you would have a
>>> queing system
>>> (which you should install in Gottingen anyhow).
>>>
> 
> I don't agree. Why use a queueing system if one can do without? It only creates
> extra (CPU and I/O) overhead. It sounds a bit like using individual bottles of
> water instead of opening the tap if you want to take a bath. But obviously if
> we're the only ones that see it that way there's no need to change the code.

The overhead will surely be negligible, especially if you're really in 
the zone of one user running for days at a time. Call it a minute per 24 
hours? The gains would seem to be a backup system that works less 
painfully :-), training the people to work the way they'll have to work 
everywhere else on the planet, and having the ability to schedule and 
queue stuff when you want to.

>> I agree, but what we should implement, and what is also on the todo list
>> on the wiki, is to be able to analyze N trajectories as one, e.g.
>> g_hbond -f a.xtc b.xtc c.xtc and so on.
>>
>>
> 
> This is obviously a useful development in any case. But it's not a replacement
> for multiple output (in case one needs e.g. certain coordinates more frequently
> than others).

Mark