There must be considerable motivation for such a major release, motivation which comes from both our users, collaborators, and DBP partners but also from advances in software engineering and scientific computing, with which we must also keep pace. Our users continue to demand more efficiency, more flexibility in programming the workflows created with SCIRun, more support for big data, and more transparent access to large compute resources when simulations exceed the useful capacity of local resources. The evolution of software engineering has led to changes in computer languages, programming paradigms, visualization hardware and processing, user interface design (and tools to support this critical component), and the third party libraries that form the building blocks of complex scientific software. SCIRun 5 is a response to all these changing conditions and needs and also represents some long awaited refactoring that will provide greater flexibility and freedom as we move into the next generation of scientific computing.
Major elements of SCIRun that we have evaluated and revised or even replaced for the new version include the following:
- Overall architecture
- The graphics pipeline and scene graph
- Separation of software layers, e.g., algorithms from interface and GUI
- GUI language and standards • Script control of SCIRun and provenance
- Integration with third party libraries, e.g., MATLAB, LAPACK, ITK.
Visualization in SCIRun 5
One of the oldest and also most complex elements of SCIRun is the visualization support, what is known as the "graphics pipeline" that takes a wide range of data and interactively and flexibly displays the results. In response to new graphics software and hardware opportunities, we have developed a new rendering system for SCIRun5 which has technical advances and handles display of large meshes more efficiently and is more modular than the current SCIRun4 renderer. To improve rendering performance of meshes generated from SCIRun, we have shifted from storing the mesh geometry in system memory to storing the geometry on the GPU, as described in Figure 1. Once the meshes are in GPU memory, only a few function calls are needed to have the GPU recall the mesh data and render the mesh to the screen. This organization allows the GPU to operate at maximum speed since it is not bound by memory bandwidth and the CPU is free to perform other tasks unrelated to feeding the GPU.
Figure 1: Proposed meshing pipeline for conforming volumetric meshing. |
The new renderer in SCIRun5 is also very modular and thus should prove easier to maintain and extend. The core software for the renderer is being used in 3 separate applications and works on all major desktop platforms, in addition to Android and WebGL. The application layer in Figure 4.5 shows the different applications with which the SCIRun5 renderer has been used. The renderer is broken down into a number of different code modules (unrelated to the concept of a module in a SCIRun network) whose dependencies are clearly defined (CPM Managed Dependencies in Figure 2). Each of the modules are thoroughly tested using continuous integration (CI): when a modification is made to any module's source code, the changed module is automatically rebuilt from scratch and tested on a remote virtual machine. This testing is performed automatically on a code management system called "github". Linking these modules together into one program is also simple and straightforward using CPM, a program building manager that is based on the open source CMake system and that we have built specifically for this application. Using this build manager, we have been able to incorporate CPM modules built for SCIRun 5 into separate applications with only a few extra lines of code. This system of small, well tested and well versioned modules forms the foundation upon which the SCIRun5 renderer is constructed. All modules mentioned in the diagram, the renderer itself, and CPM are freely available on github under the MIT license.
Figure 2: Overall organization of elements of the graphics subsystem. |