Frequently asked questions

A list of FAQs which didn't find their way into this list can be found in the Bug Tracking System.

General

How should I cite DUNE?

If you are using the dune-grid module, please cite the following publications. If you used the dune-istl module for solving your linear equation systems, please cite at least the first of the following publications. If you performed parallel computation, please cite both of the following publications.

Installation/Compilation

How do I start my own project?

First you have to get DUNE itself. This is explained in the installation notes. Then use the Dune project generator to create a simple application framework. This is done by going to where you want your application to be, and typing

   dune-common/bin/duneproject
The program will ask you for a project name, an initial version number and a maintainer's email. Supply all this and you get a new directory named after your project. In the directory you will find a sample .cc-file, the necessary AutoTools infrastructure and a README which tells you how to proceed from there.

configure fails if no f77 compiler is found.

If there is no fortran compiler installed, configure should work. If this is not the case, please reopen bug #185.

Problems occur, if there is a fortran compiler installed but it does not match the C-compiler you are using (e.g. icc together with g77), because the tests try to link fortran from C, which cannot work.

A workaround (and crude hack) is to set F77=true. In this case the test sees that it cannot compile any fortran code and just warns about it.

What Software do I need to use DUNE?

In order to build Dune you need at least the following software:

When building the development version of Dune you will also need

This will provide you with the core Dune features. The different grid managers like Alberta or UG have to be downloaded separately.

Why do I get so many warning about violated strict-aliasing?

Dune violates strict-aliasing.

You have to compile Dune will the the option "-fno-strict-aliasing". Newer versions of g++ make more use of strict aliasing rules. If you don't use the "-fno-strict-aliasing" option, you will receive many warnings, and you might even observe undesired results and unreproducible errors.

But we are not alone with this problem. Several software projects intentionally violate strict-aliasing. For example, Python 2.x did so to implement reference counting ( http://mail.python.org/pipermail/python-dev/2003-July/036898.html). The Linux kernel does this because strict aliasing causes problems with optimization of inlined code ( http://lkml.org/lkml/2003/2/26/158).

For more information see Flyspray task #674

How do I set my favourite compiler options with this fancy build-system?

You can find information about this in the build system documentation

Can I use DUNE on a Windows System?

All DUNE development is currently done on Unix-like machines. We have received one report of a successful installation on Windows using Cygwin, though.

Why are the wrong libs used on my multilib architecture system (e.g. x86_64)

Some architectures are designed, such that either 64bit or 32bit libraries can be used. The most wide spread systems are x86_64 systems, like AMD Opteron or Intel Core 2. Obviously, the program has to be compiled either as a 64bit or a 32bit binary.

If you are using libtool in version < 2, libtool can not handle different architectures. In case you have 32bit and 64bit libs installed on your system, it may happen that libtool mixes 32bit and 64bit libraries.

You can upgrade to libtool 2.x. This should fix your problems.

How do I use the make headercheck feature?

make headercheck compiles all headers in your modules separately and thus checks whether they include all headers they need. There are two options to 'make headercheck':

The default behaviour is SILENT=(HEADER == "").

An example usages would be

  1. make SILENT=0 headercheck
  2. make SILENT=1 headercheck
  3. make SILENT=0 HEADER=common/fvector.hh headercheck
  4. make SILENT=1 HEADER=common/fvector.hh headercheck
  5. make HEADER=common/fvector.hh

Example 1 behaves exactly like 'make headercheck' and example 4 behaves exactly like example 5.

Another interesting feature is to use make's ability to ignore errors. A good start for the headercheck is this:

make -is headercheck

This way, all files are checked and you can see which ones have errors. Then, you can use

make -is HEADER=headerfile headercheck

to find out what is actually wrong.

If you prefer the headercheck to stop at the first error and give output, you might consider

make -s SILENT=0 headercheck

The Grid interface

Does a Grid Implementation Have to Provide Entities of all Codimensions?

The DUNE grid interface contains methods for access to grid entities of all codimensions. However, for some entities such as faces and edges in a 3d grid, this is sometimes difficult to implement. Also, most PDE codes will not need them anyways. Therefore, currently grid implementations are only required to provide vertices and elements. All others are optional. Please refer to the documentation for the individual grids to see what codimensions they implement.

Lagrangian finite elements of order higher than one have degrees of freedom on edges and faces. In order to implement them you don't need the actual entities, just getting their indices is enough. Therefore, the method subIndex<codim>() of IndexSet is required to be implemented for all codimensions.

Is There a Way to Organize a Grid in Separate Subdomains?

Some grid managers assign a domain id to each element. Using this id the grid can be viewed as consisting of several subdomains. Each subdomain can then, for example, have different material properties. Currently the DUNE grid interface does not contain this concept. There has been discussion about including it but so far nothing happened.

One reason for this omission is that the functionality is not strictly necessary. An element's domain id is element data just like a piecewise constant FE function. You can maintain a vector with the element ids in your application and feed it to your problem assembler to let it choose your material parameters correctly.

How do I implement my own DUNE grid?

Unfortunately, so far there is no text on how to implement your own grid manager using the DUNE interface. There is some example code, though. Download the module dune-grid-dev-howto. There, you'll find the implementation of IdentityGrid, which does nothing more than wrap another DUNE grid. It therefore already contains all the boilerplate code that you will need. Copy & Paste this grid and add your own functionality!

Core Grid Implementations

Why does UGGrid run out of memory way before my physical memory is exhausted?

When working with UGGrid you may experience crashes with a message

   ERROR in low/heaps.c/GetFreelistMemory: not enough memory for 40 bytes.
   ERROR in low/heaps.c/GetFreelistMemory: not enough memory for 40 bytes.
   uggridtest: heaps.c:647: void* UG::GetFreelistMemory(UG::HEAP*, UG::INT): Assertion `0' failed.
even though you expect your machine to have sufficient main memory. The reason for this lies in the design of the UG grid manager. UG implements its own memory management. When creating a grid, a certain quantity of memory is allocated once, and used for all subsequent grid operations. If this quantity of memory is exhausted you get the error message above.

The default memory size is set to 500MB per grid. You can set it to other values by using the UGGrid constructor

   UGGrid (unsigned int heapSize=500);

Why does globalRefine() sometimes segfault for AlbertaGrid<3>?

This is a known issue with ALBERTA. The segfault you experience is a actually a stack overflow during the recursive bisection algorithm. When trying to refine an element, ALBERTA tries to use a prescribed refinement edge. It tries to refine all elements that share this edge (called a refinement patch) at the same time. But this edge need not be a refinement edge for the other elements in the patch. Therefore, ALBERTA tries to recursively refine such an element before refining the current patch. This way, one can run into cycles. While ALBERTA can ensure that the recursive bisection terminates in 2d, no such algorithm is known in 3d. One has to rely on heuristics to solve this problem. A simple idea is to select the longest edge for refinement on the macro grid. If this edge is unique, it makes the algorithm terminate in 2d. In 3d, this works unless an element is refined more that once. By default, the GridFactory for AlbertaGrid does not modify the grid. There are two reasons for this:

We can give you two hints, though:

Why does adapt() on ALUGrid sometimes lead to a failing assertion?

The ALUGrid library keeps track of open iterators. Since these become invalid during adaptation, ALUGrid asserts that no dangling iterators exist. This can be avoided using -DNDEBUG in the compile flags for the ALUGrid library (which is recommended in any case).

The Iterative Solver Template Library (ISTL)

I am getting weired segmentation faults using the parallel solvers with OpenMPI

Unfortunately there is a bug in OpenMPI (version < 1.3.2) that prevents ISTL from setting up the parallel distribution information correctly. Please either use a newer version of OpenMPI or try MPICH or LAM

Last Change: Jul 29 2010 13:33 by Markus Blatt