[gmx-developers] Rewind and reread trj from C++ api

[Teemu Murtola]

Hi,

On Sat, Nov 8, 2014 at 2:07 PM, Alexey Shvetsov <alexxy at omrb.pnpi.spb.ru>
wrote:

> 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
may not:

   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
   structure.
   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).

Best regards,
Teemu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20141113/69fc2d74/attachment.html>