[Paraview] LiveInsituLink proxy in pvpython client

[Andy Bauer]

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 <petersenkolja at gmail.com>
wrote:

> More questions below...
>
> On Thu, Oct 26, 2017 at 5:54 PM, Andy Bauer <andy.bauer at kitware.com>
> wrote:
>
>> I inlined some answers below...
>>
>> On Wed, Oct 25, 2017 at 1:42 PM, Kolja Petersen <petersenkolja at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview/attachments/20171027/3fcdd95b/attachment.html>