<div dir="ltr">Hi,<br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Nov 8, 2014 at 2:07 PM, Alexey Shvetsov <span dir="ltr">&lt;<a href="mailto:alexxy@omrb.pnpi.spb.ru" target="_blank">alexxy@omrb.pnpi.spb.ru</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">How to deal with situations when it need in that case? As i understand i cannot have two AnalyseFrame functions in one tool</blockquote><div><br></div><div>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:</div><div><ol><li>Reformulate your analysis such that you can do it in a single pass over a trajectory.</li><li>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.<br></li><li>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).</li><li>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.</li><li>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.</li></ol><div>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).</div></div><div><br></div><div>Best regards,</div><div>Teemu</div></div></div></div>