Port existing trajectory analysis tools to use the new framework - Redmine #665
Archive from user: Teemu Murtola
The framework starts to be ready for some serious use, although there still are some issues (will add those as issues blocking this one). However, if the limitations are taken into account, it should already be possible to implement quite a wide range of analysis tools. This is also the best way to find any deficiencies in the framework, because all possible use cases are quite difficult to predict beforehand. New data modules under src/gromacs/analysisdata/modules/ should be implemented (or existing ones extended) when needed.
There is a lot of work here, and I don’t have the resources to do this, and in particular not to test all the tools. One possible approach is to port tools on a one-by-one basis when someone needs the new functionality. I can provide advice and improve the Doxygen documentation of the framework if/when the need arises.
(from redmine: issue id 665, created on 2011-01-14 by gmxdefault)
- Relations:
- relates #642 (closed)
- relates #666 (closed)
- relates #1323 (closed)
- blocks #708 (closed)
- blocks #827 (closed)
- child #909 (closed)
- child #920 (closed)
- Changesets:
- Revision 5bda86f8 by Teemu Murtola on 2011-02-17T16:52:03Z:
Fully ported g_select to the new framework.
All old functionality should now be available, and the implementation
should fully conform to the guidelines on how to use the framework.
As an additional plus, the -on option no longer incurs any memory
overhead. The only issue is that the single-precision version does not
work perfectly for systems with more than 2^24 atoms, since the atom
indices are passed around as floating point numbers. This would require
a more general solution in the analysisdata module.
Removed the old implementation, which was no longer included in the
build.
IssueID #665
- Revision ccff2c0b by Teemu Murtola on 2011-02-18T19:28:42Z:
Added a new angle calculation tool.
Invokes as 'g_ana angle', but actually the functionality is somewhere in
between g_angle and g_sgangle. This tool is the first tool that really
uses the full power of the selection engine. There are still a few
issues that need updates in the analysis framework to implement
correctly (mostly related to usability and checking user input).
IssueID #665
- Revision 09b3ae8c by Teemu Murtola on 2013-08-16T19:03:17Z:
Replacement for g_bond and g_dist.
Added a proper implementation for the 'distance' tool.
It should now do most of what g_bond or g_dist can do.
The help text related to the distance histogramming is somewhat
different from g_bond, but the behavior is more or less the same; now
the help text just describes how it is actually implemented.
The main things missing are proper legends in the output files, some
statistics output (g_bond), and g_dist -dist and g_dist -lt.
g_dist -dist can already be done with g_select, and g_dist -lt also
makes most sense to implement separately into g_select instead.
Part of #665.
Change-Id: I293cf8f0d30480e1873d5dcdef414f0089f177a6
- Revision a88fc8c7 by Teemu Murtola on 2013-08-21T06:22:57Z:
Lifetime statistics into gmx-select.
This provides a lot more flexible alternative to g_dist -lt.
Added an analysisdata module that computes lifetime statistics and test
for it. Currently tuned for this one application, but should be
possible to make more flexible if required. Using this module, the
implementation in gmx-select is straightforward.
Part of #665.
Change-Id: I8bff89599c9d8a820c761b426c01ceafa9afcc5a
- Revision 914cedcf by Teemu Murtola on 2013-08-21T12:15:39Z:
Statistics for gmx-distance.
Add support for calculating statistics more or less like g_bond has into
the new C++ gmx-distance tool. The output format may not be as nice,
but one can at least get the same numbers out.
Extended the averaging analysisdata modules to handle multiple data sets
to support this, which required changing the data structure slightly
(this is the source of most modifications to existing data in XML files;
new tests/new output data of course adds additional entries).
Supporting changes in the plotting to handle missing values and errors,
and in test code to handle missing data points.
Part of #665.
Change-Id: If5f0b54d6d3eec0145625de9ab745e6ba9dc468a
- Revision 64a411f7 by Teemu Murtola on 2013-08-30T12:43:03Z:
Clean-up and improvements in C++ tools.
- Make gmx-select accept multiple selections for all output options.
- Make gmx-gangle and gmx-distance accept dynamic selections.
- Remove -dump option from gmx-select and remove commented code related
to the same in the other tools.
Part of #665.
Change-Id: I5e3c4caf2928a95c2620d969b4f447272ad9b051
- Revision 5b99d6a2 by Teemu Murtola on 2014-02-28T01:26:02Z:
Convert gmx-sas to the C++ framework
An example of converting a non-trivial analysis tool to the new
framework. Most functionality is intact, but the command-line interface
is changed a bit. Changes in behavior:
- Writing a position restraint file is not implemented. Would not be
very difficult to add.
- Solvation free energy estimates are written into a separate file
instead of the main output file, and only if requested with an -odg
option.
- The calculation group is specified as a selection with -surface.
Can be a dynamic selection. The total area of this group is always
written out.
- There can be 0..* extra output groups, specified as selections with
-output. All can be dynamic, and must always be a subset of the
calculation group.
- There is no longer a separate concept of hydrophilic and hydrophobic
surface area. The user can trivially calculate such things by
providing two different output groups. The old hydrophobicity
definition is easily expressed as "... and charge {-0.2 to 0.2}".
- tpr file is no longer required for most of the output.
- Output precision is different from the old tool. The current
precision (fixed to three decimal places) should be sufficient for
most uses, but it could be considered to use %g for formatting like
the old tool if really necessary.
Future TODOs:
- Consider if the legends on the plots could be improved.
- Add unit tests for the actual surface area calculation routine.
Part of #665.
Change-Id: Iee60c13b927b3b63b6e218164cd961971f2f3fce