Product Review: Diffpack

I installed the software on my Red Hat 6.0 Dual Pentium-II system from the demo CD-ROM, which may be ordered directly from Numerical Objects at http://www.nobjects.com/. The instructions were complete and the installation process was as simple as running a script, setting two environment variables and making a one-character change in a Makefile to reflect the name of the compiler on my system. However, if you happen to have a version of egcs newer than 1.0.3 and no longer have 1.0.3 lying around, I have two words for you—forget it. Diffpack must have egcs 1.0.3, and if you have a newer version, there is no way to compile applications with it. I ended up NFS-mounting the diffpack distribution on an older computer I hadn't gotten around to upgrading, so that I could get the examples to compile. This is not Diffpack's fault, but a show-stopper nevertheless.

The CD contains over 50 demonstration applications which directly correlate with the book. The CD-ROM has very well-structured HTML documentation which explains each demo and extracts them from the CD via a link. Each example is structured exactly alike, with source code, a Makefile and a README that explain how to build and run the example. All examples have a “Verify” directory which contains input files for verification simulations. The examples are usually designed with some sort of progression in mind, walking the user through the various capabilities of Diffpack and the helper applications which accompany it. Some applications require the licensed version of the code to run, but the CD provides pre-built executables for some of these. You will also need Perl-Tk to run any of the graphical interfaces to diffpack applications. My Perl-Tk is not current enough, so I didn't have the pleasure.

After working through the installation and application compilation process, it is clear that Diffpack is exceptionally well-designed. Quite a bit of thought has gone into making the installation process work well on any supported platform. The software installs simply, but still gives the user complete control over how the installation is done. Want to change (supported) compilers? No problem. Want to use VTK for visualization? No problem. It takes a little reading to make these things happen, but it is usually as simple as altering an environmental variable or setting an option argument for make.

Diffpack is like a fractal pattern viewed from a distance: looks simple and is simple, and the closer you look, the more there is to see. Again, unless you are running Red Hat 5.2 or a similarly time-stamped Linux distribution, your efforts will most likely fail. The applications may compile, but will dump core because you have an older f2c library, for example. Though my efforts failed, Numerical Objects reported to me that users of the Red Hat 6.0 distribution have successfully run Diffpack, so don't lose heart if you already made the change. It will just involve a little more work. Once you have the correct installation base—watch out!

I compiled and and ran examples from each of the sample directories: fem, fdm, linalg and app. The examples cover everything from “Hello World” to the wave equation to coupled heat and momentum transfer. The first, Heat2, from the fem series, gave me chill bumps. It was a simple 2-D transient Fourier heat conduction problem. I compiled the application (make MODE=opt), ran it (./test4.sh), ran LaTeX on one of the output files, and saw a complete report of the simulation: input conditions, routines called, solution history and graphical results. The report was also generated in text and HTML format. The input file was about 20 lines long and set up the grid (rectilinear), boundary conditions and run controls. The shell script which managed the application contained two lines. The application code was only 350 lines of C++ and most of that was for managing a text menu system built into the application. A bare-bones application of this type would probably have required about 30 lines of code.

The true advantage shows up when you want to change something, like solvers. Change one line, recompile, and you are done. This package effectively removes the tedium from building numerical solvers and allows the numerical scientist to deal with the problem at hand: getting a solution or proving there isn't one.

Some time will have be spent with the documentation to understand how to build applications, but once done, I suspect there is little you cannot do with this package in the field of numerical modeling. The package follows the UNIX paradigm of making many small utilities which may be combined to create the result you want. For example, results are presentable in so many formats because of helper applications such as simres2gnuplot and several other simres2* applications. Freedom and extensibility appear to reign supreme.

Of course, with freedom comes responsibility and a learning curve. Diffpack provides C++ classes which may be used to build applications. The classes are very high level, so you can call things like “GridFE” or “ConjGradNonLin” to deal with finite element grids or a conjugate gradient solver, respectively. The example programs are a very instructive aid to developers who want to build applications with Diffpack. I would liken the experience to learning to use VTK. However, because I am a numerical modeler and not knowledgeable in C++ matters, I can't report on the difficulty of building an application. I can report that pre-built applications are relatively short, easy to read and understand. With the book to aid you, it should not be too hard to become proficient if you already understand numerical methods. Because the package was built with an object model, fine control of the high-level classes is possible through sub-classes.

As with most software, you don't realize its shortcomings until you are very heavily invested in it. I don't know if it is possible to exercise fine control on mesh topologies during a simulation or vary convergence criteria by node location, for example. Most numerical simulations packages invoke heuristic “tricks” to get the job done on difficult problems. The diffpack implementation appears to be quite pure, and it may be difficult to get away with some tricks that practitioners of the “art” are familiar with. On the other hand, because it is pure, it may be the first opportunity to solve many of the problems engineers have cheated on for years. Interface tracking comes to mind.

Diffpack appears to be a well-written, well-documented tool which does exactly what its own press suggests: “Closing the Gap”. Perhaps “filling” is a more appropriate term, because this stuff is as hard as it ever was, and the “gap” between understanding a physical phenomenon and finding a reliable computational solution is large. This tool makes the gap easier to span.