Scripting Techniques for Scientific Computing

The best of all worlds
Code re-use
Mixed-language integration
Scripting interfaces
Graphical user interfaces
Moving graphics for teaching
Automatic generation of Diffpack code
The ultimiate presentation tool

Prof. Are Magnus Bruaset
Dr. Xing Cai
Morten Fagerland
Roger Hansen
Prof. Hans Petter Langtangen
Kent-Andre Mardal
Vetle Roeim

Python home page
SWIG home page

Combining the best of all worlds

The goal of our project on "Scripting Techniques for Scientific Computing" is to develop software techniques for combining "the best of all worlds", i.e., combining different tools and programming languages, when building scientific applications. As a simple example, one can think of using a C++ library for creating computational grids, a Fortran 77 library for solving a PDE, a C code for visualization, and the scripting language Python for gluing the other tools together in a high-level program, perhaps with an easy-to-use graphical interface.

Mixed-language programming is possible in Fortran, Java, and C-like languages, but the support for such programming is much stronger in a scripting language like Python, first of all because scripting languages were intially designed for being integrated with C. The clear syntax of Python means that the controling high-level script looks much like a Matlab-like interface tailored to your Fortran and C/C++ libraries. The script can be run as a stand-alone application or interactively (just as Matlab), or you can invoke it through a fully graphical user interface. Notice that interactivity means that you can almost trivially introduce computational steering into your applications.

Roughly speaking, the combination of Python, traditional number crunching languages, and existing computing and visualization software makes it possible, with quite limited efforts, to build a Matlab-like environment for your special set of numerical software. The alternative strategy of including your code in a system like Matlab is a much less straightforward process and gives you a much less flexible end product.

Code re-use

Experience during the 90s with using C++ for numerical computing has clearly shown that the resulting libraries and applications are significantly easier to extend, maintain, and re-use in new situations, compared to the traditional procedure-based programming style of Fortran and C. Object-oriented programming and generic (template) programming are two important techniques that contribute to such improvements of software development efficiency. Nevertheless, many research groups already have well-tested and optimized numerical codes, written in Fortran or C, and true code re-use would mean to integrate the pure computing parts of such codes with new developments in perhaps C++ or Java. Combining C++ and Fortran, or Java and C, quickly gives you a lot of frustrations (think of differences in representing even simple data structures such as strings!). Python offers the benefits of object-oriented and generic (template) programming, together with a syntax that is simpler and clearer than C++ and Java. In addition, there exists several tools which makes calling Fortran 77/90, C, C++, or Java code trivial, at least in principle. Hence, the idea is to write the managing code segments in Python, using efficient data structures and algorithms in new or old Fortran, C/C++, or Java code.

High-level tools for simplifying mixed-language integration

Even if the overall goal sounds attractive, and Python is a good starting point for mixed-language programming, it must be extremely easy to combine different languages if this is a technique that is going to be used widely. There are tools (SWIG, Pyfort, f2py) that automatically generate most of the necessary code for combining Python with Fortran and C/C++ code, but some disturbing details are often left for manual adjustment. This can be very annoying unless you have lots of experience with such language integrations. We therefore aim at building scripts on top of existing integration tools to streamline the integration process. One goal is to write Python code in one part of an editor window and simply jump to another part to write number crunching code in Fortran, C, or C++, often calling up your own libraries in those languages. With just pressing a button or running a simple one-line command, the Python script works with the external numerical code. (We remark that combining Python and Java is already made fully transparent by JPython.)

Scripting interfaces to existing libraries

Tools like SWIG and f2py make it possible to call functions and access data structures in C/C++ or Fortran 77/90 code directly from a Python script. In other words, you can almost automatically build a complete Python interface to existing C/C++ or Fortran libraries. This is ideal for prototyping and testing as there is no waiting time for compilation and linking when programming in Python. Hence, debugging or numerical experimentation is much faster than in a compiled language. Declarations of variables is not necessary in Python, making the code significantly simpler and more general than in C++ or Java (more like Matlab, Maple, or Mathematica). At the same time you have access to the full power of object-oriented and generic programming with complicated data structures. This means that you can use Python for structuring your Fortran or C codes. Collecting functions and data in Python classes is efficient from a numerical point of view as long as the heavy operations on your data structures are done in efficient C/C++ or Fortran code.

We intend to build Python interfaces to third-party code that we use, e.g., for grid generation. A Python interface to Diffpack is also under development, but this is, at least with the presently available integration tools, a more long-term task. When we say that Python interfaces can be build almost automatically, the word almost means in practice that the whole process is supposed to be automatic, but that strange things happen, which requires special tricks. Through the project we want to get experience with such problems and devise solutions.

Graphical user interfaces

Python is easily combined with various GUI software, like Tk, Qt, Gtk, MFC, and java.swing. Programming with Tk and Tk extensions (Pmw) from Python means that cross-platform GUIs can be generated with a minimum of code. In other words, if you already steer your scientific computing applications through Python scripts, adding a GUI on top is an efficient process that requires much less code than in C++ or Java. Python and most of its GUI tools are, of course, cross platform and run on Unix, Windows, and Mac.

An ongoing project is to build a graphical interface to the Vtk library for visualization of stationary and time-dependent scalar and vector fields in 2D and 3D. This graphical interface will hopefully offer "visual programming" of the type met in AVS and IRIS Explorer. Together with the Python and C++ interfaces to the Vtk data structures and algorithms, the resulting tool can indeed give you the best of all worlds:

  • complete programming control for automation and real-time visualization, or
  • user-friendly visual construction of visualization pipelines.

Moving graphics for teaching

Dynamic processes, either physical or algorithmic, can be effectively visualized using animation of figures, preferably with some interactive control through a graphical user interface. We want to explore the use of Python and Tk/Pmw for this purpose. With a proper set of software modules and documentation, we hope to offer tools that non-experts can use for efficiently creating dynamic, visual illustrations of topics met in teaching practice. That is, instead of drawing a couple of rough figures on the blackboard indicating some dynamic process you can develop a professional, interactive animation.

Automatic generation of Diffpack code

Although C++ programming with Diffpack is straightforward and often a matter of some manual editing of template codes, you still need to do some careful manual work. We intend to build interfaces, using scripting languages, that automatically generate a working Diffpack code from a mathematical specification of the PDEs to be solved. Further development and tuning can then be performed directly in the Diffpack code, but the proposed tool will get you started with a new application much more quickly, especially if you are a novice Diffpack programmer.

The ultimiate presentation tool

Microsoft PowerPoint is the state-of-the-art presentation tool today, but it has limited capabilities for mathematical formulas. This is a major disadvantage in our teaching where hundreds of slides with lots of mathematics need to be generated. Another drawback of PowerPoint is that the format is not in a simple ASCII form, which is a requirement for automatic text manipulation (through scripts) of large slide collections and filtering to other presentation formats. The Ultimate Presentation Tool, as we see it, would offer a GUI like PowerPoint, dynamic capabilities as found in PowerPoint, with LaTeX for mathematical writing, and direct coupling to visualization tools and simulation programs. All features must be accessed from an underlying, compact ASCII-based language. Straightforward text can be written directly in ASCII form while more complicated graphics can be edited with the GUI.

A first step towards this goal is the Tk::SlideShow module for Perl, which applies a Tk canvas for dynamic graphics and Perl for specifying the slide content. However, a script from a simpler, pure ASCII form to Perl code would be needed make generation of simple slides easier. The SDF document writing system, based on minimal tagging (in contrast to XML) and pure ASCII text, is a good starting point for the ASCII-based "slides language". Extending SDF to slides, combining it with LaTeX, applying ideas from Tk::SlideShow and using JPython as the programming environment could make it possible to realize our Ulitimate Presentation Tool as sketched. Since JPython automatically gives you the slides as Java applets, output on a Web page is trivial. The SDF-like text version of the slides makes it easy to create (static) output in LaTeX, MS Word, HTML, SGML, or FrameMaker.

The most recent update of this page was done May 5, 2000 by Hans Petter Langtangen