ParaView/Python Scripting

From KitwarePublic
< ParaView
Revision as of 14:13, 11 September 2008 by Berk (talk | contribs)
Jump to navigationJump to search

ParaView and Python

ParaView offers rich scripting support through Python. This support is available as part of the ParaView client (paraview), an MPI-enabled batch application (pvbatch), the ParaView python client (pvpython) or any other Python-enabled application. Using Python, users and developers can gain access to the ParaView engine called Server Manager.

Quick Start - a Tutorial

Getting Started

To start interacting with the Server Manager, you have to load the servermanager module. This module can be loaded from any python interpreter as long as the necessary files are in PYTHONPATH. These files are the shared libraries located in the paraview binary directory and python modules in the paraview directory: paraview/, paraview/ etc. You can also use either pvpython (for stand-alone or client/server execution), pvbatch (for non-interactive, distributed batch processing) or the python shell invoked from Tools -> Python Shell using the ParaView client to execute Python scripts. You do not have to set PYTHONPATH when using these. In this tutorial, I will be using the python integrated development environment IDLE. My PYTHONPATH is set to the following.


This is on my Mac and using the build tree. In IDLE, let’s start by loading the servermanager module.

>>> from paraview import servermanager

Note: Importing the paraview module directly is deprecated although still possible for backwards compatibility. This document refers to the servermanager module alone. Next, we need to connect to a server if we are not already connected.

>>> if not servermanager.ActiveConnection:
...	connection = servermanager.Connect()

Connection (builtin:5)

In this example, we connected to the built-in server. When using pvbatch, this is the only connection mode supported, even when pvbatch is running as an MPI task. When running pvpython or loading servermanager from an external python interpreter, we can also connect to a remote server as shown in the following example

>>> connection = servermanager.Connect('localhost')
Connection (localhost:11111)

This assumes that you already started the server (pvserver) on the local machine. Note: Connect() returns a connection object on success and returns None on failure. You might want to check the return value to make sure connection succeeded.

>>> connection = servermanager.Connect('localhost')
>>> if not connection:
...   raise exceptions.RuntimeError, Connection to localhost failed.

Note: When importing the servermanager module from the application’s python shell, Connect() should not be called as a connection already exists.

Creating a Pipeline

When first loaded, the servermanager module creates several sub-modules that can be used to create a visualization. The most important ones are listed below.

  • sources
  • filters
  • rendering

You can get a list of classes these modules contain by using dir() as shown in the following example.

>>> dir(servermanager.sources)
['AVSucdReader', 'ArrowSource', 'Axes', 'CSVReader', 'ConeSource', 'CubeSource', 'CylinderSource', 
'DEMReader', 'ExodusIIReader', 'ExodusReader', 'FLUENTReader', 'Facet Reader', 'GlyphSource2D', 
'HierarchicalFractal', 'ImageMandelbrotSource', 'ImageReader', ...]

Let’s start by creating a ConeSource object:

>>> coneSource = servermanager.sources.ConeSource()

The object assigned to coneSource is a proxy for the actual vtkConeSource. This proxy provides a set of properties and methods to control the behavior of the underlying VTK object(s). These objects may be in the same process (built-in server) or on one or more server processes (distributed remote server). The proxy will handle communication with the VTK objects in a transparent way. You can get some documentation about the proxy using help().

>>> help(coneSource)
Help on ConeSource in module paraview.servermanager object:

class ConeSource(Proxy)
 |  The Cone source can be used to add a polygonal cone to the 3D scene. The output of the Cone source is
 polygonal data.
 |  Method resolution order:
 |      ConeSource
 |      Proxy
 |      __builtin__.object
 |  Methods defined here:
 |  Initialize = aInitialize(self, connection=None)
 |  ----------------------------------------------------------------------
 |  Data descriptors defined here:
 |  Capping
 |      If this property is set to 1, the base of the cone will be capped with a filled polygon. 
Otherwise, the base of the cone will be open.
 |  Center
 |      This property specifies the center of the cone.

This gives you a full list of properties. Let’s check what the resolution property is set to.

>>> coneSource.Resolution
Property name= Resolution value = 6

You can increase the resolution as shown below.

>>> coneSource.Resolution = 32

Alternatively, we could have specified a value for resolution when creating the proxy.

>>> coneSource = servermanager.sources.ConeSource(Resolution=32)

You can assign values to any number of properties during construction using keyword arguments. Let’s also change the center.

>>> coneSource.Center
Property name= Center value = [0.0, 0.0, 0.0]
>>> coneSource.Center[1] = 1

Vector properties such as this one support setting and getting of individual elements as well as slices (ranges of elements).

>>> coneSource.Center[0:3] = [1, 2, 3]
>>> coneSource.Center
Property name= Center value = [1.0, 2.0, 3.0]

Next, let’s apply a shrink filter to the cone:

>>> shrinkFilter = servermanager.filters.ShrinkFilter(Input=coneSource)
>>> shrinkFilter.Input
Property name= Input value = <paraview.servermanager.ConeSource object at 0x2d00dd90>:0

At this point, if you are interested in getting some information about the output of the shrink filter, you can force it to update (which will also cause the execution of the cone source. For details about VTK pipeline model, see one of the VTK books.

>>> shrinkFilter.UpdatePipeline()
>>> shrinkFilter.GetDataInformation().GetNumberOfCells()
>>> shrinkFilter.GetDataInformation().GetNumberOfPoints()

We will cover the DataInformation class in more detail later.


Now that we created a small pipeline, let’s render the result. You will need two objects to render the output of an algorithm in a scene: a representation and a view. A representation is responsible for taking a data object and rendering it in a view. A view is responsible for managing a render context and a collection of representations.

>>> view = servermanager.CreateRenderView()
>>> rep = servermanager.CreateRepresentation(shrinkFilter, view)
>>> view.StillRender()

Oops, nothing is visible. We need to reposition the camera to contain the entire scene.

>>> view.ResetCamera()
>>> view.StillRender()

Et voila:

Servermanager snapshot.png

CreateRenderView() and CreateRepresentation() are special methods in the servermanager module to facilitate the creation of representations and views. CreateRepresentation() automatically adds the new representation to the view.

>>> view.Representations
Property name= Representations value = [<paraview.servermanager.UnstructuredGridRepresentation object at 0x2d0170f0>]

This was a quick introduction to the servermanager module. In the following sections, we will discuss the servermanager in more detail and introduce more advanced concepts.

paraview.servermanager Module

The servermanager module is a ParaView component written using Python on top of the VTK Server Manager C++ library. Its purpose is to make it easier to create ParaView data analysis and visualization pipelines using Python. The servermanager module can be loaded from Python interpreters running in several applications.

  • pvpython: The pvpython application, distributed with the ParaView application suite, is a Python client to the ParaView servers. It supports interactive execution as well as batch execution.
  • pvbatch: The pvbatch application, also distributed with the ParaView application suite, is a Python application designed to run batch scripts on distributed servers. When ParaView is compiled with MPI,
  • pvbatch can be launched as an MPI program. In this mode, the first node will load a Python script specified as a command-line argument and execute it using a special built-in connection on all nodes. This application does not support interactive execution.
  • paraview: Python scripts can be run from the paraview client using the Python shell that is invoked from Tools -> Python Shell. The Python shell supports interactive mode as well as loading of scripts from file.
  • External Python interpreter: Any Python-capable application can load the paraview.servermanager module if the right environment is configured. For this to work, you either have to install the paraview Python modules (including the right shared libraries) somewhere in sys.path or you have to set PYTHONPATH to point to the right locations.


The paraview.servermanager module contains several Python classes designed to be Python-friendly as well as all classes wrapped from the C++ Server Manager library. The most important classes are as follows.

  • Proxy
  • ProxyManager
  • Property and sub-classes

We will cover these classes in detail in following sections. When first loaded, the servermanager module creates several sub-modules. The most important ones are as follows.

  • sources
  • filters
  • rendering

These modules are automatically populated (at load time) with various Proxy sub-classes as defined in the Server Manager configuration files (ParaView3/Servers/ServerManager/Resources/*.xml). This allows direct instantiation of actual Proxy sub-classes (for example, SphereSource) instead of having to use vtkSMProxyManager::CreateProxy(). Furthermore, the documentation for each class can be obtained using help().

Connecting to a Server

Unless you are using the Python shell that is in the paraview application, the first step to any Server Manager Python script is connecting to a server. Even when running in stand-alone mode, you have to connect to a built-in server. To connect to a server, use servermanager.Connect(). This method takes 4 arguments, all of which have default values.

def Connect(ds_host=None, ds_port=11111, rs_host=None, rs_port=11111)

When connecting to the built-in server and running pvbatch, do not specify any of these arguments. The default values work well.

When connecting to a hybrid server (pvserver), specify only the first 2 arguments. These are the server name (or IP address) and port number.

When connecting to a data-server/render-server pair, you have to specify all four arguments. The first 2 are the host name (or IP address) and port number of the data server, the last 2 those of the render server. Here are some examples.

# Connect to built-in
>>> connection = servermanager.Connect()

# Connect to pvserver running on amber1 (first node of our test cluster)
# using the default port 11111
>>> connection = servermanager.Connect(amber1)

# Connect to pvdataserver running on the amber cluster, pvrenderserver 
# running on Berk’s desktop
>>> connection = servermanager.Connect(amber1, 12000, kamino, 11111)

Although not fully implemented yet, the servermanager supports multiple connection. The module keeps track of the active connection with the ActiveConnection variable. By default, all communication is sent to the server to which the ActiveConnection points. The first time Connect() is called, servermanager automatically sets ActiveConnection. After the first time, unless Disconnect() is called first, ActiveConnection is not set. If you want to set the ActiveConnection to another connection, use the return value from Connect().

>>> servermanager.ActiveConnection = servermanager.Connect(amber1)

Note: Connect() will return None on failure. To be safe, you should check the return value of Connect().