<p dir="ltr">Hi,</p>
<p dir="ltr">On Nov 13, 2014 9:51 AM, "Alexey Shvetsov" <<a href="mailto:alexxy@omrb.pnpi.spb.ru">alexxy@omrb.pnpi.spb.ru</a>> wrote:<br>
> Personaly i thougth about option 2 (store intermediate data). However in some cases it will lead to very large memory footprint.</p>
<p dir="ltr">Sure, but since you haven't told us anything about what you want to do, it's impossible to say whether that applies to your case. And there certainly are cases where this is possible.</p>
<p dir="ltr">> 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).</p>
<p dir="ltr">That is a particularly bad example, because<br>
1) it is possible to compute the average and covariance in a single pass, so my approach 1 results in much more effective analysis, and<br>
2) even if it weren't, there would be essentially no overhead to write two different tools, one to compute the average, and another one that takes the average structure as input and computes the covariance.</p>
<p dir="ltr">> Btw is it possible to call AnalyzeFrame recursively from C++?</p>
<p dir="ltr">That depends fully on what you put into that function... The framework itself surely doesn't call it recursively, but if you don't use any constructs that expects the guarantees that the framework provides and your recursion breaks, why not?</p>
<p dir="ltr">> Using python wrapper is a good idea, however it currenlty in early stage (e.g no selections).</p>
<p dir="ltr">If you followed my recommendation, you wouldn't need selection support to implement my suggestion 4 (as long as you wrote your core tool in C++, and only the glue with Python). But if you don't even want to explore this approach for the bindings, there's not much I can do...</p>
<p dir="ltr">Best regards,<br>
Teemu</p>