Unfortunately there's no comprehensive "developing paraview" guide. It can be used as a framework for other applications and has been designed to do that but we haven't had any funding to work on a comprehensive guide for that.
I haven't looked at the Live parts in depth in a while so my memory is probably fuzzy on that and it would take a good bit of time for me to familiarize myself with that part of the code. By murky I mean that things get a bit confusing when you're looking at the classes for both the client, server and in situ side. Kitware does offer support services if this is important to get working for you. Best, Andy On Fri, Oct 27, 2017 at 12:51 PM, Kolja Petersen <petersenko...@gmail.com> wrote: > More questions below... > > On Thu, Oct 26, 2017 at 5:54 PM, Andy Bauer <andy.ba...@kitware.com> > wrote: > >> I inlined some answers below... >> >> On Wed, Oct 25, 2017 at 1:42 PM, Kolja Petersen <petersenko...@gmail.com> >> wrote: >> >>> Thank you, Andy, >>> 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. >>> >>> 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 >>> pqLiveInsituVisualizationManager::pqLiveInsituVisualizationManager(int >>> connection_port, pqServer* server), which creates a >>> vtkSMLiveInsituLinkProxy, not a vtkLiveInsituLink as coprocessing.py. >>> >> >> Yes, coprocessing.py should only be used on the simulation side. >> > > 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? > > >> >>> >>> 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? >>> >>> >> 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. >> > > 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? > > 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. > Anyway, thanks for your explanations, although I couldn't make much > progress. > Kolja >
_______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Search the list archives at: http://markmail.org/search/?q=ParaView Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/paraview
