While we consider deal.II quite useful in the present form, there are still many things that we would like to implement in future versions. Among these are the following topics:
More example programs:
There are still many aspects of the library that are not yet
covered by the example programs (in particular, on the list
of things are the function parser library,
and the FilteredMatrix
class, but many other aspects as well). This is certainly
something that should be improved, but is rather time
consuming (on the order of at least 4 weeks full time work
for WB when starting one of the more complicated programs
from scratch).
Another aspect is that the tutorial typically serves people as a starting point for their own program, and consequently it would be nice to have well-documented programs for different applications. For example, nonlinear equations, Stokes or Navier-Stokes flow, and electromagnetics come to mind.
In either case, if someone has a program that might be of interest to the community at large, we would be very interested in having a look at it. Please let us know!
As a point of reference, in addition to the programs already available, there are several that are currently in the pipeline: step-26 deals with generating boundaries from point clouds, step-28 solves a problem from nuclear engineering, step-30 shows anisotropic refinement, step-31 solves a thermally driven convection problem, and step-32 will solve a thermochemical convection problem.
Parallelization: The current model for running on distributed memory machines over MPI is that each processor holds the entire mesh and only the linear system is distributed using PETSc. The fact that each process holds the entire mesh and DoFHandler clearly is a limiting factor. We have a number of ideas on having a truly distributed architecture, but much implementation will be necessary to make this work.
Parallelization via OpenMP: Another strategy for
parallelization we want to explore is to use OpenMP to more
effectively exploit today's multi-processor multi-core systems. It
should be relatively straightforward to apply OpenMP parallelization
to the linear algebra classes in the /lac
subdirectory. Many loops over all cells can also be parallelized (and
many are, in fact, using threads) but OpenMP isn't very good currently
for loops whose counters are not built-in data types and more thought
is consequently required.
PETSc vs. Trilinos: Currently, we support PETSc as an external linear algebra library since it is widely used and allows us to run in parallel. However, PETSc sucks in some respects (put mildly with our usual restraint) mainly because (i) its installation is complicated, (ii) the result is an installation with an unpredictable number of shared and/or static libraries in unpredictable directories and having unpredictable names, and (iii) because PETSc changes interfaces with every dot release, adding and removing function names or simply changing their arguments in incompatible ways. As a consequence, there are times when half of the mails on our mailing list are about installation problems with PETSc. This situation doesn't reflect well on anyone and makes us unhappy.
Being somewhat disenchanted with PETSc, one option would be to write interfaces to Trilinos, a competitor project to PETSc developed at Sandia National Labs. It is written in C++ right away and appears to have a different approach to compatibility and similar aspects. Its feature set is similar to PETSc, so it may be worth having interfaces to it and seeing whether it is a better alternative. Given that we already have the PETSc wrappers that define all the classes and functions we will need for the moment, writing such an interface should not be a huge task, maybe on the order of 2-4 weeks of work.
Multigrid: We are working on an implementation of multigrid methods for deal.II. While this is running on globally refined grids, we are still having problems on locally refined meshes. For those, multigrid is only applicable with DG methods yet.
A better testsuite: We have a
suite of programs (approximately 1350 programs with roughly
155,000 lines of code at present) that are run automatically
for regression tests each night. Some of these are modified real-life
applications, so they should cover a relevant part of the
library, and some others test certain parts of the library
extensively, but it would be necessary to reach every corner of
the library to be sure a certain patch does not break
something. Also, a complete test-suite for the library would
be quite valuable for ports to new computer systems and
compilers. A possible approach to cover a more complete fraction of
the library with the testsuite would be the use of gcov,
a coverage tool that is distributed with gcc.
Documentation: Printing the documentation is probably not what one would usually do anyway, due to the sheer size. However, it might be useful to print, for instance, the example programs. There might be more information worth printing in some cases which I presently can't think about.
For these cases, it would be interesting to have them in another format than HTML. We think that DocBook SGML would be a good choice, since it can be converted into many other formats, including printable ones and ones which can be nicely displayed on the screen. This would require that some document-generating scripts produce SGML instead of (or in addition to) HTML, and some other tweaks, but is probably no big deal. It just needs someone with appropriate knowledge.
Installation: Some parts of the configure machinery and the installation process are not as simple as they should be. This should eventually be made better. The most outstanding example is the way we build shared libraries; for this, the libtool utility may be a useful. Help in the configuration of these things would be greatly appreciated.
Single-file build:
If one simply copies all the .cc files into a
single file, the library can be compiled into only one single
object file. It is large, for sure, about 80MB in debug mode,
and it takes a lot of memory (2.3 GB with gcc4.1) but it
might also give the compiler a number of optimization
opportunities that it would not have otherwise. Doing
experiments on how much faster programs are this way
would be very interesting.
We believe in an open development model and would like to encourage everyone to send us patches and extensions they have. We think that a cooperative effort can improve the library much more than a limited and closed circle of developers ever can. We are therefore eager to review contributions by others for inclusion into the library and to help in their development. Please feel free to contact us in such cases!