ParaView/Collaboration

ParaView in a collaborative context

Introduction

ParaView has undergone some major updates under the cover since 3.10. One of the reason for those changes was to support collaboration. Those changes were done in 3 steps:

• Change the client/server communication from a command base paradigm to a state base one. To achieved that all the Proxy layer has been cleaned up and now we rely on Protobuf messages to store and encode proxy state across processes. This work has been released with ParaView 3.12.
• The second step was to allow a pvserver to accept several clients and make sure the client get synchronized in someway so simulation analysis could be achieved across different sites at the same time.
• Finally, drop the client limitation by allowing a client to connect to several servers at the same time.

Those changes were not trivial to make and even if we tried to keep the API unchanged for backward compatibility we definitely break some stuff. We are doing our best to keep the documentation updated as well as the main ParaView code. For more details about the API changes and logic underneath, please read the Developer corner section.

But now, it is possible to connect several clients to a single pvserver and share the pipeline and visualization across different clients. Those clients can be either the regular ParaView Qt client or simply a pvpython batch or even a ParaViewWeb application. Moreover, a ParaView client can now handle several connected servers at the same time. Such configuration even works with collaborative server even if in such configuration it can be thought to understand what is going on and who is controlling the application. ;-)

New capabilities

Those major changes open new doors to the usage of ParaView and not only application wise but also framework wise. Nowadays, more projects are considering using ParaView as a library instead of VTK. The reason for such move reside in the benefit of the ParaView framework where scalability, distributed architecture became transparent. And now on top of that we provide collaboration as a built-in feature.

But what does collaboration brings to ParaView ?

• It allow several clients to connect to a same server and share the same visualization pipeline and views.
• A master/slave paradigm is used for controlling the pipeline parameters. The master can either give its right to someone else or either force everyone to follow him in its navigation in 2D and 3D views or any other slave user.
• The collaboration is not limited to the ParaView Qt client. Other clients such as pvpython or ParaViewWeb could benefit from it and be part of the collaboration.
• Every proxy state get automatically synchronized across clients.

One server / Multiple clients

As Collaboration implies more networking usage for synchronization purpose, this feature is not enable by default. Therefore, an optional argument has to be provided to the server at the start-up. Client wise, noting special is needed as this information transit automatically from the server to the client once this one connect to it.

Command line to start a Collaborative pvserver which will keep listening the network even after the first client connect to it.

> pvserver --multi-clients

Then any ParaView client can simply connect to that server like a regular one. The following video is showing some basic interaction and usage on how the collaboration capability can be used with ParaView.

http://vimeo.com/34480656

One client / Multiple servers

This feature was added recently to the ParaView framework in order to add more flexibility to proxy management. At first, this capability was just targeting the proxy layer when used inside external C++ and Python code and a subset of the ParaView Qt components. But thanks to the previous refactoring we managed to achieve a better integration of that capability by allowing ParaView itself to connect to several servers. Moreover, most of the Collaborative capability are still intact across multiple collaborative server connections.

In order to enable that feature, you need to tell the client that you allow it to have multiple server which was not allowed previously. To to so, you would have to start ParaView with the following command.

> paraview --multi-servers

Multiple clients / Multiple servers

This is the resulting of mixing both of the above feature by starting the server in collaboration mode and the client in multi-server mode.

> pvserver --multi-clients
> paraview --multi-servers

The following video illustrate how it works and what can be achieved.

http://vimeo.com/34484642

The Python client

Collaboration

pvpython is a client on its own and because of the way it is design the collaboration is not implicit, the user have to manually request the client to update itself in case of collaborative usage.

The following code snippet show the important set of commands.

 > ./pvpython
 > from paraview.simple import *
 > from paraview.collaboration import *
 > processServerEvents()

The processServerEvents() command needs to be called periodically so the current proxy state could be updated based on the other client changes.

Multi-servers

pvpython allow the user to connect to several server at the same time and switch from one to the over in a transparent manner.

The following sample script illustrate how that capability can be used.

> from paraview.simple import *
> from paraview import servermanager
>
> localConnection = servermanager.ActiveConnection
>
> localSphere = Sphere()
> localClip = Clip()
> Show()
> Render()
> ResetCamera()
>
> enableMultiServer()
>
> remoteConnection = Connect("localhost")
> remoteSphere = Sphere()
> remoteView = CreateRenderView()
> Show()
> Render()
>
> switchActiveConnection(localConnection, globals())
> switchActiveConnection(remoteConnection, globals())
> 
> Disconnect(globals())
> Disconnect(globals())
> Connect()

Developer corner

TBD

• Explain sessions
• SM/SI objects
• Undo/Redo use protobuf message to keep track of Proxy state
• ProxyManager vs SessionProxyManager