From c5678555ec34b7ace3e35747e1181a31dccd7698 Mon Sep 17 00:00:00 2001
From: bangerth
- 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.
-
- 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.
-
- Let's put it this way: the configuration of PETSc is really
- non-trivial, and it isn't made much easier by the
- documentation (or lack thereof) that the library's developers
- provide and the constant incompatible changes they make to
- everything. We've got the interface to PETSc working pretty well on
- many platforms, but there are cases where PETSc requires linking
- with other libraries that the deal.II Makefiles are unaware of.
-
- If you get linker errors about undefined symbols, try to figure out
- which library these functions reside in. If you can't manage to get
- this going yourself, feel free to send email to the mailing list.
-
- In general, try to get things going first by configuring PETSc with
- options This is probably due to the introduction of the new GNU FORTRAN
- Compiler gfortran. If those libraries were compiled with
- gfortran and you have the old g77 installed, then
- the library -lgfortran is missing. Or vice versa
- -lg2c might be missing. Check config.log for the
- test for BLAS to see if it complains about missing symbols
- indicating such a thing. If so, install the missing compiler.
-
- 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 try to use a current cygwin distribution.
- A look at the mail
- archive might be advisable in case of difficulties.
-
- Also note that on some installations of Cygwin, one of the system
- header files used the proprocessor to define
- Since the offending preprocessor define is only active when
-
- 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
- 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
- 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
-
-
- (or the place where you have installed deal.II, respectively) in the shell
- prior to execution, or add this line to
- Yes, at least on the more modern OS X operating systems this works
- just fine, as long as the developer tools like the GCC compiler,
- PERL, etc are installed. The only issue we are currently aware of is
- that if deal.II is configured to interface with
- PETSc, then PETSc needs to be configured with the
-
- Yes. If you use the
- 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 can't. 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 as evidenced by the many publications in widely disparate
- fields obtained with the help of deal.II. 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:
- The deal.II FAQ
-
-
-
-
-
-
-libXXX.DLL
cannot
- be found!
-
-
--with-shared=0 --with-mpi=0
- --with-clanguage=C++
and then configuring
- deal.II with the option
- --disable-shared
.
- 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.
- _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.
- Other Windows compilers
- 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.
- -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!
- PATH
environment variable. To do this, type
- export PATH=$PATH:/usr/local/lib/deal.II/lib
- .bashrc
or
- .bash_profile
.
- To disable shared libraries, run ./configure --disable-shared
- and compile deal.II again (with make all
).
- --with-x=0
flag to prevent linking in the X11 libraries
- (you probably won't need them anyway).
- --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.
-
-
-
- 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: -
- Some images from these applications can be found on the - deal.II Wiki. - 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. -
- -- 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! -
-
README
A fairly complete C++ compiler. We usually use
- gcc3.x but also some
- others. Various working compilers
- are listed above. egcs1.x and older gcc versions will not
- work, however. For gcc 2.96, see the Frequently Asked Questions. Also, Sun
- Workshop C++ 5.0 will not work since it does not support
- template member functions, Sun Forte C++ 5.5 will not work since it
- does not understand a number of other advanced template features,
- and IBM C Set++ 3.0 will not
- work since they only have non-ISO header file names (with
- appended .h. Version 5.0 does not work since they do not
- allow the declaration of explicit specializations and a
- larger number of other techniques that are used in the
- library, see the link in the list above. The SGI MIPSpro
+ gcc3.x or
+ 4.x but also some others. Various working compilers
+ are listed above. We do not support gcc versions older than
+ 3.2 any more at this time. Except for the most recent versions, Sun
+ Workshop C++ and Sun Forte C++ will not work since they only
+ supports a limited subset of C++. The most recent versions of
+ IBM C Set++ should work. The SGI MIPSpro
compiler 7.3 or earlier will not work since it is not C++
standard conforming. The MIPSpro compiler 7.4 will also not
work since it is still too buggy.
- Note that we have supported egcs 1.1.x in previous releases
- of the library (up to deal.II 3.0.x),
- but due to some missing feature in the support of Standard
- C++, we now only support later versions of gcc for releases
- of deal.II after version 3.0.x. Beyond
- that, we frequently compile deal.II with
- newer gcc snapshots, to ensure that the library will
- compile with upcoming releases.
-
We are interested in writing portable C++, so if you find
something that does not work with your compiler, we are
@@ -941,7 +923,7 @@
the library may be found on the
homepage of
deal.II, or in the
- Frequently Asked Questions section.
+ Frequently Asked Questions section.
If you don't find anything there,
feel free to ask if you have any problems with deal.II. If a
question is of general interest, you may want to use our mailing list,
--
2.39.5
- FAQ
+ FAQ
News
Download