Add support for trajectories of part of the system to new analysis framework
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.
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.
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
- Add basic tests for one positive and a few negative cases.
Part of #1861.
#2 Updated by Teemu Murtola over 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 over 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 over 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 over 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.