Refactor trajectoryanalysis module to allow handling of trajectory frame manipulation
The trajectoryanalysis module works currently with the assumption that all data sets are of a type such as
- index , value , deviation
This makes it more difficult to use the machinery for something like trajectory file manipulation or internal manipulation of coordinate frames.
A proposed change is to move the declaration of the per-frame data structures to the individual analysis modules, so that each module could declare different kinds of data handlers that are distinct from the currently implemented types in analysisdata.h.
One issue that Teemu has already raised is that this would remove the option to run the analysis in parallel, which should be avoided. I don't know if there would be a way around this by keeping the original structure and adding a different abstraction layer between the different kinds of data handled during the analysis.
Add gmx convert-trj
Adds a new module gmx convert-trj, aimed at providing the minimal
functionality to convert different GROMACS supported trajectory formats
into each other, as well as supporting selections to chose atoms for
writing to disk.
The tool is based on the OutputManager and OutputAdapter framework for
writing new trajectory files and for setting meta information in the
#2 Updated by Teemu Murtola almost 2 years ago
I don't understand what your problem is. Using any of analysisdata, or even the per-frame data objects, is completely opt-in in the framework. You can perfectly well put arbitrary objects in your analysis module, or in a custom per-frame data structure, and at most you will lose the ability to run that particular tool with the simple parallelism scheme that is in the background (but has never been implemented). None of this should require removing any existing code or functionality.
#3 Updated by Paul Bauer almost 2 years ago
ok, then I didn't understand the code good enough for this, sorry.
I'll remove the linked change then again and will upload a proposal for a change that will introduce coordinate data handling and internal storage to the general framework.
Thanks for your advice and for setting me right on this.