DynSys3D: system design

The design of DynSys3D mainly consists of a set of structural specifications and principal decisions. There is no specific functional core of the system, which has to be available when implementing further software based on this workbench. The main advantage of working within DynSys3D is the ability to reuse already existing software components and, simultaneously, to extend the system by new features.

   
Principal components

A major element of the system is the principal component. Initially DynSys3D consisted of three of them: DYNAMICAL SYSTEM, NUMERICAL INTEGRATOR, and VISUALIZATION TECHNIQUE. A module is built by choosing appropriate representatives of the principal components involved and linking them together to an AVS module. For example, a combination of LORENZ, EULER and STREAMLINE, would result in an AVS module, which is capable of generating a stream line which represents the Lorenz attractor by using Euler integration [63].

All representatives of a principal component must conform to an interface given by DynSys3D. The interface specification is represented as a header file within the system. This file lists the maximum capabilities of a principal component. Representatives of a component, which do not implement the whole list of functions are also possible, but may not, due to their limitations, be able to work with certain other component instances. The check whether some instances work together or not is done automatically during the link step.

   
Separating visualization techniques and module interfaces

The most important principal component of DynSys3D is the VISUALIZATION TECHNIQUE. Instances of this class represent the core of the modules and thus provide the mechanisms that are necessary for building an AVS module. The visualization technique itself should be clearly decoupled from the AVS interface functionality. This allows easy reuse of the visualization-technique code within other compound visualization techniques. For example, it should be possible to reuse the stream line technique within another module which generates an entire rack of stream lines.

AVS modules mainly consist of one main C procedure each. It is invoked by AVS, whenever new data has been propagated to the module through the data-flow network or a module parameter was changed by the user. During each call the current input data and parameter values are handed over to this main function via parameters. Generally this main function performs the visualization technique represented by the module and finally returns the resulting output data to AVS.

Within DynSys3D the main function of a module represents a separation layer between the AVS interface and the implementation of the visualization technique. Parameters, input, and output are managed within this layer and another function is called to perform the required visualization technique. It is this second function which can be reused by other modules without major changes or adaptations.

   
Multiple developers

DynSys3D was designed to support multiple developers extending the system in parallel. In general several difficulties arise in such a situation: Developers often get a local copy of the system and extend it by their own contributions. Afterwards all these copies have to be merged, which is potentially rather difficult. Even if the instantiation of multiple copies of the system is omitted, problems may arise: Code which was already usable may become corrupt again, when debugging is performed on the code.

The design of the system allows to reduce these problems. Only the directory hierarchy of DynSys3D is replicated for all the developers. They build their implementations locally until it is finished. Whenever a developer needs an already existing system component, a link to the DynSys3D directory tree is installed instead of the replicated local directory. Developers are encouraged to make already working parts of their work early available to the others by placing them as compiled code within the DynSys3D file space. These submitted object files stay available to the others even if the local copy of the developer may not work momentarily. When a new component is finished, it is moved from the developers local hierarchy to the DynSys3D area and installed as standard component.

   
Focus on visualization

The design of DynSys3D reflects the intention of providing a system, which allows to concentrate on visualization aspects. Some tasks during the analysis of dynamical systems, however, belong to other areas like mathematics and numerics and had to be tackled, at least partially, as well. One class of such problems is the identification of characteristic subsets in a dynamical system. Writing a piece of software, which is capable of finding all these elements as, e.g., critical points, cycles, and separatrices, is beyond the scope of DynSys3D. In this specific case we transfered the search for these characteristic elements from the visualization component to the dynamical system itself. This is done as it is much easier for a specific dynamical system to declare its critical points than for a general piece of software to identify characteristic subsets for arbitrary dynamical systems. Another reason why this solution seems to be appropriate is that often the results of analytical analyses are available prior to the visualization step.

   
Interactivity

Visualization usually is demanding in terms of time and computer resources [73]. Complex operations during the several steps of the visualization pipeline and the huge amount of data involved in the calculations slow down the visualization in most cases. Moreover in many cases the data generation, e.g., numerical simulations, take even longer than the visualization itself.

In the case of this thesis the actual visualization techniques are also often far from being interactive. Anyhow we thought that at least an interactive inspection of the results of the visualization should be possible for the techniques investigated. Therefore the visualization modules include a parameter, which controls the complexity of the geometric representation of the result, e.g., the number of triangles.

This geometric representation parameter does not influence the numerical accuracy, which is used for the calculation of the results. It just forces the module to use a courser representation of the results than reported from the calculation.

   
Symmetry

Another concept of DynSys3D is the aim to increase the amount of software symmetry across different implementations of multiple developers. Symmetry in this context means that implementation should reflect certain macro structures, e.g., semantical relations (stream line $\leftrightarrow$ stream surface) or the modular concept.

The separation of principal components and the specification of the interfaces is a key design element, which leads to more symmetry. Additionally some principal decisions, e.g., the requirement of a parameter controlling the complexity of the geometric representation, were thought to lead to more symmetry throughout the system. The achievement of a high degree of symmetry is formulated as a design guideline which must be adhered to by the different developers.

mailto:helwig@cg.tuwien.ac.at.