In this and the previous chapter we have presented several application areas in which VISSION was successfully used. In the following several observations on the flexibility and limitations ofVISSION are presented which addressVISSION’s suitability as a framework for domain specific application con- struction and steering.
One of the most challenging problems SimVis researchers and software designers are confronted with is the choice of the software platform or environment to suit a given application. In most cases, a perfectly suited application does not exist, so one has to adapt an existing one or build a new one. In research environments, coding and adapting new components and gluing existing ones together to pro- duce several application setups is a routine task. It is, however, also this task that is the most tiresome and error prone part of the research and development process. This is mainly due to the heterogeneity of existing software components that range from monolithic applications to frameworks and libraries, ending up with small, self developed algorithms. A frequent question SimVis software practitioners asks themselves is: which software environment should I adopt such that I can easily combine my own code with other people’s code, and with the powerful available large SimVis libraries?
In this respect,VISSION’s non intrusive code integration policy proved to be a powerful concept. Code components which were developed on a totally independent basis, ranging from two very large C++ libraries (VTK and Inventor) containing over 500 components each, to small libraries (under 20 components) and one-component code fragments independently developed by several researchers could be integrated and coupled together. The only programming effort involved writing the corre- sponding metaclasses having a size of approximately 6 MC++ lines per metaclass. This process could be done gradually. First, only the base classes of VTK and a few concrete filters, mappers, and a 3D viewer were integrated to test the concept. Next, the remaining VTK classes were integrated. No
modification to the original VTK code was done. In a few cases when we detected an erroneous or otherwise undesired behaviour of the integrated VTK classes, we provided some simple C++ wrap- pers around the original VTK code. These wrappers maintain the same interfaces and delegate their operations to the underlying VTK implementation, but apply the desired checks or adaptation to the original operations. As the original VTK code was not modified, we could use it as it evolved through several releases with practically no change to our metaclasses. Only a few minor interface changes were needed when the new VTK releases changed some component signatures.
other minor changes were sometimes needed, e.g. when ’wrapping’ an algorithm present as a fully independent, console-based C program, into a C++ class declaration that communicates with the out- side world via method calls instead of the standard input and output. In most cases this actually made the original code even more reusable and context independent. Each component set preserved its own typing policies, as there is no need to e.g. force all components to use the same dataset structures. The same holds for execution mechanisms, as, for example, VTK uses internally a demand driven dataflow, while Inventor has an event driven one. Components from the two libraries can, however, be freely in- termixed inVISSIONpipelines.
The above facts lead to the following strategy for a typicalVISSIONuser:
1. identify the application domain of interest (e.g., finite difference computations)
2. find an existing software library that addresses the respective domain. If such a library exist, bring it to the form of a C++ class library. In virtually all cases, this should be relatively easy, as C++ offers a clearly more powerful set of concepts and interface mechanisms than other lan- guages such as C or FORTRAN.
3. test the library offline, e.g. in a classical console-based program.
4. write the meta-library for the existing C++ library. This is trivial in most cases, as MC++ was especially designed to cope with C++ interfaced components.
5. use the library inVISSION, possibly by intermixing its components with other components al- ready present inVISSION. In this way, one has to provide only the components particular to his application domain, as many general-purpose visualisation and graphics primitives are already present inVISSIONvia the VTK and Inventor libraries.
The above scenario was applied successfully to building over 50 visualisations and graphics applica- tions by integrating the VTK and Inventor libraries inVISSION. Several other more specific application domains such as numerical computations and realistic rendering were addressed in basically the same way. In most cases, applications used components from two or three different libraries, which proves that component reuse and interoperability takes indeed place inVISSION. The fact that several libraries with over 600 components were made available inVISSION, either by adapting existing code or by writing it from scratch proves that the system scales well. VISSION’s combination of visual dataflow programming, supported by a flexible code integration mechanism proves to be an effective alternative for SimVis researchers to the classical paradigm of writing a standalone program doing computations, interaction, and visualisation for every new application.
One has to admit that classical programming is undoubtedly more flexible than visual dataflow programming. If one has total freedom over the way code statements are written, it is obvious that more control can be achieved over the shape of the final application than when combining a few tenths of blocks controlled by a few parameters and a fixed dataflow execution model. However, one should not forget which are the prices to pay for this freedom:
0
Writing, debugging, understanding, and maintaining classical code is orders of magnitude more difficult than doing the same to a visual network. Building a visual pipeline involves no pro- gramming knowledge, while building a similar application in a classical way involves familiarity with a compiler and a programming language, component libraries, GUI libraries, windowing systems, and possibly more. The time it takes to do the same operations in a visual environment is much shorter, even for e.g. expert C++ programmers.
0
Sharing data between peer researchers has taken place since long. Sharing applications and code is however rarely done, as people have different coding styles. Visual dataflow programming and the distribution of code asVISSIONmeta-libraries makes the interchange of code modules or full applications much easier, as these now obey a standard form.
Conclusions
8.1
Introduction
This thesis addresses the development of interactive scientific simulation and visualisation (SimVis) applications in academic research environments. Such environments pose major challenges to the de- velopment and use of SimVis software applications. Research applications usually have an experimen- tal nature. They are built to test new concepts, algorithms, data structures, and so on. The nature of the research process implies a continuously changing structure of the SimVis software applications. In- sight or new ideas acquired during the (interactive) experimentation with the application often urge the need to add or remove numerical or visualisation software components, recode components, or even write new components from scratch.