This is a short list of questions that are asked frequently on the deal.II mailing list, so we collect short answers for them here. If you have a question that is not answered here, it is probably a good idea to first browse through the mailing list archives first, as there many questions have already been discussed.
libXXX.DLL cannot
be found!
Even if people reading this list and especially people managing this list belong to the most able programmers in the universe (and a decent number of parallel universes), all of us need data to find errors. So, whatever went wrong, paste the error message into your email. If appropriate, add lines from the file producing the error.
deal.II can be compiled by a number of compilers without problems (see the section prerequisites in the readme file). If the ./configure script does not pick the right one, selecting another is simple, and described in an according section in the readme file.
You can't, this version of gcc simply does not work with deal.II, or at least did not. deal.II version 4.0 will contain fixes to allow compilation, but versions up to and including 3.4 cannot be compiled with gcc 2.96. Furthermore, later versions don't support this compiler any more at all, and will tell you so during configuration.
gcc 2.96 was created by RedHat from a snapshot somewhere between 2.95 and 3.0; it contained a large number of compiler bugs, which have partly been fixed, but too many remain as that we were able to make the library work with this compiler until we could get hold of such a system (initially, the main development of deal.II was done in Germany, which is SuSE country, not Red Hat). Also note that version 2.96 is not an officially released version of gcc. Simply use either gcc 2.95 or 3.X. The reason we finally decided not to support this compiler is that we have reports that gcc 2.96 may miscompile parts of the library, see for example this message. We have also found that some of the example programs return wrong values or go into infinite loops if compiled with this version of gcc.
RedHat provides updates to gcc version 3.0 or later, and downgrades to gcc version 2.95, all of which work with deal.II. Red Hat releases starting with version 8.0 will also be based on a different compiler, so the problem does not exist there any more.
However, there are more problems lurking around the corner: even though we
have included patches so that the library can be compiled, presently not all
of the examples can. There is at least one problem in the compiler which we
could not work around (I reported this to the gcc bug tracking system as
c++/616 in October 2000, and it was fixed a few weeks later, but apparently
did not make it to Red Hat's version). The problem manifests itself in
situations like this:
Here, the compiler reports
template <int dim> struct Function {};
template <int dim> struct RHS : Function
which is clearly bogus since
x.cc: In function `void f () [with int dim = 1]':
x.cc:7: instantiated from here
x.cc:5: uninitialized const `rhs'
rhs uses the default constructor of
the class. Unfortunately, there is no way of working around the bug short of
removing the constness of the variable. We did not want to do this, since
this changes the semantics of the programs and is promoting bad style which
we do not want to do in example programs. Furthermore, since gcc 2.96 is
being phased out at the time of this writing, there is no point in doing this
any more. Therefore, we advise you to remove the constness of these variables
if you are forced to use this compiler and want to use the example programs,
or use them as the basis for your own
project. You can either do this by hand, or by using
this
patch that is archived in out mailing list
archives. A better way is probably to up- or downgrade your compiler, if
this is possible for your machine.
First the good news: yes, you can. Still, this answer needs to be more specific. The configuration program for deal.II expects a Unix-like environment. This is provided by the cygwin system. You should always use a current cygwin distribution A look into the mail archive might be advisable in case of difficulties. There is a small but growing community of deal.II users under cygwin.
Also note that on some installations of Cygwin, one of the system
header files used the proprocessor to define quad to
quad_t. Since deal.II uses the name
quad as a function name, the name is sometimes
replaced, sometimes not, depending on the order of include files and
whether the respective system header was included at all. This leads
to compilation errors.
Since the offending preprocessor define is only active when
_POSIX_SOURCE is not set, deal.II
releases after version 3.4 set this flag, to avoid the
problem, but releases up to and including version 3.4 may not
work. For more information, refer to the
mailing list
thread on this subject, and follow-up messages.
As long as a compiler is sufficiently standards conforming, and has
a command line interface, it may be used to compile the library. In
order to do so, the automatic configuration needs to recognize the
compiler, and be able to specify some flags, for example for
optimization. Presently, except for gcc and Intel C++, we do not
support any of the genuine Windows compilers, such as Visual C++, or
Borland C++. However, if you want to add support for them, just look
at how this is done in aclocal.m4 for the existing
compilers, and add support for the one you prefer. You may also want
to get into contact with us on the matter.
The Perl utility from Cygwin distribution (up to version 5.6.1-2)
contains a bug that causes a "permission denied" error with in-place
editing (using the -pi switch). This bug prevents
building the online documentation from the source files. To solve
this problem there are two workarounds as described in an article on
the Cygnus
Solutions mailing list. First, one should specify an
explicit extension in all makefiles, i.e. replace all
-npi or -pi options with
-npi~ or -pi~ for example. Second, apply a
patch to the source code of the perl utility and recompile.
libXXX.DLL cannot
be found!
With Version 5.1.0, deal.II creates and uses shared
libraries (DLLs) under cygwin. These DLLs will be linked to your program
at run-time, which requires Windows to know where the DLLs are stored.
Windows looks for DLLs in the execution path of your program, in the
Windows system directories, and in every directory specified in the
PATH environment variable. To do this, type
export PATH=$PATH:/usr/local/lib/deal.II/lib
(or the place where you have installed deal.II, respectively) in the shell
prior to execution, or add this line to .bashrc or
.bash_profile.
To disable shared libraries, run ./configure --disable-shared
and compile deal.II again (with make all).
Yes. If you use the --with-multithreading
--enable-multithreading flags when you run ./configure
(see the README file), then the
library will be set up to use multiple threads for various tasks, and you
can also use multiple threads in your program. See the example programs
to see how to do the latter. On machines with more than one processor
(i.e. SMP machines), using this functionality makes a lot of sense and can
significantly accelerate a program.
By default, deal.II does not support operations on clusters of computers that communicate via MPI. However, it also doesn't prohibit you from doing so in your application programs (and there are a number of programs that actually do this), it just doesn't implement anything that actively uses MPI functionality.
On the other hand, newer versions of deal.II have interfaces to the PETSc library that implements a lot of functionality for distributed linear algebra, i.e. for operations on vectors and matrices that are distributed across a cluster of machines coupled via MPI. By using these wrapper classes for linear algebra, it is possible to implement programs that work on truly large problems by distributing computations. In addition, we have functions that call into METIS to generate partitionings of triangulations.
For questions how to set up deal.II to use PETSc and METIS, refer to the readme file.
No, you cannot do either. The basic data structures are too much tailored to quadrilaterals and hexahedra. Implementing other cells amounts to re-implementing nearly all grid and DoF classes from scratch. On the other hand, the restriction to quadrilaterals and hexahedra avoids a large number of run-time computations and makes the library as fast as it is.
The simple answer is: if it can be written as a PDE, then this is possible. The more complicated answer is: deal.II is not a problem-solving environment, it is a toolbox that supports you in solving a PDE by the method of finite elements. You will have to implement assembling matrices and right hand side vectors yourself, as well as nonlinear outer iterations, etc. However, you will not need to care about programming a triangulation class that can handle locally refined grids in one, two, and three dimensions, linear algebra classes, linear solvers, different finite element classes, etc.
To give only a very brief overview of what is possible, here is a list of the nontrivial problems that were treated by the programs that the main authors alone wrote to date:
To illustrate the complexity of the programs mentioned above we note that most of them include adaptive mesh refinement tailored to the efficient computation of specific quantities of physical interest and error estimation measured in terms of these quantities. This includes the solution of a so-called dual problems, that means e.g. for the wave equation the solution of a wave equation solved backward in time.
Problems other users of deal.II have solved include:
Probably, many other problem types are solved by the many users which we do not know of directly. If someone would like to have his project added to this page, just contact us.
There is no general rule on how to attack implementing a program to solve your particular problem. However, the way most often taken is to look at one of the example programs from the tutorial and modify it such that it solves your equation. This way, a number of problems can be solved at relatively small effort.
If your class of problem does not allow taking and modifying one of the examples programs, then you have to write something up yourself. The example programs may nevertheless be a good guide on how to program with deal.II.
Yes, you can, and it has been done numerous times with deal.II. However, we have a standard recommendation: consider such problems as systems of partial differential equations, where the individual components of the solution are the real and imaginary part of your unknown. The reason for this is that for complex-valued problems, the product <u,v> of two vectors is not the same as <v,u>, and it is very easy to get this wrong in many places. If you want to avoid these common traps, then the easiest way around is to split up you equation into two equations of real and imaginary part first, and then treat the resulting system as a system of real variables. This also makes the type of linear system clearer that you get after discretization, and tells you something about which solver may be adequate for it.
While there are a number of projects in which deal.II is used to write solvers for time-dependent problems, there is indeed no tutorial program showing this. The reason for this is two-fold: first, writing tutorial programs takes awfully long, on the order of at least one full work week, and a time-dependent program would likely be large and complex so may even take longer. These days, the main authors of the library unfortunately lack the time for projects of this size unless it would be directly related to one of their ongoing projects, and would therefore be a side-product of what they do anyway.
The second reason is that over time we have found out that there is not much common ground in time-dependent solvers: most of our time-dependent projects build on deal.II serve very different purposes, from research into error estimators to solving actual engineering problems. They may change the mesh between each successive step, once in a while, or never. They may use explicit or implicit time stepping schemes. Since they differ in so many aspects, there are only few aspects specific to their time-dependentness that can be moved to the library, and example programs would be very different depending on the purpose for which it was written. Furthermore, unlike most of the other tutorial programs, it may not serve as a template for your own project unless it happens to have the same objectives. It may therefore not be terribly useful to a lot of people.
That said, if someone has a nice program to contribute as an example program: we would be delighted to take it in!
deal.II is Open Source -- this not only implies that you as everyone else has access to the source codes, it also implies a certain development model: whoever would like to contribute to the further development is invited to do so!
This model follows a small number of simple rules. The first and basic one is that if you have something that might be of interest to others as well, you are invited to send it to the list for possible inclusion into the library and use by others as well. Such additions useful to others are, for example:
In general, once you start to use something you wrote for one project in a second project, this is something that would make up a good addition to the entire library!
If you consider providing some code for inclusing into the library, these are the simple rules of gaining reputation in the Open Source community:
In order to allow that a library remains a consistent piece of software, there are a number of administrative rules:
However, again: the basic rule is that if you think your addition is interesting to others, there most probably is a way to get it into the library!