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

[Alexey Shvetsov]

Hi Teemu,

Personaly i thougth about option 2 (store intermediate data). However in 
some cases it will lead to very large memory footprint.

Example when you need to rewind and reread trajectory already present in 
gromacs tools (e.g. g_covar it computes average structure and after that 
computes displacements over average possitions).

Btw is it possible to call AnalyzeFrame recursively from C++?

Using python wrapper is a good idea, however it currenlty in early stage 
(e.g no selections).


Teemu Murtola писал 13-11-2014 07:28:
> 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:
> 
> 	* Reformulate your analysis such that you can do it in a single pass
> over a trajectory.
> 
> 	* 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.
> 	* 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).
> 	* 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.
> 	* 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

-- 
Best Regards,
Alexey 'Alexxy' Shvetsov, PhD
Department of Molecular and Radiation Biophysics
FSBI Petersburg Nuclear Physics Institute, NRC Kurchatov Institute,
Leningrad region, Gatchina, Russia
mailto:alexxyum at gmail.com
mailto:alexxy at omrb.pnpi.spb.ru