447.dealII
Numerical Solution of Partial Differential Equations using the Adaptive Finite Element Method
Wolfgang Bangerth - Started the original design and coding of deal.II in early 1998; principal author and maintainer of the library; author of the testcase based on the library and used for SPEC
Guido Kanschat & Ralf Hartmann: - Joined the project in 1999, co-maintainers and co-authors of the library
Other contributors are cited on The deal.II Homepage (http://www.dealii.org/)
The SPEC CPU2006 benchmark 447.dealII is a program that uses deal.II, a C++ program library targeted at adaptive finite elements and error estimation. The library uses state-of-the-art programming techniques of the C++ programming language, including the Boost library. It offers a modern interface to the complex data structures and algorithms required for adaptivity and enables use of a variety of finite elements in one, two, and three space dimensions, as well as time-dependent problems.
The main aim of deal.II is to enable development of modern finite element algorithms, using among other aspects sophisticated error estimators and adaptive meshes. Writing such programs is a non-trivial task, and successful programs tend to become very large and complex.
Therefore, the deal.II library provides the application programmer with grid handling and refinement, handling of degrees of freedom, input of meshes and output of results in graphics formats, and the like. Also, support for several space dimensions at once is included in a way that allows programs to be independent of the space dimension, without unreasonable penalties on run-time and memory consumption.
The testcase for the benchmark version, 447.dealII, solves an equation (a Helmholtz-type equation with non-constant coefficients) that is at the heart of solvers for a wide variety of applications. For example, solvers for incompressible fluid flow, static or time-harmonic electromagnetics, static and quasi-static elasto-plasticity, general relativity, and implicit time stepping schemes for seismic, acoustic, and electromagnetic applications spend most of their computing time solving one form or other of this equation. The code uses modern adaptive methods based on duality weighted error estimates to generate optimal meshes. The equation is solved in 3d.
Except for the number of refinement steps, the input is generated by code in the benchmark.
While the lack of an input file seems odd at first, this is a typical approach in many finite element applications. The reason is that many operations cannot be implemented efficiently when data has to be read in from a file. In contrast to more "traditional" approaches, adaptive codes change the mesh in each step; consequently, it is not sufficient to specify data such as the values of coefficients, or the geometry only in a fixed number of integration points, but a functional description is required. Instead of implementing a parser and interpreter for general functions, this is often implemented in small pieces of code that are then linked into the application. In 447.dealII, this happens in the step-14.cc file, in which not only the general framework of the application, but also coefficients are defined (see classes LaplaceCoefficient, MassCoefficient). The geometry of the domain as well as boundary values are selected in the Exercise_2_3 class.
An additional complication is posed by output functionals that extract quantities such as point values, integrated fluxes across the boundary, or (in aerospace applications) lift and drag coefficients. These functionals are, in general, so unique to the application that they cannot be specified in an input file but need actual code. For the SPEC benchmark, we require the evaluation of the solution at a given point; this is implemented in the PointValueEvaluation class in step-14.cc.
The output describes the problem state at each refinement step. To reduce the amount of output, the benchmark downsamples the solution to a coarser grid. It writes the output to two types of files: solution-*.gmv contains the primal and dual solution as well as error indicators. These files can be viewed by the General Mesh Viewer ("gmv"), a non-commercial program for plotting graphical output. The three-dimensional, adaptively refined mesh is output to the grid-*.eps files and can be viewed with any PostScript viewer such as ghostview.
In addition, the program prints the number of the iteration, the number of degrees of freedom in this iteration, as well as the computed value for the point evaluation as well as an estimated error to stdout.
C++
Because deal.II uses state-of-the-art C++ programming techniques, a number of minor errors have been found in various compilers. There is also one major portability issue regarding an unspecified item in the C++ standard.
This issue was discussed in detail during the development of CPU2006 and it is described in some detail in the accompanying document 447.dealII_CPPStds.txt. In short, this problem can be summarized as follows: deal.II implements support for 1d, 2d, and 3d using a system of templates and explicit specializations. Since the benchmark only solves an equation in 3d, the 1d and 2d parts are not needed and are disabled. However, the code contains declarations of explicitly specialized function templates for 1d and 2d that lead some compilers to emit virtual function tables that reference functions for the 1d and 2d components (a behavior that is allowed, but not mandated by the C++ 2003 standard - see paragraph 9 of section 14.7.1). This leads to linker errors if these functions are not available with these compilers.
The solution to this is to compile the entire library not only for 3d, but also for 1d and 2d. This instantiates the relevant function templates for these space dimensions as well, satisfying the references in the vtables. The code compiled for 1d and 2d is never executed, however.
To compile the SPEC version with all three, add
explicit_dimensions = 1
to your config file. The default is to build only once. Compilers that experience linker errors when only compiling the 3d part should also compile the 1d and 2d parts, whereas compilers that don't need this would only compile for 3d. Since the 1d and 2d functions are never called, this does not create or inhibit optimization possibilities for either class of compilers. This is discussed in a bit more detail in the document 447.dealII_CPPStds.txt.
In addition to this, not all compilers implement the C++ standard correctly in some respects. In order to provide a single source code, deal.II has a config.h file that stores preprocessor defines indicating the problems and capabilities of compilers. Almost all of these defines are used to work around problems with the exact syntax understood by compilers, in particular with respect to declaring class templates as friends of other classes. In only one place is a part affected that actually generates code (i.e. statements, rather than just declarations). The use of the defines in config.h was examined during the development of CPU2006. Part of that discussion may be found in the accompanying document 447.dealII_Config.txt. However, that document should be viewed as an intermediate working document. The handling of most of the macros in config.h changed before release of CPU2006.
New with CPU2006 V1.1:
Last updated: $Date: 2008-04-12 08:31:17 -0400 (Sat, 12 Apr 2008) $