AGOCG logo
Graphics Multimedia VR Visualisation Contents
Training Reports Workshops Briefings Index
This report is also available as an Acrobat file.
Next Back [Top]

Review of Visualisation Systems

6.4 IRIS Explorer

6.4.1 - Programming language
6.4.2 - General overview and structure
6.4.3 - Automatic generation
6.4.4 - General topics

6.4.1 Programming language

The programming languages that are supported directly by IRIS Explorer are:

6.4.2 General overview and structure

Modules are written as a user function and associated subroutines called from the user function. These are then compiled and automatically embedded within an Explorer wrapper. The input and output ports of the final module are expressed as mappings from the parameters of the user function to Explorer data types. It is possible to create hook functions that can be called in specific circumstances i.e. the initialisation hook function is called when the module is launched into the map and is used to do initialisation for the module.

Module compilation is done using a graphical interface called Module Builder (mbuilder) which requires the name of the source code file, the Module name, any flags, any Libraries and any User Makefile. There are then subsequent visual interfaces for:-

Once all aspects of the module have been entered into the Module Builder, selecting build will cause it to begin compiling the module. On building, a set of makefiles are produced and all error messages are returned to the screen. Once these makefiles are produced the module can be recompiled externally to Module Builder by using UNIX make. Building a module not only produces the executable, but also the C source code for the interface between the user function and the remainder of Explorer.

Explorer uses three controlling interfaces or wrappers to mediate between the module's user function and the rest of the system. These are the Module Control Wrapper (MCW), the Module Data Wrapper (MDW) and the Generic Wrapper. All three of these are generated automatically on building, though the MDW can be turned off but the user must then incorporate the MDW functions in their own code. The MCW is the module data manager, contains the firing algorithm and provides interfaces to input and output functions, including port and widget settings. The MDW performs conversions between Explorer and user-defined data types on the ports and the data format required by the user. The user can thus develop modules with customised interfaces without having to interact with Explorer data types. The Generic Wrapper is not accessible to the module writer, except indirectly through Hook Functions menu.

As an alternative to writing C/Fortran code and having to build, link and compile after each alteration, Explorer provides a method of generating user defined modules that act on the Lattice data type, without having to use Module Builder. The LatFunction module is an interpreter for a lattice manipulation language called Shape that makes it easy to operate on Lattices. It allows the user to interactively change the way LatFunction acts on the data it receives, which provides a quick way to prototype a new module without having to actually compile it. The user passes the name of the Shape program file as a parameter to the LatFunction module. Shape is an interpreted, array-oriented language with a C-like syntax which makes it easy to create, process and manipulate lattices. Since the program is interpreted, changing the output lattice can be done by changing the name of the file passed to LatFunction - i.e. a new module doesn't have to be launched every time the lattice needs to be changed. This makes LatFunction useful in prototyping or testing new modules.

How is control passed to/from a module?

The modules are all free to fire independently of each other, the only constraint being that they have the data on their input ports that they require. In practice this means that control is passed from upstream modules to downstream modules as data (or parameters) are generated/altered and passed on.

How is data passed to/from a module?

Data flow between modules is specified by the user by wiring modules in the Map Editor together. The connections are made from the output port of one module (always on the right of a module control panel) to the input port of another module (always on the left). This is done by pointing and clicking over the relevant port which pops a list of available output ports, selecting one of these then causes the other modules with compatible input ports to be highlighted. A wire is then displayed in the map editor linking the two modules together. On workstations supporting shared memory only the pointers are copied, not the data itself.

6.4.3 Automatic generation

The tool for this with Explorer is Module Builder (see figure 15
), used as described above, filling in details of ports and function arguments to describe the flow of data through the module. However, instead of using the build option, "Create function prototype" is selected from the Prototypes menu and a source code template is created with gaps for the user to write their function.

One of the menu options on mbuilder is for creating document prototypes. This option produces a standard document file with all the input/output data structures listed, also, mbuilder automatically produces the template for the module help files in the standard format with all the port data types listed as for the doc pages. Gaps are left for the user to fill in specific details of the module and port descriptions using any standard editor.

6.4.4 General topics

Application control of the module

The firing algorithm in the Module Control Wrapper (MCW) is responsible for determining when the module is ready to fire. It is based on whether all the required frames of data are present on the input ports. The user can make a module fire by selecting the fire option from the pop up menu associated with each module. Explorer provides a means of registering file descriptors with the Explorer Kernel through the API function cxInputAdd. This descriptor is then watched by Explorer and when there is data to read a callback function is called. This in turn can then request that its associated user function be fired by calling the API function fireASAP(). Through this method it is possible to connect to external UNIX sockets and hence to other applications/devices.

Remote execution

In IRIS Explorer this is achieved by simply calling up a module Librarian on an alternative machine. This is done through the host pull down menu which gives a dialogue box into which the host name is entered. This new Librarian is used in the same way as the local one where modules are selected from it and placed in the map. Explorer takes care of the rest. These modules are marked with the name of the machine they are running on.

Shared Data

Explorer uses a shared memory model for storing data. This allows modules to share a single copy of, say a Lattice, which remains in memory until it is no longer being referenced by any modules. This is achieved by means of a reference count stored within the data structure.

User interface

In Module Builder there is an option for editing the control panel of a module. Selecting this gives a visual tool for designing and arranging the widgets associated with a module. It is possible to set size, default values, positions, visibility, sizeability and widget type. Also it is possible to add text labels, frames, and separators. The widgets are associated with the user function by expressing them in the argument list as cxParameter types. The P-func Editor can be used to calculate an input parameter value from one or more connected parameters on other modules in the map.

There is an option to build a module with X-MCW which uses the X mechanism for handling scheduling. Using this option allows Explorer to recognise and manipulate X Window or Motif widgets in a module. The advantages of this are that you have complete freedom in creating the user interface.

At a higher level, it is possible to group a set of modules that make up a map and edit a control panel made up from some (or all) of the widgets available from all the modules in the group. This includes the graphical output windows of DisplayImg and Render. This is done from within the map editor and can be saved as a map. This map can then be run in application mode which is where the map editor and librarian are unused and just the user defined control panel is visible.


Module Builder allows the cross compilation of C and Fortran and also the inclusion of object code. All the required files are listed in the text box "User Func File" as a space separated list. Mbuilder needs the language type of the actual user function, but the rest are defined by their file extension. External libraries can be linked by inserting them in the Libraries text slot in the same way they are listed in the UNIX link command. It uses the form -l<library> for individual libraries.

Debugging support

Debugging support is provided by compiling the module with an environment variable DEBUG set to 1 to force the use of the -g flag. A module is then launched into a map and any of a number of debuggers can be attached through the modules process ID.

Explorer does some runtime checking of data and there are a few options as to the course of action taken if an error is found. These are selected at run time from the -action <INT> option where

and -level <0/1> which sets the level of data checking.


The module writer's guide contains an initial chapter going through building a module with a fairly trivial example (the source of which can be found on line) explaining what the basic elements of Module Builder do. The next chapter runs in parallel with the first and gives a more general overview of Module Builder. There are chapters for each of the data types with examples of code in both C and Fortran. In addition to the Module Writer's Guide there are UNIX man pages in 2 sections, the first covering all the standard modules, the second covering all the API routines.

There are also available courses from NAG which include an introductory and advanced course. For more information you should contact NAG directly.

Review of Visualisation Systems
Next Back [Top]

Generated with CERN WebMaker

Graphics     Multimedia      Virtual Environments      Visualisation      Contents