<div dir="ltr"><div class="gmail_extra">More questions below...</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 26, 2017 at 5:54 PM, Andy Bauer <span dir="ltr"><<a href="mailto:andy.bauer@kitware.com" target="_blank">andy.bauer@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I inlined some answers below...<div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Wed, Oct 25, 2017 at 1:42 PM, Kolja Petersen <span dir="ltr"><<a href="mailto:petersenkolja@gmail.com" target="_blank">petersenkolja@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Thank you, Andy,</div><div>unfortunately your answer has shown me how little I understand about Catalyst. But maybe it leads in the right direction after some work from my side.</div><div><br></div><div>Just to make sure that we are talking about the same thing: My pvpython client is supposed to automate some of the visualization functionality of the paraview GUI. The coprocessing.py is in charge of the other side of the link, namely to provide data to the visualization side, if I understand correctly? I rather followed what happens in the constructor pqLiveInsituVisualizationManag<wbr>er::pqLiveInsituVisualizationM<wbr>anager(int connection_port, pqServer* server), which creates a vtkSMLiveInsituLinkProxy, not a vtkLiveInsituLink as coprocessing.py.</div></div></blockquote><div><br></div></span><div>Yes, coprocessing.py should only be used on the simulation side.</div></div></div></div></blockquote><div><br></div><div>So, did you suggest, coprocessing.py could also help to develop the visualization side? If yes, how? Or was my first email too unclear, so that my intention was not obvious? </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Now I saw that the vtkLiveInsituLink class can have ProcessType LIVE (for the visualization side? as server side object of the proxy created by paraview?) or INSITU (for the simulation side?). So apparently the same class can take both roles? If yes, that'd clarify some of my confusion. But still I don't see how coprocessing.py helps me to implement a python visualization client?</div><div><br></div></div></blockquote><div><br></div></span><div>Yes, the same class does work in both roles with the LIVE ProcessType being the visualization side and the INSITU being the simulation side. Things get a little murkier when there is a separate pvserver from the client that connects to the simulation.</div></div></div></div></blockquote><div><br></div><div>What do you mean by "murkier"? Paraview also uses a proxy (to a vtkLiveInsituLink instance either on a pvserver or on the builtin server), not  the class itself. Do you have an easier solution (C++ or python) by using vtkInsituLink directly?</div><div><br></div><div>Are there any design documents from Kitware that show the timings and message exchange between Catalyst, pvserver and Paraview (or other clients)? I don't know Kitware's publishing policies. My impression was always that you are not just developing the Paraview application but also an open source visualization programming framework. Maybe I'm wrong, but I am missing some kind of "Paraview Programming Guide" that goes beyond a User's Guide, to enable others understand the concepts behind Paraview and contribute at a deeper level than just adding filters and data processing algorithms.</div><div>Anyway, thanks for your explanations, although I couldn't make much progress.</div><div>Kolja</div></div></div></div>