This marks the beginning of series of blog posts that I intend to write (and can hopefully rope in others to write too) to give a new developer for ParaView, ParaView plugin, or a ParaView-based application  some overview on how things come together. To keep things manageable both for the reader and the writer, I intend to keep each post small and focused. This is surely an experiment and experiments are bound to go terribly wrong, so please feel free to give your feedback either in the comments section or on the mailing list so we can continue to revise and learn from our mistakes as (and if) we continue with this.

The ideal reader

Before chugging along, let’s identify the target reader:

1. You are well versed with using ParaView.
2. You are familiar with VTK. You need not know all the crazy details of the pipeline just yet, but knowing what VTK data model is, VTK algorithms are, how pipelines are put together is assumed. ParaView is VTK. For an uninitiated observer, ParaView is not much more than a UI for VTK (clearly that’s too simplistic a view, but we all start somewhere).
3. You are able to build ParaView from source.
4. You are familiar with navigating the code, potentially using the online Doxygen documentation but ideally just opening your favorite editor (which is highly unlikely to be anything other than VIM) and looking at the source code.

The objective here is not to document all the API but to give the reader some bearing as he or she dives into the code to hack it.

ParaView world view

If there is one thing that I always keep in mind when I am writing any code for ParaView, that would be the various modes in which ParaView can be used. Most users simply run ParaView using paraview executable. Seasoned users are aware that there are several other executables viz. pvserver, pvdataserver, pvrenderserver, pvpython, and pvbatch. paraview can be used by itself, or together with single pvserver, or a MPI group of several pvservers, or together with pvdataserver + pvrenderserver or MPI groups of the same. To make it possible to support all these configurations without losing our hair (well, most of it anyways), it helps to think of ParaView as made up of 3 logical components: DataServer, RenderServer, and Client. In any configuration, a process may act as one or more of these components.

• DataServer – This is component that does all the data processing. Thus all files that you open are opened here. All VTK readers, and filters that you apply to process your data are created here. All the data that is generated by various sources and filters lives here. DataServer is MPI-capable i.e. it can be running on a group of MPI ranks thus all the data that you’re reading and processing may be partitioned among multiple ranks.
• RenderServer – This does the rendering. Thinking in VTK terms, the mappers, actors, renderers, render windows etc. are here.
• Client – This is UI or scripting interface (Python) to control the data processing and rendering.

The data gets processed on the DataServer and gets converted into renderable artifacts. These are then shipped to the RenderServer where the rendering happens. And all this is orchestrated by the Client.

When you run paraview and are connected to the builtin server, all the 3 components are in the same process space and yet it’s a good habit to pretend they aren’t. The underpinnings may use shortcuts when doing data transfers, for example when shipping the renderable artifacts to the RenderServer from the DataServer, but unless you’re dealing explicitly with code that does that, you can just ignore that.

In the next post, I will introduce the ServerManager — the backbone of ParaView infrastructure. This is the thing that makes it possible for the Client to do all the orchestration of the analysis and visualization pipelines irrespective of whether the server components are local or remote.