dealii / dealii

The development repository for the deal.II finite element library.

What is deal.II?

deal.II is a C++ program library targeted at the computational solution of partial differential equations using adaptive finite elements. It uses state-of-the-art programming techniques to offer you a modern interface to the complex data structures and algorithms required.

For the impatient:

Let's say you've unpacked the .tar.gz file into a directory /path/to/dealii/sources. Then configure, compile, and install the deal.II library with:

$ mkdir build
$ cd build
$ cmake -DCMAKE_INSTALL_PREFIX=/path/where/dealii/should/be/installed/to /path/to/dealii/sources
$ make install    (alternatively $ make -j<N> install)
$ make test

To build from the repository, execute the following commands first:

$ git clone https://github.com/dealii/dealii
$ cd dealii

Then continue as before.

A detailed ReadME can be found at ./doc/readme.html, ./doc/users/cmake_user.html, or at https://www.dealii.org/.

Getting started:

The tutorial steps are located under examples/ of the installation. Information about the tutorial steps can be found at ./doc/doxygen/tutorial/index.html or at https://www.dealii.org/.

deal.II includes support for pretty-printing deal.II objects inside GDB. See contrib/utilities/dotgdbinit.py or the new documentation page (under 'information for users') for instructions on how to set this up.

License:

Please see the file ./LICENSE.md for details

Further information:

For further information have a look at ./doc/index.html or at https://www.dealii.org.

Docker Images:

Docker images based on the Ubuntu operating system are available on Docker Hub. You can use any of the available version (list of available tags) by running, for example:

$ docker run --rm -t -i dealii/dealii:master-focal

The above command would drop you into an isolated environment, in which you will find the latest version of deal.II (master development branch) installed under /usr/local.

dealii's Issues

Configure Travis CI

The .travis.yml file is present, but Travis CI was not configured to fetch this information from github. One of the administrators of the repository should do this, if we want to test pull merges "on the fly".

L

Build failures introduced with commit 6a36497 and commit bfe1138

Luca, we miss some instantiations [1].

Reminds me that I plan to change the regression tester such that it can also test pull requests on demand and posts the results onto the pull-request...

[1] http://cdash.kyomu.43-1.org/viewTest.php?onlyfailed&buildid=11062

Improve inverse mapping approaches

From [email protected] on February 19, 2014 04:45:39

We have a number of places where we compute the inverse of the mapping F(hat x)=x for a point x in real space, finding the reference coordinates hat x. One of the places is the function that returns whether a point is inside a cell.

We do this in a sort of ad-hoc way that occasionally fails. We should take a look at Damien Lebrun-Grandie's PhD thesis (Texas A&M University, 2014) for some ideas to implement. In particular, I like the rotated bounding box (section 6.2.3) and the good initial guess (section 6.2.2) for the inversion.

This may make for a simple project for a starting student, if anyone wants to get a student started.

Original issue: http://code.google.com/p/dealii/issues/detail?id=186

Use lower_bound more intelligently

From [email protected] on April 02, 2013 22:31:42

There are a bunch of places in the library where we use std::lower_bound or Utilities::lower_bound to find the place to insert or lookup an element into a sorted array. Importantly, some of these places actually look up or insert several elements and in this case we can optimize things a bit. For example, if we have that

p = lower_bound (x.begin(), x.end(), values[i]);

then we could compute the place to insert values[i+1] using the same statement, or we could improve things by doing something like

if (values[i+1] > values[i])

    p = lower_bound (p, x.end(), values[i+1]);

else

    p = lower_bound (x.begin(), p, values[i+1]);

This should on average save one bisection step which may be relevant if the arrays we store into/lookup in are relatively small.

Original issue: http://code.google.com/p/dealii/issues/detail?id=25

Poor performance for constructor of FE_Nedelec in 3D.

From [email protected] on June 30, 2014 14:04:03

For order 4 and above the time to call the constructor is taking 1000 seconds or more. I didn't bother to go past order 5.

E.g. running this code on my imac desktop (OSX 10.9.3)

int main ()
{
const unsigned int dim=3;
Timer timer;
for (unsigned int k=0;k<6;k++)
{
timer.start ();
FE_Nedelec fe(k);
timer.stop ();
std::cout << "Order " << k << std::endl;
std::cout << "DoFs per cell: " << fe.n_dofs_per_cell() << std::endl;
std::cout << "Time: " << timer() << "s" << std::endl;
timer.reset();
}
return 0;
}

I get:
Order 0
DoFs per cell: 12
Time: 0.002656s
Order 1
DoFs per cell: 54
Time: 0.414289s
Order 2
DoFs per cell: 144
Time: 6.07334s
Order 3
DoFs per cell: 300
Time: 68.2726s
Order 4
DoFs per cell: 540
Time: 1346.91s
Order 5
DoFs per cell: 882
Time: 16012s

I see similar performance on my linux installation, both using up-to-date versions from the svn.

Can this performance be improved? - I am planning on using orders up to 6 or 8, but these run times will be a problem.

Thanks

Original issue: http://code.google.com/p/dealii/issues/detail?id=227

Missing implementations/instantiations of some Finite Elements in codimension codes

Some Finite Elements (like FE_Q_Hierarchical or FE_DGP_NonParametric) either have missing instantiations for codimension one and two, or they have incomplete implementations, making their use impossible in codimension != 0.

parallel::distributed::Triangulation should be able to transfer vertex data

From [email protected] on May 16, 2014 17:30:30

For problems where we move around vertices, it is currently complicated to use distributed triangulations because the vertex locations are lost upon rebalancing. ASPECT current implements a scheme for free surfaces that we should migrate into deal.II proper.

Original issue: http://code.google.com/p/dealii/issues/detail?id=216

Incorrect behaviour of FE_Nedelec::interpolate

From [email protected] on July 05, 2014 00:20:34

It seems that FE_Nedelec::interpolate does not work correctly for high orders. I have replicated the interpolate_rt.cc test in the attached file and the output it gives is:

FE_Nedelec<3>(0) 12 vector 1.66533e-16 Vector 1.66533e-16
FE_Nedelec<3>(1) 56 vector 2.77556e-17 Vector 2.77556e-17
FE_Nedelec<3>(2) 117 vector 0.128996 Vector 0.177798
FE_Nedelec<3>(3) 208 vector 0.241009 Vector 0.32687

As far as I understand this indicates that for high-order elements something goes wrong, does not it?
Any idea what could that be?

Thank you,
Alexander

Attachment: interpolate_nedelec.cc

Original issue: http://code.google.com/p/dealii/issues/detail?id=231

Documentation bug

When compiling off source, if DEAL_II_COMPONENT_DOCUMENTATION=ON, at least with doxygen 1.6.1, we (@andreamola and I) get this error:

Warning: ignoring unsupported tag `PROJECT_LOGO           =' at line 6, file options.dox
Warning: ignoring unsupported tag `USE_MATHJAX            =' at line 113, file options.dox
Warning: ignoring unsupported tag `MATHJAX_RELPATH        =' at line 114, file options.dox
Warning: ignoring unsupported tag `MATHJAX_EXTENSIONS     =' at line 115, file options.dox
Warning: ignoring unsupported tag `HTML_COLORSTYLE_HUE    =' at line 116, file options.dox
Warning: ignoring unsupported tag `HTML_COLORSTYLE_SAT    =' at line 117, file options.dox
Warning: ignoring unsupported tag `HTML_EXTRA_STYLESHEET  =' at line 118, file options.dox
Warning: ignoring unsupported tag `SERVER_BASED_SEARCH    =' at line 217, file options.dox
Error: tag HTML_HEADER: header file `header.html' does not exist
make[3]: *** [doc/doxygen/header.html] Error 1
make[2]: *** [doc/doxygen/CMakeFiles/doxygen.dir/all] Error 2
make[1]: *** [CMakeFiles/documentation.dir/rule] Error 2
make: *** [documentation] Error 2

Bug in commit 23a290bff3516a3f7831f6ab39dd5f99562ce6ff ?

../source/grid/grid_tools.cc: In instantiation of 'void dealii::GridTools::distort_random(double, dealii::Triangulation<dim, spacedim>&, bool) [with int dim = 1; int spacedim = 1]':
source/grid/grid_tools.inst:1556:12: required from here
../source/grid/grid_tools.cc:758:9: error: 'class dealii::parallel::distributed::Triangulation<1, 1>' has no member named 'communicate_locally_moved_vertices'
../source/grid/grid_tools.cc:716:24: warning: unused variable 'n_vertices' [-Wunused-variable]
../source/grid/grid_tools.cc: In instantiation of 'void dealii::GridTools::distort_random(double, dealii::Triangulation<dim, spacedim>&, bool) [with int dim = 1; int spacedim = 2]':
source/grid/grid_tools.inst:1669:12: required from here
../source/grid/grid_tools.cc:758:9: error: 'class dealii::parallel::distributed::Triangulation<1, 2>' has no member named 'communicate_locally_moved_vertices'
../source/grid/grid_tools.cc:716:24: warning: unused variable 'n_vertices' [-Wunused-variable]
../source/grid/grid_tools.cc: In instantiation of 'void dealii::GridTools::distort_random(double, dealii::Triangulation<dim, spacedim>&, bool) [with int dim = 1; int spacedim = 3]':
source/grid/grid_tools.inst:1782:12: required from here
../source/grid/grid_tools.cc:758:9: error: 'class dealii::parallel::distributed::Triangulation<1, 3>' has no member named 'communicate_locally_moved_vertices'
../source/grid/grid_tools.cc:716:24: warning: unused variable 'n_vertices' [-Wunused-variable]
../source/grid/grid_tools.cc: In instantiation of 'void dealii::GridTools::distort_random(double, dealii::Triangulation<dim, spacedim>&, bool) [with int dim = 2; int spacedim = 2]':
source/grid/grid_tools.inst:2008:12: required from here
../source/grid/grid_tools.cc:758:9: error: 'class dealii::parallel::distributed::Triangulation<2, 2>' has no member named 'communicate_locally_moved_vertices'
../source/grid/grid_tools.cc:716:24: warning: unused variable 'n_vertices' [-Wunused-variable]
../source/grid/grid_tools.cc: In instantiation of 'void dealii::GridTools::distort_random(double, dealii::Triangulation<dim, spacedim>&, bool) [with int dim = 2; int spacedim = 3]':
source/grid/grid_tools.inst:2121:12: required from here
../source/grid/grid_tools.cc:758:9: error: 'class dealii::parallel::distributed::Triangulation<2, 3>' has no member named 'communicate_locally_moved_vertices'
../source/grid/grid_tools.cc:716:24: warning: unused variable 'n_vertices' [-Wunused-variable]
../source/grid/grid_tools.cc: In instantiation of 'void dealii::GridTools::distort_random(double, dealii::Triangulation<dim, spacedim>&, bool) [with int dim = 3; int spacedim = 3]':
source/grid/grid_tools.inst:2460:12: required from here
../source/grid/grid_tools.cc:758:9: error: 'class dealii::parallel::distributed::Triangulation<3, 3>' has no member named 'communicate_locally_moved_vertices'
../source/grid/grid_tools.cc:716:24: warning: unused variable 'n_vertices' [-Wunused-variable]

Continuous Integration - provide our own infrastructure

Well, it seems that around one third of the CI tests on travis fail due to quota - which renders the whole thing a bit questionable.

I think the only viable solution in the long run will be to have our own CI infrastructure. And setting up this basically boils down to use the github API to trigger a build and report back the result.

Does anyone have a good idea to achieve this?

• Shall we use Jenkins?
• Write it ourselves?

Have member functions in DoFHandler to compute cell colorization

From [email protected] on May 15, 2014 18:23:39

To support multithreading better, we should provide default ways to get colorized arrays of cells, like we use in the paper with Turcksin and Kronbichler.

Original issue: http://code.google.com/p/dealii/issues/detail?id=215

Port to netcdf-4.2*

Please note that netcdf-4.2* (and its C++ bindings) is currently unsupported by deal.II.

netcdf-4.2 has changed the C++ bindings and the header names significantly, so this will require some porting.

For the time being, please use netcdf-4.1* instead - or, even better, help with the porting to netcdf-4.2* :-)

Implement a way to get a cell based on a CellId

From [email protected] on August 15, 2014 08:00:05

As discussed in a recent thread on the mailing list, there is currently no way to get a cell iterator for a given CellId. This would be useful for parallel computations that attach data to cells and need to send it to other processors upon repartitioning.

My suspicion is that we'd need a function
Triangulation::get_cell (const CellId &) const;
or similar, and probably the same for the DoFHandlers.

Original issue: http://code.google.com/p/dealii/issues/detail?id=244

Fix poor attempt at thread safety

From [email protected] on August 22, 2014 14:29:52

FE_DGQ and FE_Nedelec use a scheme whereby they defer construction of embedding and/or restriction matrices until they are in fact needed. The guard code looks like this:

{
  // initialization upon first request
  if (this->prolongation[refinement_case-1][child].n() == 0)
    {
      Threads::Mutex::ScopedLock lock(this->mutex);

      // if matrix got updated while waiting for the lock
      if (this->prolongation[refinement_case-1][child].n() ==
          this->dofs_per_cell)
        return this->prolongation[refinement_case-1][child];
   ...
  this_nonconst.prolongation[refinement_case-1].swap(isotropic_matrices.back());
}

The problem with this code is that the swap operation is not atomic: the first or second "if" may see a matrix that already has its size set but not the content yet. Or, worse, that doesn't have the size set yet, but has the elements already -- in which case it will be recomputed and the first thread to use the matrix may see temporary values while the second one recomputes the matrices.

The only way out is storing a boolean for each matrix indicating whether it is computed already, testing the boolean at the beginning and setting it at the very end.

Original issue: http://code.google.com/p/dealii/issues/detail?id=248

PR #146 introduced a bug: non-mpi versions of deal.II no longer compile

See, for example:

http://cdash.kyomu.43-1.org/buildSummary.php?buildid=12565

@bangerth

add GridIn::parse_parameters, format detection

From timo.heister on May 15, 2013 10:05:14

It would be great to have GridIn::declare/parse_parameters. Additionally, the read() routine could guess the format from the file ending.

Original issue: http://code.google.com/p/dealii/issues/detail?id=56

Remove old external dependencies

Something we discussed briefly in Heidelberg: What about removing the external dependencies for mumps and netcdf?

• mumps should be fully available through our trilinos wrappers. Furthermore, our direct interface is not very elaborate (no thread safety, concurrent jobs, reinvocation...).
  • We only support netcdf up to version 4.1 - and only the TAU grid format.

Opinions?

Create a module discussing the various ways to assemble

From [email protected] on August 20, 2013 00:08:11

Link to it starting in step-3. The module should compare the ways to assemble using straight up code (step-3), WorkStream, MeshWorker

Original issue: http://code.google.com/p/dealii/issues/detail?id=87

Regulate the distribution of the active cells on each core with p4est

From [email protected] on August 22, 2013 21:16:04

If there would be the possibility to use hp-adaptive refinement in parallel with p4est, it would be more efficient to regulate the distribution of the number of the active cells on each core.
This is also useful for elastoplastic contact simulation, where the assembling of plastified cells is more expansive than for elastic cells.
There should be already a function in p4est which can be used for this purpose.

Best, Joerg

Original issue: http://code.google.com/p/dealii/issues/detail?id=99

Need (?) to check METIS integer size against our own

From [email protected] on May 05, 2014 05:04:41

METIS can use either 32- or 64-bit indices. This is determined at the top of metis.h which in 64-bit mode looks like this:

#define METIS_USE_LONGINDEX

#ifdef METIS_USE_LONGINDEX
#define IDXTYPEWIDTH 64
#else
#define IDXTYPEWIDTH 32
#endif

Do we need to worry about this? Should we make sure that the index type matches our own types::global_dof_index?

In practice, our code is safe one way or the other. We're also most probably not ever going to be in a situation where we call METIS functions with more than 2B cells/indices. I just ask this question because when we install PETSc and tell it --download-metis, then PETSc configures its sub-METIS with the same index size as PETSc. This leads to awkward situations with our testsuite, as in https://svn.dealii.org/trunk/tests/metis/metis_01a.cc where we can not reliably figure out which output we have to expect if the METIS we happen to use was not obtained from PETSc.

Original issue: http://code.google.com/p/dealii/issues/detail?id=211

fix step-18/19

From timo.heister on August 14, 2013 20:09:55

1. step 18 is somewhat out of date and should be updated. We can probably do parallel vtk output and remove step-19 (which is the file merger program).
2. I got the report that merged file output using step-19 is missing a few elements, when merging a parallel output with >1 CPU. Investigate that.
3. step-18 also crashes on my machine:
   Cycle 1:

---

An error occurred in line <806> of file </scratch/deal-trunk/deal.II/include/deal.II/grid/tria_objects.h> in function
unsigned int& dealii::internal::Triangulation::TriaObjects::user_index(unsigned int) [with G = dealii::internal::Triangulation::TriaObject<3>]
The violated condition was:
user_data_type == data_unknown || user_data_type == data_index
The name and call sequence of the exception was:
ExcPointerIndexClash()
Additional Information:
(none)

Stacktrace:

#0 /scratch/deal-trunk/installed/lib/libdeal_II.g.so.8.1.pre: dealii::internal::Triangulation::TriaObjectsdealii::internal::Triangulation::TriaObject<3 >::user_index(unsigned int)
#1 /scratch/deal-trunk/installed/lib/libdeal_II.g.so.8.1.pre: dealii::TriaAccessor<3, 3, 3>::user_index() const
#2 /scratch/deal-trunk/installed/lib/libdeal_II.g.so.8.1.pre:
#3 /scratch/deal-trunk/installed/lib/libdeal_II.g.so.8.1.pre: dealii::Triangulation<3, 3>::save_user_indices_hex(std::vector<unsigned int, std::allocator >&) const
#4 /scratch/deal-trunk/installed/lib/libdeal_II.g.so.8.1.pre: dealii::Triangulation<3, 3>::save_user_indices(std::vector<unsigned int, std::allocator >&) const
#5 /scratch/deal-trunk/installed/lib/libdeal_II.g.so.8.1.pre: void dealii::GridTools::get_face_connectivity_of_cells<3, 3>(dealii::Triangulation<3, 3> const&, dealii::SparsityPattern&)
#6 /scratch/deal-trunk/installed/lib/libdeal_II.g.so.8.1.pre: void dealii::GridTools::partition_triangulation<3, 3>(unsigned int, dealii::Triangulation<3, 3>&)
#7 ./step-18: Step18::TopLevel<3>::refine_initial_grid()
#8 ./step-18: Step18::TopLevel<3>::do_initial_timestep()
#9 ./step-18: Step18::TopLevel<3>::run()
#10 ./step-18: main

Original issue: http://code.google.com/p/dealii/issues/detail?id=80

Functions in GridGenerator need more documentation

From [email protected] on May 07, 2014 22:25:04

The functions in namespace GridGenerator should be more explicit about the fact that you need to apply a boundary object to the geometry so generated for it all to work when you actually refine the mesh.

Original issue: http://code.google.com/p/dealii/issues/detail?id=212

Inconsistent interface between Trilinos and PETSc wrappers

From [email protected] on March 15, 2014 03:32:44

Following a thread on the mailing list, we seem to have an inconsistent set of interfaces between PETSc and the other matrix types. We should deprecate the old functions and add the ones that make the interface consistent.

Following the relevant messages:
.................................................................

It looks like the order of the parameters is switched for Petsc matrices vs Trilinos ones. http://dealii.org/8.1.0/doxygen/deal.II/classTrilinosWrappers_1_1SparseMatrix.html#a791d1d6a8e7f78f32c276350ee44fa6c http://dealii.org/8.1.0/doxygen/deal.II/classPETScWrappers_1_1MatrixBase.html#a4ebcb9648709b8ccb058b72214b8fdb8 On Wednesday, March 5, 2014 10:14:29 PM UTC+1, Gennadiy Rishkin wrote:

Hi,

Doing:

system_matrix.add( theta*time_step, laplace_matrix );

works perfectly with Trilinos but with PETSc, it gives the error below:

/home/grishk/TEST/main.cc: In member function ‘void TestEquation<dim>::assemble_system()’:
/home/grishk/TEST/main.cc:463:53: error: no matching function for call to ‘dealii::PETScWrappers::MPI::SparseMatrix::add(double&, dealii::LinearAlgebraPETSc::MPI::SparseMatrix&)’
  system_matrix.add( theta*time_step, laplace_matrix );
                                                     ^
/home/grishk/TEST/main.cc:463:53: note: candidates are:
In file included from /home/grishk/dealII/include/deal.II/lac/petsc_parallel_sparse_matrix.h:25:0,
                 from /home/grishk/dealII/include/deal.II/lac/generic_linear_algebra.h:50,
                 from /home/grishk/TEST/main.cc:18:
/home/grishk/dealII/include/deal.II/lac/petsc_matrix_base.h:1653:3: note: void dealii::PETScWrappers::MatrixBase::add(dealii::PETScWrappers::MatrixBase::size_type, dealii::PETScWrappers::MatrixBase::size_type, PetscScalar)
   MatrixBase::add (const size_type   i,
   ^
/home/grishk/dealII/include/deal.II/lac/petsc_matrix_base.h:1653:3: note:   candidate expects 3 arguments, 2 provided
/home/grishk/dealII/include/deal.II/lac/petsc_matrix_base.h:1684:3: note: void dealii::PETScWrappers::MatrixBase::add(const std::vector<unsigned int>&, const dealii::FullMatrix<double>&, bool)
   MatrixBase::add (const std::vector<size_type>  &indices,
   ^
/home/grishk/dealII/include/deal.II/lac/petsc_matrix_base.h:1684:3: note:   no known conversion for argument 1 from ‘double’ to ‘const std::vector<unsigned int>&’
/home/grishk/dealII/include/deal.II/lac/petsc_matrix_base.h:1701:3: note: void dealii::PETScWrappers::MatrixBase::add(const std::vector<unsigned int>&, const std::vector<unsigned int>&, const dealii::FullMatrix<double>&, bool)
   MatrixBase::add (const std::vector<size_type>  &row_indices,
   ^
/home/grishk/dealII/include/deal.II/lac/petsc_matrix_base.h:1701:3: note:   candidate expects 4 arguments, 2 provided
/home/grishk/dealII/include/deal.II/lac/petsc_matrix_base.h:1720:3: note: void dealii::PETScWrappers::MatrixBase::add(dealii::PETScWrappers::MatrixBase::size_type, const std::vector<unsigned int>&, const std::vector<double>&, bool)
   MatrixBase::add (const size_type                 row,
   ^
/home/grishk/dealII/include/deal.II/lac/petsc_matrix_base.h:1720:3: note:   candidate expects 4 arguments, 2 provided
/home/grishk/dealII/include/deal.II/lac/petsc_matrix_base.h:1736:3: note: void dealii::PETScWrappers::MatrixBase::add(dealii::PETScWrappers::MatrixBase::size_type, dealii::PETScWrappers::MatrixBase::size_type, const size_type*, const PetscScalar*, bool, bool)
   MatrixBase::add (const size_type    row,
   ^
/home/grishk/dealII/include/deal.II/lac/petsc_matrix_base.h:1736:3: note:   candidate expects 6 arguments, 2 provided
/home/grishk/dealII/include/deal.II/lac/petsc_matrix_base.h:962:17: note: dealii::PETScWrappers::MatrixBase& dealii::PETScWrappers::MatrixBase::add(const dealii::PETScWrappers::MatrixBase&, PetscScalar)
     MatrixBase &add (const MatrixBase &other,
                 ^
/home/grishk/dealII/include/deal.II/lac/petsc_matrix_base.h:962:17: note:   no known conversion for argument 1 from ‘double’ to ‘const dealii::PETScWrappers::MatrixBase&’

Original issue: http://code.google.com/p/dealii/issues/detail?id=193

Document iterators at the place where they are typedef'ed

From [email protected] on April 09, 2014 12:46:51

I don't know why this took me 16 years to realize: People always have trouble figuring out which class actually implements the particular iterator they look at (rightfully so, the structure is complicated). There is even a report on just this issue.

What we should be doing is point to the concrete type each iterator represents at the place where they are typedef'ed in the Triangulation and DoFHandler classes.

I don't have the time right now but will get to it before the next release.

Original issue: http://code.google.com/p/dealii/issues/detail?id=198

Expand $Id$ in file headers

There are currently many files that have a $Id$ string at the top of the file, but don't have it expanded:

dealii> grep -r Id | grep '$Id$' | wc -l
3957

There do not appear any files where it currently is expanded. How do we switch this back on?

(Background: I regularly get patches from other people who only send me their most current version of a file. It is very useful to know the revision of the file from which they started so that I can just do a diff between that version and whatever I got sent.)

Non-convergence using higher order FE_Nedelec and Dirichlet BCs on cells with non-rectangular faces

From [email protected] on September 05, 2014 17:07:08

As mentioned on the user forum a few weeks ago, (see one of my later posts here https://groups.google.com/forum/#!topic/dealii/1g3YSUdPSGY ):

When using cells with non-rectangular faces, convergence is lost when using order > 0 for Nedelec elements and Dirichlet boundary conditions (enforcement of n x E = f using VectorTools::project_boundary_values_curl_conforming). The documentation suggests that parallelepiped-shaped elements should work.

I've attached a simple test case to demonstrate:

solving curl(curl(E)) + E = J

with E = (x, y, z), so J = E.

We should recover the exact solution for p=1.

usage is "./check_nedelec_parallelepiped_linear -p 1".

You can switch to Neumann conditions ( n x curl(E) = g, g = 0 in this case) by commenting out lines 464-477. Note I've not tested this thoroughly for inhomogeneous Neumann BCs.

Output for Neumann, p=1:
cycle cells dofs L2 Error H(curl) Error
0 1 54 2.86419857e-15 2.99094281e-15
1 8 300 9.59771518e-15 9.70149564e-15
2 64 1944 3.60714649e-14 3.62864291e-14

Output for Dirichlet, p=1:
cycle cells dofs L2 Error H(curl) Error
0 1 54 4.40403490e-01 9.41996832e-01
1 8 300 4.14205529e-01 1.39101296e+00
2 64 1944 3.97981036e-01 2.06131473e+00

Thanks.

Attachment: check_nedelec_parallelepiped_linear.cc

Original issue: http://code.google.com/p/dealii/issues/detail?id=253

Cannot link tutorial with static executable

From [email protected] on June 11, 2014 18:05:26

When compiling deal.II with -DDEAL_II_STATIC_EXECUTABLE=ON, I cannot link the tutorials.

I tried on different computers but none of them work and the errors are different on each machine :(

gcc 4.8.2 on Titan
/usr/bin/ld: warning: libsci_gnu_48_mp.so.3, needed by /opt/cray/tpsl/1.3.04/GNU/48/x86_64/lib/libsuperlu_gnu.so, may conflict with libsci_gnu_48_mp.so.4
/usr/bin/ld: dynamic STT_GNU_IFUNC symbol strcmp' with pointer equality in/opt/cray/xe-sysroot/4.2.34/usr/lib64/libc.a(strcmp.o)' can not be used when making an executable; recompile with -fPIE and relink with -pie

clang 3.4.1 with libstc++ 4.6
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.6/libstdc++.a(eh_globals.o): undefined reference to symbol '__tls_get_addr@@GLIBC_2.3'
/usr/bin/ld: note: '__tls_get_addr@@GLIBC_2.3' is defined in DSO /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 so try adding it to the linker command line
/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2: could not read symbols: Invalid operation
clang: error: linker command failed with exit code 1 (use -v to see invocation)

gcc 4.8.2 on Ubuntu 14.04:
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/libpthread.a(lowlevellock.o): In function __lll_lock_wait_private': /build/buildd/eglibc-2.19/nptl/../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:78: multiple definition of__lll_lock_wait_private'
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/libc.a(libc-lowlevellock.o):(.text+0x0): first defined here
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/libpthread.a(lowlevellock.o): In function __lll_unlock_wake_private': /build/buildd/eglibc-2.19/nptl/../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:328: multiple definition of__lll_unlock_wake_private'
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/libc.a(libc-lowlevellock.o):(.text+0x30): first defined here
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.8/libstdc++.a(eh_globals.o): undefined reference to symbol '__tls_get_addr@@GLIBC_2.3'
//lib/x86_64-linux-gnu/ld-linux-x86-64.so.2: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status

Original issue: http://code.google.com/p/dealii/issues/detail?id=222

More flexible FunctionMap with one ComponentMask per boundary indicator

From [email protected] on July 04, 2014 14:42:12

In my application I solve a system of equations with solution components u and v on a domain with boundaries A and B. I have Dirichlet values for u on the boundary A and Neumann boundaries on B. For v I have Dirichlet boundaries on both A and B.

deal.ii doesn't support this use case as the boundary related functions (e.g. VectorTools::interpolate_boundary_values() or MGConstrainedDoFs::initialize()) ask for one FunctionMap and one ComponentMask. This design implies that all components must share the same Dirichlet boundary.

(Sometimes the problem can be circumvented by calling the method in question multiple times, but this is a workaround and doesn't work for e.g. the MGConstrainedDoFs class.)

It would be great if the "boundary functions" would be able to work with objects which can store one ComponentMask per boundary indicator. Either by adding this functionality to the FunctionMap or, to not break existing code, by having e.g. a MaskedFunctionMap object.

Original issue: http://code.google.com/p/dealii/issues/detail?id=230

default numdiff behavior

We have several tests in which numdiff fails to recognize a number, because the output contains some unknown delimiters. For example:

DEAL::<0.250000 0.250000 0.00000> 
DEAL::<0.500000 0.250000 0.00000> 
DEAL::<0.250000 0.500000 0.00000> 
DEAL::<0.500000 0.500000 0.00000> 
DEAL::<0.250000 0.250000 0.250000> 
DEAL::<0.500000 0.250000 0.250000> 
DEAL::<0.250000 0.500000 0.250000> 
DEAL::<0.500000 0.500000 0.250000> 

or

DEAL::Cell 3.3048, face 2 n=0.00000 -1.00000 0.00000
DEAL::Cell 3.3051, face 1 n=0.707107 0.707107 0.00000
DEAL::Cell 3.3054, face 0 n=-0.894427 -0.447214 0.00000
DEAL::Cell 3.3056, face 5 n=0.00000 0.600000 0.800000
DEAL::Cell 3.3059, face 4 n=0.00000 -0.447214 -0.894427

We should at least add <,>,=,, to the list of separators/delimiters for numdiff. I tried looking this up, and I think that either of these two options could be used

-s, --separators=IFS
    Specify the set of characters to use as delimiters
    while splitting the input lines into fields
    (The default set of delimiters is space, tab and newline).
    If IFS is prefixed with 1: or 2: then use the given delimiter set
    only for the lines from the first or the second file respectively
-D, --delimiters=DELIMS
    Specify the set of strings to use as delimiters
    while splitting the input lines into fields
    (The default set of delimiters is space, tab and newline).
    If DELIMS is prefixed with 1: or 2: then use the given delimiter set
    only for the lines from the first or the second file respectively

Matthias, where is a sensible place to insert this?

L.

Replace all uses of std::auto_ptr

From [email protected] on December 25, 2012 16:26:11

std::auto_ptr has been deprecated in C++11 and we should replace it.

What we should use is unique_ptr. The problem is that we use either the C++11 facilities or the fallback BOOST classes (if the compiler doesn't support C++11 yet) and BOOST doesn't have unique_ptr -- it has scoped_ptr that offers the same functionality but with a different name so it's not trivial to do something like std_cxx1x::unique_ptr.

Original issue: http://code.google.com/p/dealii/issues/detail?id=3

Cleanup HTML and make it standard conforming

From dr.guido.kanschat on August 28, 2013 06:24:35

The html pages, documentation and homepage are to a large portion not standard conforming. Furthermore, they contain a lot of repetitive markup and text. In order to keep maintenance simple, this should be cleaned up.

Some items to observe are:

1. cannot contain block elements! http://docs.webplatform.org/wiki/html/elements/p 2.

    elements are a bit tricky. Therefore, the opening and closing tags should always be in the first column. Avoid formatting through indentation by hand (interferes with copy/paste) and use CSS instead
   

2. Unify document structure: title of the page in

   , sections in

   , subsections

   and so on.

3. Use
   for table of contents

Original issue: http://code.google.com/p/dealii/issues/detail?id=110

Do ConstraintMatrix::distribute() after SolutionTransfer::interpolate()

From [email protected] on June 22, 2014 04:35:22

From a recent mailing list discussion:

Is this correct? We have previously stored data on either the current cells
(if they remain the same or get refined) or their parent (if they will be
coarsened) and then we call set_dof_values_by_interpolation() on each of the
these cells after refinement. I do not think that this will ensure hanging
node constraints (imagine a mesh where all you do is coarsen away 4 cells --
the fine level cells will remain the same, but this may no longer satisfy
hanging node constraints). Or am I mistaken?

You are right. The hanging node constraints are not satisfied after coarsening.

I've documented this with the SolutionTransfer class now.

I think that the conservative solution is to always call constraints.distribute() on the transferred solution. This is what step-15 already does, for example (apparently some long time ago, someone thought of this issue). I think this should be added to steps 26, 28, 31, 32, 33, 42, 43. Ugh.

Original issue: http://code.google.com/p/dealii/issues/detail?id=224

Verify in multigrid that Triangulation is sufficiently smooth

From dr.guido.kanschat on August 22, 2013 18:28:58

Multigrid methods will not complain if limit_level_difference_at_vertices is not set, but they produce wrong results at least with H1-conforming elements.

One of the multigrid classes should check whether this smoothness is needed, and if so, throw an exception if the Triangulation does not conform.

Original issue: http://code.google.com/p/dealii/issues/detail?id=98

Change step-20 to use CompressedSparsityPattern

From [email protected] on August 07, 2013 13:28:11

step-20 still uses the direct way to compute the sparsity pattern. We've moved away from this, so do the same in step-20 as well.

Original issue: http://code.google.com/p/dealii/issues/detail?id=79

Extend DataOutBase to also accept 0-dimensional patches

From [email protected] on August 15, 2013 03:19:04

Aspect already does output of particles, and there's been discussion on the mailing list about outputting data at quadrature points. This could all easily be incorporated into DataOutBase if we allowed patches to store zero-dimensional data.

I'll eventually get around to this, but wanted to have this recorded.

Original issue: http://code.google.com/p/dealii/issues/detail?id=81

implement integrate_difference for div

From timo.heister on April 24, 2014 21:53:53

Computing divergence error is something VectorTools::integrate_difference() should handle.

Original issue: http://code.google.com/p/dealii/issues/detail?id=205

Dev documentation on web site needs to build from git

The scripts that automatically build the documentation periodically and put it up at
http://www.dealii.org/developer
still seem to get their information from the svn repo. They need to be converted to git to be up to date.

Get FE From Name: codimension 1 and 2 support

The FETools::get_fe_from_name and FiniteElement::get_name functions, currently assume that spacedim is always equal to dim. This should be fixed to reflect also spacedim.

Separation of Mesh topology and geometry

From dr.guido.kanschat on September 17, 2012 15:27:07

For handling of degrees of freedom and most of the structure of finite element data and code, the actual geometry of the mesh is irrelevant.

Therefore, it is suggested to create a class Mesh, which has a minimal comfortable interface to handle mesh topologies and create DoFHandler and similar structures, once the mesh is given.

The current Triangulation class could inherit from Mesh and have the actual functions that fill the mesh class. This way, topology and geometry can still be created by the same refinement functions, if so desired.

The classes of the library that would combine topology and geometry are FEValues and Mapping; in particular, the latter could be more flexible and allow for the exact representation of manifolds

Original issue: http://code.google.com/p/dealii/issues/detail?id=1

Migrate issues from google code?

There is a script that seems to do a decent job in migrating all issues from google code:

https://github.com/arthur-debert/google-code-issues-migrator

what do people think about this?

L.

step-53 doesn't install topography.txt.gz

@tamiko : step-53 has the topography.txt.gz file that needs to be installed. This is similar to step-5 that needs to install circle-grid.inp. However, while circle-grid.inp is installed, topography.txt.gz is not although the two CMakeLists.txt are identical. How do I achieve that topography.txt.gz is installed?

implement DataComponentInterpretation::ignore

From timo.heister on May 01, 2014 16:15:48

I want to be able to output only the components with DataOut that I am interested in and not all components in the DoFHandler. Using a postprocessor here is too complicated in my opinion.

Additionally, while paraview allows me to look at vectors and their individual components, this is much more difficult in visit (only using the calculator as far as i know). As a workaround I have to DataOut::add_data_vector() twice, once with component_is_scalar and once with component_is_part_of_vector. Sadly, this means I am required to output every component twice, even those that I don't care about. :-(

Original issue: http://code.google.com/p/dealii/issues/detail?id=210

Honor Manifold ID for cell refinements

I'm assigning this to me:

I want to proceed step by step, incorporating part of what is in my

manifold_id_review branch

into a new branch. The first step is simply to add the four methods

get_new_point_on_cell
get_new_point_on_hex
get_new_point
project_to_manifold

to Boundary<dim,spacedim>, and make all get_new_point_on_* by default call get_new_point, which in turns query project_to_manifold with the averaged point.

This sounds a little intricate, but it is a way to keep backward compatibility while starting with the new idea about manifolds (seen as collection of points with a metric), where by default the new point is created by averaging the surrounding points, and projecting back the result to the manifold.

Simple implementations can implement the

project_to_manifold

function, and everything should work out of the box. More complex implementations should implement

get_new_point

New implementations should not need to go behyond this.

Provide facilities to compute the most inclusive element in an hp::FECollection

From [email protected] on January 25, 2014 04:57:31

SolutionTransfer::prepare_for_coarsening_and_refinement has this lovely piece of code (or will at least soon):

      // take FE index from the child with most
      // degrees of freedom locally
      unsigned int most_general_child = 0;
      if (different_fe_on_children == true)
        for (unsigned int child=1; child<cell->n_children(); ++child)
          if (cell->child(child)->get_fe().dofs_per_cell >
              cell->child(most_general_child)->get_fe().dofs_per_cell)
            most_general_child = child;
      const unsigned int target_fe_index = 
           cell->child(most_general_child)->active_fe_index();

Comparing numbers of degrees of freedom is a really crude way to find out which element we can interpolate to from children that carry different FEs. We need to implement some functionality in hp::FECollection and the finite elements themselves that can provide this sort of information.

Original issue: http://code.google.com/p/dealii/issues/detail?id=177

write trilinos quick_test

From timo.heister on May 15, 2014 16:41:48

Trilinos ML is crashing for Ian on his machine.

1. Create a quicktest out of step-40 (Trilinos mode).
2. Ask Ian to make sure that the test fails on his machine.

Original issue: http://code.google.com/p/dealii/issues/detail?id=214

README, VERSION, etc.

Since github is capable of automatically (and nicely!) formatting markdown text, should we change the README, VERSION and LICENCE files to be properly formatted markdown? (i.e., adding md extension, and using indentation in a way that makes markdown see command prompts, code snippets, links, etc.)

L.

doxygen uses wrong style file

From [email protected] on July 14, 2014 02:54:51

I don't quite understand what is going on here, but it is annoying:

When I generate the documentation locally, the html files I get all have this header:
...............................

<title>The deal.II Library: The step-26 tutorial program</title> <script type="text/javascript" src="jquery.js"></script> <script type="text/javascript" src="dynsections.js"></script> <script type="text/javascript" src="search/search.js"></script> <script type="text/javascript"> $(document).ready(function() { searchBox.OnSelectItem(0); }); </script> [...] ..............................................

The problem is that the file style.css does not exist in the directory where everything is installed, $INSTALL/doc/doxygen/deal.II. Consequently, the markup of all pages is completely garbled and mostly unreadable.

On the other hand, if I look at the online documentation, say at http://www.dealii.org/developer/doxygen/deal.II/step_26.html , then I see that the header looks like this:
..............................................

<title>The deal.II Library: The step-26 tutorial program</title> <script type="text/javascript" src="jquery.js"></script> <script type="text/javascript" src="dynsections.js"></script> <script type="text/javascript" src="search/search.js"></script> <script type="text/javascript"> $(document).ready(function() { searchBox.OnSelectItem(0); }); </script> ..............................................

This is correct, and doxygen.css indeed exists.

Anyone got any idea what produces this difference?

Original issue: http://code.google.com/p/dealii/issues/detail?id=234

Indentation and code formatting

Currently, when discussing pull requests, we are at the mercy of different text editors when it comes to indentation or code formatting in general. In the long run, we should implement tests running on pull requests which compare to the standardized formatting.

Before doing so, we have to discuss, whether we are happy with astyle. There are reports that it may not reproduce the same result if run twice. True? Another issue is that continuing template parameter lists are indented not behind the opening <, but on the same level.

An alternative is clang-format, but it seems to be in a very early stage of development, in particular when it comes to flexibility and documentation. The GNU style, which is probably closest to ours is not even mentioned in some documents.

What do you think? I would find automatic indentation checks extremely useful.

Add rights to developers...

At the moment me (and probably other developers as well), do not have the rights to merge pull requests, nor to assign labels to issues (or close them).

I receive pull requests, but from the web, I'm not allowed to merge them. I can create issues, but I cannot assign labels nor owners...

Is this intented?

L.