ParaQ:Compound Filter Design

Overview

An important capability of ParaQ is the ability to capture the work that a user has done, and make it available to other users in the form of a Compound Filter (CF).

This draft document will address Compound Filters at the two levels - ParaView Server Manager, and ParaQ client. The PVSM level describes capabilities available to all clients. Though it is up to each client to determine how to expose a CF, this document proposes a simple implementation.

NOTE: Historically, this has been known as a 'Macro' capability, but the group has determined that this is misleading, so we have coined the term 'Compound Filter' instead.

Definition

A Compound Filter contains:

1. Zero or more Compound Filters
2. One or more ParaView Server Manager objects, their settings, input/output connections, and linkings
   1. These objects need not be connected; multiple 'root' objects may exist.
3. Zero or more input connection definitions
4. Zero or more output connection definitions

Simple, yet Complex

A CF is intended to simplify user interactions by 'bundling up' capability into smaller, more manageable chunks. At the same time, the inner workings of a CF must somehow be available to expert users - allowing them to tweak internal settings, or to re-use a CF by making adjustments inside the filter, and re-saving it as a different CF.

A CF's 'locked' (or simple) representation:

• Is 'locked' - the user cannot see inside it, or manipulate, in any way, the filters within it.
• Has a pre-defined set of zero or more inputs.
• Has a pre-defined set of zero or more outputs.
• Has a pre-defined set of controls.

A CF's 'unlocked' representation:

• Is fully exposed, and open to manipulation by the user. There is no restriction on what the user can do, once the CF has been unlocked. The CF is reduced to a hierarchy of PVSM objects.

Other things to note:

• A CF can only be 're-locked' immediately after locking it. There is no requirement that the system be able to evaluate an 'unlocked' CF and determine if it can be locked again.

Managing CF's

CF's shall be implemented much the same way as application plugins. A CF has the following characteristics:

1. It resides on disk, in a well-organized directory
2. A ParaView state file includes the following information about a CF:
   1. URL(path,name)/UUID
   2. CF version number
   3. (optional) Values for CF properties
   4. (optional) Values for CF UI
   5. (optional) other informaion

In this scenario, a ParaView client:

1. Loads a PVSM state
2. Searches a set of directories for the CF definition.
   1. If it finds the CF definition, the version is checked, and some reconciliation occurs (user-directed or automatic)
   2. If it does not find the CF, it informs the user, and continues. Relevant information should be easily accessible to the user.

Short Term (Demo) Deliverables

1. Demo requires interacting with 'locked' CF's only.
   1. ParaQ UI element showing a 'locked' state.
2. Demo requires CF loading, and application of a CF to a dataset. All creation and editing can be done by hand, or through ParaView.
3. PVSM state parsing and in-memory objects. API for accessing this in-memory state.

Compound Filter Requirements on PVSM

1. There must be hierarchical server manager states. For example, we can think of importing a filter as importing a server manager state into another server manager state, like this:

 - Root of Application Data
   - Client-specific Data (ParaQ would record UI state, etc.)
   - Server Manager State
     - CF (imported Server Manager State)

1. There must be a notion of a 'group' in PVSM - a set of objects that are related. A CF is essentially a 'locked group'

ParaView Server Manager Level

Implementation

A Compound Filter will be implemented as a ParaView Server state file. This XML file will be parsed by classes within the ParaView Server Manager, which will expose an API to any client wishing to build a client-side representation of that Compound Filter. This is exactly the same mechanism that will be used to inform a client of the current state of the server.

It is up to the client to:

1. Build a client-side representation of the compound filter.

Decisions to be made

1. Is the term 'Compound Filter' acceptible to the group?

ParaQ Client Level

Use Cases

UC1: Saving a Single Filter Graph

The user creates a single filter graph, consisting of an Exodus Reader, a Threshold Filter, and filters needed to Glyph. Selecting those elements in a hierarchy view, the user indicates that the selected filters should be saved as a macro. For example, by right mouse clicking on the selected items. The Compound Filter is saved locally as a ParaView Server Manager state file.

UC2: Importing a Single Filter Graph

The user opens a new version of ParaQ, and selects an 'Import Compound Filter' (for example) menu item. This populates a hierarchy view with the following items:

 @ [Macro Name]
  

This item, when inspected with an object inspector, presents a simplified interface, defined at export time by the user.

If the user wants to tweak settings within the CF, he selects the CF in an appropriate view, then selects the 'Unlock CF' menu item. This exposes the internals of the CF, and removes all restrictions. The Group item [Macro Node] now represents just a group - there is no CF in the application.

 + [Macro Name]
     Exodus Reader
     Threshold
     Glyphing Filters