|
|
|
|
|
|
|
|
|
|
||||||||
|
|
|
|
|||||
|
|
|
|
|
|
|||
The Field description represents a mapping between your actual data sampling space and the Data Explorer graphics system used to make images of that data space. Given such a mapping, the next step is to learn how to visualize your data in meaningful ways. Data Explorer provides both a visual programming language and a text-based scripting language. The scripting language is described in Chapter 10. "Data Explorer Scripting Language". The visual programming language uses a graphically oriented editor instead of a traditional text-based editor as in C or Pascal. You will be using this graphical programming environment to generate graphic images as output; this distinction between graphics as program and graphics as output is subtle, but we do not want to confuse the two.
To build a visual program, you physically select, place, and connect functional modules; these are represented graphically as labeled rectangular boxes with tabs sticking out of them. Each module can be thought of as a subroutine in a text-based programming system. You can place multiple instances of the same module, analogous to calling a subroutine several times in a program. Modules have inputs and outputs (those little tabs sticking out) just like the arguments and return values in a text language. The inputs and outputs of modules are connected together into a network, which in some ways resembles a flow-chart diagram. (Unlike a flow-chart, you cannot loop back a wire to an earlier input in a Data Explorer visual program) Note that many modules have "hidden" tabs for less commonly used parameters. You can expose hidden parameters by using the Expand button in the module's Configuration dialog box.
Generally speaking, you use Data Explorer to visualize your data in the following way. First, bring in the data from a disk file as a Field (the Import module can read in a Data Explorer format file, a General Array Importer file, or netCDF, CDF, or HDF files). Next, run the imported data Field through one or more modules found in the Realization category. Each of these produces a visual object. You may also want to process these Realizations through Transformation modules to modify the visual or other characteristics of an object. Either one or a collection of visual objects is then displayed in an Image window. The Image window provides a number of convenient tools for interactively rotating your visual objects, zooming in for a closer look at them, and so on. There are many different variations of the above scheme: for example, modules like Construct allow you to create simple Fields without having to import data; Structuring category modules permit you to modify Field components in many ways; other types of output are provided so you can write image files to disk, and so on. But the concept of Import-Realize-Transform-Image is the basic and most common approach to using Data Explorer.
So what happens inside a visual program? The Field with its components flows through one module after another. Some modules add new components, others remove or change components. However, an essential point to keep in mind is that unless a module is designed to operate on a specific component, it does not affect any other part of a Field. That is to say, if you feed a Field into a module that does not operate on the "positions" component, then from the output of that module will come a Field with the identical (unchanged) positions component. And that means that another module further "downstream" in the visual program can operate on that "positions" component if need be. This differs in a critical way from traditional languages, which explicitly specify all return values from a function. In Data Explorer, assume that everything that goes into a module comes out (though often changed), whereas in a traditional language, ignoring side-effects (bad programming practice, usually), only those values specifically indicated as return values are returned when the function exits. The descriptions in IBM Visualization Data Explorer User's Reference identify the components that are changed, deleted, or added by each module.
It is also very often useful to "branch" a visual program. Any module input can only have one wire ("tab connection") attached to it at a time. However, any module output can feed several different module inputs. This allows you to run copies of the same Field through different "subnets" to perform several different operations on it. To see all of these visual outputs in the same scene, you use the Collect module to gather all the "subnet" output wires back together. The single output from Collect (called a Group) can be attached to the input of the Image module. The Collect module shares a handy feature with some other modules in that you can easily add new inputs to it if you need more than the two default input tabs.
See Appendix A. "Using Data Explorer: Some Useful Hints" for discussions of the following:
[ OpenDX Home at IBM | OpenDX.org ]