Specifically:
* Use the same numbering scheme for enumerations as below. The style
[(1)] likely originated from using an `\item[(1)]` in the original
latex version of the introduction.
* Add a sentence after the bullet point list at the end of the introduction
to help doxygen understand that it should not indent the following
section heading (from the commented program) the same as the bullet
point list.
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.
In particular, change the following two things: (i) Say 'Additional information'
instead of 'Additional Information' because the rest of the text is also
capitalized in the common way. (ii) Indent the actual (additional) error text
by four characters, just like the other additional pieces of information.
The result is that errors now look like this:
--------------------------------------------------------
An error occurred in line <710> of file </home/fac/f/bangerth/p/deal.II/1/install/examples/step-6/step-6.cc> in function
int main()
The violated condition was:
false
Additional information:
abcdef
Stacktrace:
-----------
#0 ./step-6: main
--------------------------------------------------------
The memory consumption for Triangulation recently changed with #3163.
I have been seeing the difference for finite elements for longer already,
but don't recall which change broke the test.
It has long annoyed me that when we print exception messages that were created
via ExcMessage, that the information is really duplicative. Example:
--------------------------------------------------------
An error occurred in line <710> of file <.../step-6.cc> in function
int main()
The violated condition was:
false
The name and call sequence of the exception was:
ExcMessage ("abc" "def")
Additional Information:
abcdef
Stacktrace:
-----------
#0 ./step-6: main
--------------------------------------------------------
Here, the text that comes after 'The name and call sequence...'
is duplicative with what comes after 'Additional Information:'.
This is specifically the case for ExcMessage errors because
there *everything* that constructs the 'Additional information'
will actually be also under 'The name and...' part.
This patch cleans this up by omitting the first of these two
parts if the error message was created via ExcMessage.
Timo Heister [Tue, 4 Oct 2016 16:49:13 +0000 (12:49 -0400)]
remove warnings
clang warns with.
```
/ssd/deal-git/source/fe/fe_tools_extrapolate.cc:708:20: warning:
reference cannot be bound to dereferenced null pointer in well-defined
C++ code; comparison may be assumed to always evaluate to true
[-Wtautological-undefined-compare]
```