David Wells [Fri, 21 Oct 2016 19:28:19 +0000 (15:28 -0400)]
Fix some boost warnings by applying old patches.
This commit redoes two old commits:
* 0fd99736f58, which silences a (bogus) warning in GCC 4.8 and GCC 4.9,
and
* 56b062ca039, which silences anothor bogus warning in GCC versions
prior to 4.8.
David Wells [Thu, 20 Oct 2016 01:31:19 +0000 (21:31 -0400)]
Update the bundled boost copy from 1.56 to 1.62.
This commit updates our bundled copy of boost from 1.56 to 1.62. While
doing this I removed several boost libraries that are not used anywhere
in deal.II nor in the rest of the part of boost that we bundle:
boost/compatibility: This little library wraps the standard C headers
and we don't need it.
boost/signals: This has long since been deprecated in favor of
signals2.
boost/tr1: The boost TR1 library contains reimplementations of features
that ultimately appeared in C++11. We implement this ourselves with the
std_cxx11 namespace so we skip this folder.
boost/thread/experimental: This library is new and we don't currently
have any use for it.
but internally (despite the fact that the field is declared
as 'double' above) reads them as integers. This leads to
wrong results if they are given as floating point numbers,
as in the case above.
While there also add an assertion an clean things up
slightly.
Refactor documentation for TrilinosWrappers::BlockSparsityPattern.
The documentation for this class now mirrors that provided in
`petsc_block_sparse_matrix.h` (and, for the namespace description,
`petsc_vector_base.h`).
These tests *do* use the JxW values, but they are not explicitly specified
as necessary. Instead, some quirk of our internal machineries causes this
flag to be set anyway, but it's better not to rely on this.
In the current setup, steps-1 and 2 first set all manifold ids, and only
then attach a manifold object. This invites the question what the triangulation
would do in between. On the other hand, we can easily fix this by first
attaching a manifold object to the triangulation for manifold_id zero,
and only then set the manifold_ids of cells and faces to zero.
Use an easier to read style for declaring iterator variables.
For first-time readers of deal.II programs (who may be used to other languages than C++),
our declarations of 'cell' and 'endc' that span multiple lines may be difficult to read.
For the first three tutorial programs, use a simpler syntax where each variable declaration
only requires a single line of code.
David Wells [Wed, 12 Oct 2016 15:56:51 +0000 (11:56 -0400)]
Improve the step-11 quadrature order explanation.
This little commit fixes three little issues with this paragraph:
1. A Gauss quadrature rule has order 2 r - 1 for r points, not 2 r + 1
2. p and p + 1 should be surrounded by $s
3. @>= should be replaced by the TeX command \geq
Generalize the data structure used to represent an edge set.
Specifically, the class is used to represent the set of edges by which the parallel
set can grow in each iteration. In 2d, this set can only have zero, one, or two
elements, and we can use a corresponding, O(1) data structure to store them.
In 3d, the set can be of arbitrary size and we represent it as a std::set.
Creating generic data structures also allows to write the algorithm that uses it
in a more concise way using iterators.
David Wells [Tue, 11 Oct 2016 19:05:25 +0000 (15:05 -0400)]
Remove FiniteElementBase doc references.
FiniteElementBase was removed in commit 6cc25d0964 (August 2005) and the
relevant functionality moved to FiniteElement or the namespace
FiniteElementDomination.
The new name is dimension independent. The speed is gained because we do not need
to search a list from the top every time, but it is enough to start searching where
we left off previously.
Generalize the data structures for the cells adjacent to an edge.
In 2d, only two cells can be adjacent to an edge, and the current data structures in the
mesh reorientation algorithm reflect this: each edge had 2 slots for adjacent cells, of which
zero, one, or two could be used at any given time.
On the other hand, in 3d, an arbitrary number of cells may be adjacent to an edge. I eventually
want to extend the algorithm re-written in #3166 to the 3d case as well. This patch generalizes
the data structure representing the cells adjacent to an edge by making it generic. The patch
only implements the 2d case, but the 3d case will be easy to add later on, and it makes the 'Edge'
data structure generic.
projects / dealii.git / log