Project

General

Profile

Feature #1221

Updated by Teemu Murtola about 7 years ago

Currently, in addition to selecting individual atoms, the selection engine allows one to specify, e.g., centers-of-mass centres-of-mass of (parts of) residues using syntax like:
<pre>
res_com of resname RA RB
</pre>
The analysis tools then get a list of positions (one coordinate for each residue), each of which can consist of multiple atoms. It is also possible to use the same position keywords to influence how atoms are selected based on coordinates:
<pre>
res_com within 1 of resname RA RB
</pre>
This selects all atoms that belong to residues whose center-of-mass is within the given distance.

These allow
allows a lot of things, but for generic use (in particular with some coarse-graining approaches) it may be too restrictive/cumbersome to only be able to do the splitting based on residue or molecule boundaries. It would be nice to be able to specify a fully generic mapping of this sort, and have the selection engine evaluate it.

One essential part of implementing this is first specifying what "fully generic mapping" really means, and what needs to be supported. But after there is some clarity for this, the implementation should amount to:
# Adding unit tests for the existing functionality in selection/poscalc.*.
# Adding support for out-of-order mapping in the functions from selection/indexutil.* that operate on gmx_ana_indexmap_t structures (what exactly needs to be supported depends on the specification) and adding similar support in selection/poscalc.*. The main limitation to lift is that currently, the mapping is specified as a t_blocka with a limitation that the list of atoms that participate in the mapping must be ascending (i.e., if the last atom that participates in position N is M, then the first atom that can participate in position N+1 is M+1).
# Adding support for parsing a mapping specification and converting that into data that can be used by selection/poscalc.*. One option would be to use a set of selections for this purpose.
# Adding support for custom keywords for specifying the position mapping (i.e., allow one to replace @res_com@ in the above examples example with the specified custom mapping) and initializing the position calculation for the selection appropriately in this case.
# Add sorting of output atoms for selection keywords that select atoms based on positions (i.e., construct the output atom list based on a set of positions).

Back