[gmx-developers] Rewind and reread trj from C++ api
teemu.murtola at gmail.com
Thu Nov 13 05:28:43 CET 2014
On Sat, Nov 8, 2014 at 2:07 PM, Alexey Shvetsov <alexxy at omrb.pnpi.spb.ru>
> How to deal with situations when it need in that case? As i understand i
> cannot have two AnalyseFrame functions in one tool
As you have not given any hint on what you are actually trying to do, I can
only give general advice. There are several alternatives below, and it
depends fully on your case on which of these may be appropriate and which
1. Reformulate your analysis such that you can do it in a single pass
over a trajectory.
2. Store necessary information from past frames such that you do not
need to rewind the trajectory; you just process again that stored
information. Depending on the nature of the information, you can perhaps
use AnalysisData object(s) for this, or some more specialized data
3. Write the tool such that the user can/must run it multiple times over
the same trajectory, where each run only does a single pass, and stores all
the necessary information to be passed to the other cases. Again, depending
on the nature of the analysis, the different passes may also be done with
different tools that perform more primitive operations than the full
analysis (which may also make the individual components more reusable).
4. If case 3 results in a need to pass complex intermediate state from
one tool to another, you can wrap this within a shell script or a Python
script. If you focus your Python binding efforts to support combining
existing tools instead of writing tools from scratch, it could be useful
for cases like this as well.
5. Write your tool without using the TrajectoryAnalysisCommandLineRunner
class, and instead write your own loop over the frames. Just use the parts
of the framework that make sense for your problem, but note that not
everything underneath has been wrapped in a similar level of API as what
the runner provides.
In general, the focus in the framework is to make the most common cases
easy. A single-pass trajectory reading is certainly sufficient for a large
class of tools, and rewinding the trajectory is also incompatible with the
possibility to use Unix pipes or shell redirections for some things
(although as it is now, there are other obstacles that prevent one from
using these for trajectories).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the gromacs.org_gmx-developers