The problem

The grid-function limits is the minimal and maximum values a grid-function assumes. The limits is used mainly by the vizu-window to determine how to map the color-scale in the grid-part, based on the grid-function values. The main problem, is not really how to obtain the grid-function limits for a certain grid-function, but how to manage these limits in a way that the visualization make sense.

While working with limits we have to consider several aspects:

• Parts: A problem can be composed of several parts (grid-part). When displaying one part we want to consider the limits of all parts of the group, not only the part being displayed.

• Time: A grid-function can vary with time (transient grid-function). The user may want to check the value of a certain time-step against the value assumed during the entire simulation, so, the limits must consider the values the grid-function can assume during all time-steps.

• Vizu: While viewing several parts in a vizu-window, the user may want that all those visible parts, and only them, interfere in the visualization limits. If any part is removed or added, the limits must be changed properly.

• Units: Associated with the limits scalar-values there is a unit (or Quantity). The unit of the limits must be displayed to the user and any discrepancy must be taken into account.

• Scalar-Bar: The scalar bar displays the color-scale associated with a grid-function and the current limits. It must be updated using the actual limits the "actor" is using to render the grid-part.

• Limits options: Depending on the case being study, the user may want to change how the limits are calculated, choosing how the "Parts" and "Time" are handled by the application: either locally (local) or considering all the elements available (global). The user can also manually set a limits value (custom).

• Global limits: Consider all the loaded sources when determining the limits for a grid-function. This is necessary when comparing two different cases in separated vizu-windows.

The Solution

The limits is responsibility of the source-process. The other processes in the hierarchy ( Process Hierarchy ) ask the source process using the Query mechanism.

The source-process is the ideal place for limits handling, since it has direct access to the source of data, that is, the reader. It can either obtain the limits from the reader, or, if there is no limits stored in the file, it loads the grid-function and calculates the limits.

The Parts and Time Problems

The LimitsManager class implements the limits-manager at source-process level. It solves the "Parts" and "Time" problems by declaring "dimensions". Each dimension can be local or global. When set to local, the limits-manager considers only the value passed via parameter. If global, it consider all possible values that dimension can assume.

The Vizu Problem

The Vizu problem, in the other hand, is solved by the vizu-window itself. That is because it depends on information that only the vizu-window have: Which processes are using the grid-function. Of course, this information could flow to the source-process and handled there, but we decided to solve in the vizu-window side.

The vizu-window implements the "vizu-limits" feature, which consists in a query-implementation, for the "grid-function-limits" query, that considers all the visible coloring-processes registered in the vizu-window. When vizu-limits is enabled, this query replaces the "grid-function-limits" query of all registered processes providing the desired solution.

The Limits options problem:

We decided to associate grid-function options to the grid-function name. That includes the color-scale, limits and units options. For each grid-function there is only one place to change this options: in the GridFunctionUserData.

The main problem with that solution is how to connect the guys that stores the information with the guys that need them. This is solved using the plugin mechanism, via the EPGridFunctionUserDataProvider.

The process also works in the other way, that is, the grid-function-user-data needs information from the process hierarchy which is far far away from it:

• Valid initial value for the custom limits,
• The grid-function quantity and unit to initialize the "preferred unit" option,

The plugin mechanism, together with the Query mechanism solve these problems.