Questions about Paraview/Catalyst software architecture


I am writing a custom application based on Paraview, and I really want to understand/I am curious about how some aspects are managed.

If you can give me answers/informations about one or many of the questions listed below that would help me to visualize how things work within Paraview and help me extend my application.

  • Google’s Protocol buffer is used for what ? (used in paraview_protobuf::Message, vtkSMSession, vtkClientServerStream) what’s a stream can represent ?
  • What’s the format of the data exchanged between Catalyst and Paraview through the TCP/IP link ? XML ? binary ? How it is parsed (serialized / unserialized)
  • what vtkPVPostFilter really does ?
  • Can I manage filters/other objects which are executing in the catalyst pipeline from Paraview ?
  • What’s the difference between a vtkSMProxy (Server Manager) and a vtkSIProxy (Server Implementation) Difference between SM/SI objects.
  • Why an pqLiveInsituVisualizationManager::addExtract must be executed to add a new view.
  • Difference between ProxyManager and SessionProxyManager
  • The utility of vtkPVTrivialProducer.
  • What TCP events contain (pqServer, vtkTCPNetworkAccessManager and vtkMultiProcessController) and how data is updated ?

Any other informations about the architecture are highly appreciated. I spent a lot of time reading the code but I didn’t learn so much, it’s very hard to see the big picture and understand the tools used to carry data or parse requests by reading the code.

Thank you.

1 Like

Hi I’m just going to fill the blank on the part that I know on top of my head:

  1. protobuf: It is used as format for sharing state across a distributed setup between proxy. The SMSession is responsible for dispatching messages to the pieces that need it when local change are happening on any SMProxy to their distributed SIProxy part.

  2. PV/Catalyst format exchange: Skip

  3. vtkPVPostFilter: Skip

  4. SM/SI: SM is the client side proxy part. The SI object are the actual object that hold the VTK instance that does the actual work which could also be local but most likely remote or both local and remote. The SMSession is responsible to forward any change on an SM to all its SI using protobuf as exchange format.

  5. pqLiveInsituVisualizationManager: Skip

  6. ProxyManager and SessionProxyManager: ParaView was initially design as a single server (which could be MPI distributed) but we started to support collaboration and multiple servers with different and independent data. At that point we introduced the Session part which correspond to a connection with a given server. So in general the ProxyManager only hold one SessionProxyManager but sometime with a multi-server setup, the ProxyManager will keep track of several SessionProxyManager.

  7. vtkPVTrivialProducer: The role of trivial producer is to bridge a dataset into an vtkFilter that is part of a pipeline. The TrivialProducer aims to act as a filter so it could behave like the rest of the code. In in-situ and so on, the code on each MPI process will have just a dataset. So with the TrivialProducer we can attach those data piece so they can compose the full distributed dataset.

  8. TCP events: Skip

I hope that will help you get a better picture of what is going on…



Hello Sebastien,

Thank you very much for the share !