Simple way to get last frame from trajectory - Redmine #2873

added Bug analysis tools + 1 deleted label

Archive from user: Erik Lindahl

Since the documentation for the dump option is “Dump frame nearest specified time (ps)”, this sounds like it’s a bug that it does not do that :-)

Instead of adding another option, IMHO we should just make the present one behave according to the specifications.

(from redmine: written on 2019-02-28 by gmxdefault)

The specifications are imprecise. I think I implemented this and I think it gives the nearest frame within a the time step between frames.
We can extend it to work exactly to the current specification, but it seems to me that this is not a very intuitive way to get the last frame.

(from redmine: written on 2019-02-28 by berkhess)

For 2019, I suggest we amend the documentation to reflect the behaviour, since making changes to trjconv is undesirable.

For 2020, I suggest we implement something like my earlier suggestion of gmx dump -f -lastframe

(from redmine: written on 2019-02-28 by mark.j.abraham)

changed milestone to %2022.beta2

We might be able to add this to 2022, because if we don't it seems we'll just keep bumping it forever...

This is not quite straightforward because one also has to have a source of atom names, etc. Also in the absence of an index file, the number of atoms in the trajectory file has to match that of the source of atom names, which is generally another file.

Here's a summary of the information we might need from the user's input files, where trx and sto are any of the supported range for efTRX and efSTO respectively:

trx input format	output format	can be supported
xtc	sto	yes if tpr provided
trr	sto	yes if tpr provided
gro	sto	yes
g96	sto	yes
pdb	sto	yes
tng (any)	sto	yes if tpr provided
tng including top	sto	yes
tng without top	sto	no

So full support would look like all of the following working:

gmx dump -f any.trx -s topol.tpr -lastframe any.sto
gmx dump -f traj_with_top.tng -lastframe any.sto
gmx dump -f traj.gro -lastframe any.sto
gmx dump -f traj.g96 -lastframe any.sto
gmx dump -f traj.pdb -lastframe any.sto

where the default filename for -lastframe is conf.gro.

I'll have a go at the first 1 (or 2) using a dumb implementation that reads the whole trajectory in, and then reassess if the last few are worth it.

In general, one needs also an index file, because the trajectory file need not have the whole system in it.

changed the description

I don't think this is simple or useful enough to implement. A user can run gmx check and then gmx trjconv -dump to get the contents of the last frame. They'll generally have to give a source of atom names and perhaps index groups to gmx trjconv to get that done, which is complexity that is not immediately obvious. As above, there are several sub-cases and they all work differently, so cobbling them onto gmx dump would be a change of focus for that tool. Even gmx lastframe would not be a simple thing.

closed

Aren't you overinterpreting the scope?

Obviously, we can't magically convert from data formats without e.g. atom names to one with atom names (or indices), but I think the actual bug here is that gmx trjconv simply doesn't follow its specifications - it's not dumping the contents closest to the specified time, but it dumps contents of the first frame it finds within half the time of the specified time (assuming the trajectory is equally spaced), and if no such frame is found it doesn't dump anything.

If that hasn't changed, it sounds like a very direct bug to me, and one that should be quite easy to fix; we just have to maintain the last frame before checking the next one.

This won't even require any new options - it will just make the tool adhere to the specification of what we claim it is doing.

Indeed. I'll reconsider.

I will be over-busy until a grant deadline 1700 CET today, but can help after that - since this is old (ugly) code I'm probably at least co-guilty of introducing...

There were several complications in the implementation, including

we did the all the writing in the loop because that's the main use case for trjconv
that if we need to dump the last frame, we didn't find out that it's the last frame until we are ready to exit the loop over frames, after we decided not to print this frame
in general, if we need to print the previous frame because it was the one closest to the dump time, it was already gone.

But if we extract the writing function (and its 60+ arguments) so that we can call it normally during the loop and perhaps after the loop when we are using trjconv -dump then we can have a sound implementation of -dump. Alternatively, we can attempt to read the next frame early, so that we know whether the frame is the last frame before we decide about writing it.

@erik.lindahl You have some MRs to chew upon ;-)

reopened

mentioned in commit c1213118

mentioned in merge request !2184 (merged)

mentioned in merge request !2185 (merged)

assigned to @mark.j.abraham

mentioned in commit 06cf3eba

closed with merge request !2185 (merged)

mentioned in commit 69534db2

Simple way to get last frame from trajectory - Redmine #2873

Designs

Child items ...

Activity