Project

General

Profile

Feature #1861

Add support for trajectories of part of the system to new analysis framework

Added by Berk Hess about 4 years ago. Updated over 3 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
analysis tools
Target version:
Difficulty:
uncategorized
Close

Description

Currently the new analysis framework can only read trajectory files of all atoms in the tpr. Convert could produce a tpr of a subgroup, but that is messy (#1667).
Allowing reading of trajectories of part of the system should not be much work, since that just requires one extra selection with the xtc group and an index translation.


Related issues

Related to GROMACS - Bug #1667: gmx convert-tpr writes wrong number of mol in output tprNew

Associated revisions

Revision 12c07b72 (diff)
Added by Teemu Murtola almost 4 years ago

Support arbitrary subset trajectories in poscalc.*

- Make low-level selection code work with trajectories that contain an
arbitrary subset of the topology atoms, instead of just the first N.
- Add an entry to t_trxframe to represent such trajectories.
- Add some basic tests. Negative cases crash with an assert, so not
tested (should get caught higher up).

This should cover all of selection evaluation, but various consistency
checks need to be adjusted as well (will be done in a child change).

Related to #1861.

Change-Id: I727c79a38e39fb9142976875ab3311e7b1172a55

Revision 4239f345 (diff)
Added by Teemu Murtola almost 4 years ago

Support frames with atom subsets in selections

- Instead of just computing the highest atom index required for
evaluating the selections, compute all the atom indices.
- Use these to check that the input frame actually contains the
necessary atoms.
- Add basic tests for one positive and a few negative cases.

Part of #1861.

Change-Id: If4c2d031f638f56d81ca4c7844dffa242f863af8

Revision 4ee73c88 (diff)
Added by Teemu Murtola almost 4 years ago

Support trajectory analysis with any atom subset

Make tools written for the new C++ analysis framework support analyzing
trajectories that contain an arbitrary subset of atoms.

Part of #1861.

Change-Id: I4a658e953f6f4e3d2ec1151c9c4d405c2e888780

History

#1 Updated by Berk Hess about 4 years ago

  • Related to Bug #1667: gmx convert-tpr writes wrong number of mol in output tpr added

#2 Updated by Teemu Murtola about 4 years ago

I think it also works already now if the trajectory has the first N atoms from the topology (but not all), but this has limited usability.

Yes, in principle this is straightforward, and consists of three/four things:
  • command-line/interactive support for selecting the group,
  • deciding on how to propagate this information around in the code (should it, e.g., go into t_trxframe, or somewhere else?),
  • doing the mapping everywhere that accesses the trajectory,
  • (providing nice error messages in case the user tries to operate on atoms that are not in the trajectory).

But the selection code passes t_trxframe around a lot, so it will be some work to fix all the uses.

#3 Updated by Berk Hess about 4 years ago

With the first N atom the most common case all already covered.

I would suggest to store the index in t_trxframe. I assume/hope that with tng files the index can be stored in the tng file, in which case it can come into t_trxframe without the user selecting anything.

#4 Updated by Teemu Murtola about 4 years ago

How about the lookup from topology atom indices to trajectory coordinate indices? Should we move gmx_ga2la_t out of domdec and rename it to more general, or just have some simpler lookup based on standard data structures (that probably either has O(N) space complexity in the number of topology atoms, or O(MlogM) lookup complexity, or a lot of memory allocation overhead). Any opinions?

#5 Updated by Teemu Murtola about 4 years ago

I took a look at the selection code, and unless I missed something, the only operation really needed is that given a t_trxframe and an array that contains topology atom indices, we need to get an array of trajectory atom indices. But this needs to be done for multiple arrays for a single frame, and the array contents may vary between frames.

With some extra effort and code complexity, it's possible to precompute the mapping just once if we assume that the trajectory contains the same atoms in each frame. But I'm not sure whether that additional effort makes sense, because it could be nice to be able to actually write a dynamic selection to a trajectory and then use that further (at least, many people have asked about this on the mailing list in the past). And without this extra optimization, this part of the selection code is ready to handle also such input.

#6 Updated by Gerrit Code Review Bot about 4 years ago

Gerrit received a related patchset '1' for Issue #1861.
Uploader: Teemu Murtola ()
Change-Id: I727c79a38e39fb9142976875ab3311e7b1172a55
Gerrit URL: https://gerrit.gromacs.org/5394

#7 Updated by Gerrit Code Review Bot about 4 years ago

Gerrit received a related patchset '1' for Issue #1861.
Uploader: Teemu Murtola ()
Change-Id: If4c2d031f638f56d81ca4c7844dffa242f863af8
Gerrit URL: https://gerrit.gromacs.org/5402

#8 Updated by Gerrit Code Review Bot about 4 years ago

Gerrit received a related patchset '1' for Issue #1861.
Uploader: Teemu Murtola ()
Change-Id: I4a658e953f6f4e3d2ec1151c9c4d405c2e888780
Gerrit URL: https://gerrit.gromacs.org/5403

#9 Updated by Teemu Murtola about 4 years ago

  • Status changed from New to In Progress
  • Assignee set to Teemu Murtola
  • Target version set to 2016

#10 Updated by Teemu Murtola about 4 years ago

  • Tracker changed from Task to Feature

#11 Updated by Teemu Murtola almost 4 years ago

  • Status changed from In Progress to Fix uploaded

#12 Updated by Teemu Murtola almost 4 years ago

  • Status changed from Fix uploaded to Resolved

Basic support should now be there.

#13 Updated by Teemu Murtola over 3 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF