ParaView Plugin

Installation

There are three components to the VisTrails plugin for ParaView. First, a patch to the ParaView source code is required, since ParaView does not provide the necessary access to its undo stack by default. Second, there is a standard ParaView plugin that will capture the actions that the user performs. Third, there is a plugin version of VisTrails.

ParaView Patch

ParaView must be compiled from source for the VisTrails plugin to work. The source code can be downloaded from here. Since there has been development on the undo stack in ParaView between the latest release (3.4) and the current cvs development version, there are two patches available.

• ParaView-3.4.0.patch
• ParaView-dev.patch

These patches can be installed with (use Cygwin on Windows):

cd ParaView3
patch -p0 < ParaView.patch

The BULID_SHARED_LIBS CMake variable must be set to ON, and ParaView can then be compiled as normal.

ParaView Plugin

The ParaView plugin also uses CMake to generate Visual Studio project files and make files. You may need to set the ParaView_DIR CMake variable to point to your ParaView source directory. The plugin can then be compiled, which creates 'VisTrails.dll' on Windows, and 'libVisTrails.so' on Linux. This can be loaded manually from within ParaView, or it can be copied to the ParaView plugins directory so it automatically gets loaded on startup.

VisTrails Plugin Version

Python 2.5 is required to run the plugin version of VisTrails. No compiling is necessary, though it must be placed in the correct directory so that the plugin can find it.

cd /path/to/paraview/executable/
mkdir plugins
cd plugins
cp -r /path/to/vistrails/plugin/version vistrails

Usage

With the VisTrails plugin loaded, ParaView may be used as normal. As the user performs actions, they are recorded by VisTrails in the Provenance Recorder window. ParaView pipelines can be loaded simply by clicking on the desired version. Currently, when data files are loaded in ParaView, VisTrails records the absolute filename. Therefore, whenever the pipeline is replayed, all of the datafiles must be available in the same location.

The user may load ParaView state files, but state loads cannot be undone. When a pipeline that is higher in the version tree is selected, playback must begin at the root, which may be slow. Like data files, the absolute path of state files are stored by VisTrails, so replaying of the state load requires that the file remains in the same place and unchanged. VisTrails .vt files can be saved and loaded from the Provenance Recorder, which will include the current state, as well as all previous states that have been explored. State files can also be saved from ParaView, and loaded into instances that do not have the VisTrails plugin loaded.

Most view state changes are not recorded by the plugin. When loading a .vt file, you may need to 'Zoom To Data' for a good view.

Known issues

• The plugin has only been tested with a local ParaView server configuration.
• When loading ParaView with VisTrails already running, VisTrails captures some of the initialization of ParaView. This is not standard usage, and this has not been seen when the ParaView plugin spawns the VisTrails process itself. However, it is not inconcievable that it could happen. When the Provenance Recorder window opens, it should only have a single empty oval in it. If it has several pipelines already in it, simply create a new VisTrail.

Programming Notes

• Types of operations:
  • Generic changes that get put on the undo stack.
  • State file load.
    • Must be replayed from version 0 since these cannot be undone.
  • Anything else that doesn't get put on the undo stack will not be captured and therefore not replay correctly!
• ParaView / VisTrails message loops.