ParaView Plugins

ParaView really needs a good plugin mechanism. ParaView 3 is supposed to be an updated mechanism for more flexibility, and already people are clamoring to add their own code into ParaView 3. Although a custom interface might be sufficient for some of these purposes, these vertical applications are not a panacea. For one thing, vertical applications have a much higher overhead in both development and support. For another, designing a vertical application from the ground up will probably result in many other ParaView features being dropped. Custom filters also help, but they only allow a user to combine functionality that exists in ParaView, not bring in totally new functionality.

Use Cases

This section captures the use cases for ParaView plugins. I encourage everyone to add their own use cases, but let us limit them to real users with real needs so that we can manage the scope of our design.

Prism

We all know that the Prism vertical application will not have funding for support in the next fiscal year. Thus, we are trying very hard to absorb the functionality of Prism into ParaView. Although the focused user interface will be missing, the basic functionality will be present and coupled with the rest of the functionality of ParaView.

Let us consider everything we need to implement the Prism functionality. Prism has a custom reader to read in data from SESAME files. It also has some custom filters to process the SESAME data and Exodus data for presentation. Perhaps most important is the custom view that Prism supports that shows data in a phase-space plot. There is also a linking of the simultaneous 3D geometry view and phase-space plot that allows selections to be consistent between them.

Although most, if not all, the Prism functionality will eventually migrate into ParaView, let us take this as an example of trying to develop and deploy a new feature involving multiple and custom views. If we had the appropriate multiview and plugin capability during the initial Prism work, we may have been able to cull a significant amount of development work. Furthermore, Prism is not an isolated use case. The Mohr's circle work could also have benefited greatly with a simple deployment platform rather than having to build an entire application from the ground up. The comparative and uncertainty visualizations on the horizon also have potentially similar needs. Once the InfoVis work is integrated into VTK/ParaView, there will be many opportunities for plugging in new views, and the ParaView community at large will be interested in doing just this.

Goodyear

Goodyear is planning on using ParaView to replace their legacy visualization tools. After talking with Illana Iskovitz at Goodyear, we have agreed that the best we to do this is with a ParaView plugin rather than an entire vertical application.

The plugin will define a set of filters. These filters will be accessible through the application menu and with a toolbar. The toolbar will have custom images for each filter. The filters themselves will be composites of existing filters, new custom C++ filters, and composites of existing and new filters.

The big portion of the customization is that, because the Goodyear analysts work with tires, it is often convenient to parametrize the models radially. The custom filters will have to present and work with these cylindrical coordinates. In the future, they may even need custom 3D widgets that sweep radially.

Also, for ease of use, many of the "filter" operations must set up viewing parameters like camera coordinates and display properties. This is because, for a certain operation, the analyst needs to see the same view into the data every time.

Developer Playground

Oftentimes developers, such as myself (User:kmorel), want to experiment with VTK code they are working with. It is very convenient to simply wrap the unit up in a ParaView plugin and use it within that framework rather than write some temporary scaffolding code. This allows the developer to easily experiment with the new unit or apply the unit to some data to perform a particular task. It also provides a simple deployment mechanism for friendly customers.

The current ability of ParaView 2 to load in a new reader or filter is invaluable, and ParaView 3 needs to replicate this ability. Also, as we dive further into the infovis world, views will also become a common component to implement in VTK. It should also be straightforward to plug experimental views into ParaView.

Electrical Simulation (ESim Vis) a.k.a. dramatically changing the ParaView look and feel but getting all the goodies under the hood

We (Sandia) are embarking on a project which will use ParaView3, or at the least ParaView3 components to create a custom application for visualizing electrical waveform results from circuit simulators. The graphics view for this application are represented by 2D plots.

Ideally we would implement the ESim Vis tool by a combination of ParaView3 plug-in and app-specific configuration files (rather than creating a custom application that implements the pqMainWindowCore class).

The following requirements were gathered from the customer:

• Read output(s) from XYCE
• Ease of use
• Out-of-box ease of use – i.e. give me a decent display right away
• Ideally would have the same feature set as Probe (Probe the xy plotting tool, not Probe the VTK filter) (Probe = 3rd commercial tool for waveform vis for circuit simulations) (.csd output files)
• Can read large files (e.g. 5 GB or larger)
• Send plot to printer
• Data reduction methods
• View multiple graphs simultaneously
• (easy) Add-on capability if desire to extend tool
• Resampling of data should not miss (critical) events -- E.g. Sharpest rise time – XDAMP resamples, a nano sec event might come along with a high peak and fall, XDAMP could miss those events
• Desire to have GRACE-like features
• Ability to manipulate waveforms
• Add data as client/server is running
• Experimental data format (reader)
• Cross platform – Windows and Linux will cover most use cases

Requirements

The following requirements must be met to satisfy the #use cases above.

Shared object modules

Many of the use cases require custom C++ code. It must be possible to compile the code into a shared object library (or dynamic link library on Win32 or module on Mac) and load it directly into ParaView.

Client/Server support

We must be able to load in plugins when running in client/server mode. It is not practical to assume that we will be able to deliver every plugin for every user on every platform for every build. Also, delivering plugins may be a good way to reduce the delivery time for a specific feature (compared to waiting for another release of ParaView).

Custom VTK objects

A plugin needs the ability to add its own VTK objects and have them available as proxy objects to the client.

GUI reader/filter entries

A plugin should be able to add new readers and filters to the UI as well as the appropriate object inspectors for them.

Custom Qt widgets

Some reader or filters may require custom widgets. The plugin should also be able to contain these widgets as well as a mechanism for adding it to a GUI component (such as an object inspector).

This may be tricky. How are we going to define in the plugin where these custom widgets are going to go and how they will be linked to the application (i.e. events)? I would suggest that we leave this out of the plugin mechanism and require changes to the code to add custom widgets. Berk 16:34, 21 Nov 2006 (EST)

Although I never actually said this, I was specificially thinking of customizing the object inspector properties page. This would either be a custom widget that a hint in the server manager XML would point to, or a customized panel for cases where the autogenerated panels don't work well. I think these with these constraints the issues of where they go and and how events connect to the application go away. --Ken 05:53, 30 Nov 2006 (EST)

New toolbars

The plugin should have the ability to add a toolbar to the GUI with custom icons (that are also embedded in the plugin). At the very least, these buttons should be able to create readers and filters.

New view

Need an ability to add a new type of "view."

Maybe requirements:

Arbitrary C++ calls

The ability for a toolbar button action to run arbitrary C++ code on the client side.

Design

The basic design of ParaView plugins is to encapsulate the plugin in a system specific object file that can be dynamically loaded (dynamic library on Win32, shared object library on unix, module on Mac OS X). This object file (henceforth called the plugin or the plugin file) will contain any source code the user needs included with the plugin as well as any other ParaView-specific information (such as server manager XML) embeded in it. The plugin file will also contain a name and version to identify it. When ParaView loads the plugin file, it will automatically find the components embeded in the plugin and install them.

Definition Mechanism

There should be a minimum amount of effort for creating a plugin above and beyond the actual source code and other input files. This can be achieved with a CMake macro. The macro is called ADD_PARAVIEW_PLUGIN. (Or whatever. The name doesn't matter much, but we just need something to call it.) The macro is automatically defined whenever a CMake project includes the use of ParaView.

FIND_PACKAGE(ParaView3)
INCLUDE(${USE_PARAVIEW3_FILE})

The ADD_PARAVIEW_PLUGIN macro has the following parameter structure.

ADD_PARAVIEW_PLUGIN(name version
  [SERVER_MANAGER_SOURCES source files]
  [SERVER_MANAGER_XML xml file]
  [WIDGETS widget names]
  [QT_RESOURCES qt resource files]
  [INITIALIZATION initalization object source]
  [SOURCES source files]
  [CLIENT_ONLY]
  reader, filter, and toolbar definitions
  [DEPENDS plugin name [plugin version]...]
)

Note that an implementation of an argument parser is available at http://www.cmake.org/Wiki/CMakeMacroParseArguments.

Loading Mechanism