Reference documentation for deal.II version 9.6.0
|
Classes | |
class | IteratorRange< Iterator > |
Functions | |
template<typename FunctionObjectType > | |
auto | Threads::new_task (FunctionObjectType function_object) -> Task< decltype(function_object())> |
template<typename BaseIterator , typename Predicate > | |
IteratorRange< FilteredIterator< BaseIterator > > | filter_iterators (IteratorRange< BaseIterator > i, const Predicate &p) |
template<typename BaseIterator , typename Predicate , typename... Targs> | |
IteratorRange< typename internal::FilteredIteratorImplementation::NestFilteredIterators< BaseIterator, std::tuple< Predicate, Targs... > >::type > | filter_iterators (IteratorRange< BaseIterator > i, const Predicate &p, const Targs... args) |
template<typename BaseIterator , typename Predicate > | |
IteratorRange< FilteredIterator< BaseIterator > > | operator| (IteratorRange< BaseIterator > i, const Predicate &p) |
template<typename BaseIterator , typename Predicate > | |
IteratorRange< FilteredIterator< BaseIterator > > | filter_iterators (IteratorRange< BaseIterator > i, const Predicate &p) |
template<typename BaseIterator , typename Predicate , typename... Targs> | |
IteratorRange< typename internal::FilteredIteratorImplementation::NestFilteredIterators< BaseIterator, std::tuple< Predicate, Targs... > >::type > | filter_iterators (IteratorRange< BaseIterator > i, const Predicate &p, const Targs... args) |
template<typename BaseIterator , typename Predicate > | |
IteratorRange< FilteredIterator< BaseIterator > > | operator| (IteratorRange< BaseIterator > i, const Predicate &p) |
Cell iterator functions returning ranges of iterators | |
IteratorRange< cell_iterator > | DoFHandler< dim, spacedim >::cell_iterators () const |
IteratorRange< active_cell_iterator > | DoFHandler< dim, spacedim >::active_cell_iterators () const |
IteratorRange< level_cell_iterator > | DoFHandler< dim, spacedim >::mg_cell_iterators () const |
IteratorRange< cell_iterator > | DoFHandler< dim, spacedim >::cell_iterators_on_level (const unsigned int level) const |
IteratorRange< active_cell_iterator > | DoFHandler< dim, spacedim >::active_cell_iterators_on_level (const unsigned int level) const |
IteratorRange< level_cell_iterator > | DoFHandler< dim, spacedim >::mg_cell_iterators_on_level (const unsigned int level) const |
Cell iterator functions returning ranges of iterators | |
IteratorRange< cell_iterator > | Triangulation< dim, spacedim >::cell_iterators () const |
IteratorRange< active_cell_iterator > | Triangulation< dim, spacedim >::active_cell_iterators () const |
IteratorRange< cell_iterator > | Triangulation< dim, spacedim >::cell_iterators_on_level (const unsigned int level) const |
IteratorRange< active_cell_iterator > | Triangulation< dim, spacedim >::active_cell_iterators_on_level (const unsigned int level) const |
Face iterator functions | |
IteratorRange< active_face_iterator > | Triangulation< dim, spacedim >::active_face_iterators () const |
Since version 9.6, deal.II requires a compiler that supports at least C++17. Large parts of the library now depend on modern language constructs which are documented here.
One example is support for C++11 range-based for loops. deal.II-based codes often have many loops of the kind
Using C++11's range-based for loops, you can now write this as follows:
This works in the same way with Triangulation::active_cell_iterators() and DoFHandler::active_cell_iterators(). There are variants of these functions that provide iterator ranges for all cells (not just the active ones) and for cells on individual levels.
There are numerous other functions in the library that allow for the idiomatic use of range-based for loops. Examples are ReferenceCell::face_indices(), ReferenceCell::vertex_indices(), FEValuesBase::quadrature_point_indices(), among many others.
C++11 also introduces the concept of constexpr variables and function. The variables defined as constexpr
are constant values that are computed during the compilation of the program and therefore have zero runtime cost associated with their initialization. Additionally, constexpr
constants have properly defined lifetimes which prevent the so-called "static initialization order fiasco" completely. Functions can be marked as constexpr
, indicating that they can produce compile-time constant return values if their input arguments are constant expressions. Additionally, classes with at least one constexpr
constructor can be initialized as constexpr
.
As an example, since the constructor Tensor::Tensor(const array_type &) is constexpr
, we can initialize a tensor with an array during compile time as:
Here, the contents of A are not stored on the stack. Rather, they are initialized during compile time and inserted into the .data
portion of the executable program. The program can use these values at runtime without spending time for initialization. Initializing tensors can be simplified in one line.
Some functions such as determinant() are specified as constexpr
: these rely on the generalized constexpr support available in C++14. Some functions, such as unit_symmetric_tensor(), rely on further developments of constexpr
only available in C++17 and newer. As such, this function is declared as
The macro DEAL_II_CONSTEXPR expands to constexpr
if the compiler supports enough constexpr
features (such as loops). If the compiler does not then this macro expands to nothing.
Functions declared as constexpr
can be evaluated at compile time. Hence code like
assuming A
is declared with the constexpr
specifier, will typically result in compile-time constants. This example shows the performance gains of using constexpr
because here we performed an operation with \(O(\text{dim}^3)\) complexity during compile time, avoiding any runtime cost.
|
inline |
Overload of the new_task function for objects that can be called like a function object without arguments. In particular, this function allows calling Threads::new_task() with either objects that result from using std::bind, or using lambda functions. For example, this function is called when writing code such as
Here, we schedule the call to the sequence of functions do_this()
and then_do_that()
on a separate task, by making the lambda function declared here the function to execute on the task. The lambda function then returns 42 (which is a bit pointless here, but it could of course be some computed number), and this is going to be the returned value you can later retrieve via task.return_value()
once the task (i.e., the body of the lambda function) has completed.
decltype
statement used in the declaration of this function, and it is then used as the template argument of the Threads::Task object returned by the current function. In the example above, because the lambda function returns 42 (which in C++ has data type int
), the inferred type is int
and the task object will have type Task<int>
. In other words, it is not necessary to explicitly specify in user code what that return type of the lambda or std::bind expression will be, though it is possible to explicitly do so by (entirely equivalently) writing std::async(std::launch::async, ...)
in that it runs the given task in the background. See https://en.cppreference.com/w/cpp/thread/async for more information.Definition at line 1239 of file thread_management.h.
IteratorRange< cell_iterator > DoFHandler< dim, spacedim >::cell_iterators | ( | ) | const |
Return an iterator range that contains all cells (active or not) that make up this DoFHandler. Such a range is useful to initialize range-based for loops as supported by C++11. See the example in the documentation of active_cell_iterators().
IteratorRange< active_cell_iterator > DoFHandler< dim, spacedim >::active_cell_iterators | ( | ) | const |
Return an iterator range that contains all active cells that make up this DoFHandler. Such a range is useful to initialize range-based for loops as supported by C++11, see also C++11 standard.
Range-based for loops are useful in that they require much less code than traditional loops (see here for a discussion of how they work). An example is that without range-based for loops, one often writes code such as the following:
Using C++11's range-based for loops, this is now entirely equivalent to the following:
[this->begin_active(), this->end())
IteratorRange< level_cell_iterator > DoFHandler< dim, spacedim >::mg_cell_iterators | ( | ) | const |
Return an iterator range that contains all cells (active or not) that make up this DoFHandler in their level-cell form. Such a range is useful to initialize range-based for loops as supported by C++11. See the example in the documentation of active_cell_iterators().
[this->begin_mg(), this->end_mg())
IteratorRange< cell_iterator > DoFHandler< dim, spacedim >::cell_iterators_on_level | ( | const unsigned int | level | ) | const |
Return an iterator range that contains all cells (active or not) that make up the given level of this DoFHandler. Such a range is useful to initialize range-based for loops as supported by C++11. See the example in the documentation of active_cell_iterators().
[in] | level | A given level in the refinement hierarchy of this triangulation. |
[this->begin(level), this->end(level))
IteratorRange< active_cell_iterator > DoFHandler< dim, spacedim >::active_cell_iterators_on_level | ( | const unsigned int | level | ) | const |
Return an iterator range that contains all active cells that make up the given level of this DoFHandler. Such a range is useful to initialize range-based for loops as supported by C++11. See the example in the documentation of active_cell_iterators().
[in] | level | A given level in the refinement hierarchy of this triangulation. |
[this->begin_active(level), this->end(level))
IteratorRange< level_cell_iterator > DoFHandler< dim, spacedim >::mg_cell_iterators_on_level | ( | const unsigned int | level | ) | const |
Return an iterator range that contains all cells (active or not) that make up the given level of this DoFHandler in their level-cell form. Such a range is useful to initialize range-based for loops as supported by C++11. See the example in the documentation of active_cell_iterators().
[in] | level | A given level in the refinement hierarchy of this triangulation. |
[this->begin_mg(level), this->end_mg(level))
|
inline |
Filter the given range of iterators using a Predicate. This allows to replace:
by:
operator|
instead. The latter is certainly more in the spirit of C++20 range adaptors and results in the following code instead of the one shown above: Definition at line 997 of file filtered_iterator.h.
IteratorRange< typename internal::FilteredIteratorImplementation::NestFilteredIterators< BaseIterator, std::tuple< Predicate, Targs... > >::type > filter_iterators | ( | IteratorRange< BaseIterator > | i, |
const Predicate & | p, | ||
const Targs... | args ) |
Filter the given range of iterators through an arbitrary number of Predicates. This allows to replace:
by:
operator|
once or multiple times instead. The latter is certainly more in the spirit of C++20 range adaptors and results in the following code instead of the one shown above: Definition at line 1071 of file filtered_iterator.h.
|
inline |
Filter the given range of iterators using a predicate. This allows to replace:
by:
Here, the operator|
is to be interpreted in the same way as is done in the range adaptors feature that is part of C++20. It has the same meaning as the |
symbol on the command line: It takes what is on its left as its inputs, and filters and transforms to produce some output. In the example above, it "filters" all of the active cell iterators and removes those that do not satisfy the predicate – that is, it produces a range of iterators that only contains those cells that are both active and locally owned.
|
operator can be applied more than once. This results in code such as the following: Definition at line 1145 of file filtered_iterator.h.
IteratorRange< cell_iterator > Triangulation< dim, spacedim >::cell_iterators | ( | ) | const |
Return an iterator range that contains all cells (active or not) that make up this triangulation. Such a range is useful to initialize range-based for loops as supported by C++11. See the example in the documentation of active_cell_iterators().
IteratorRange< active_cell_iterator > Triangulation< dim, spacedim >::active_cell_iterators | ( | ) | const |
Return an iterator range that contains all active cells that make up this triangulation. Such a range is useful to initialize range-based for loops as supported by C++11, see also C++11 standard.
Range-based for loops are useful in that they require much less code than traditional loops (see here for a discussion of how they work). An example is that without range-based for loops, one often writes code such as the following (assuming for a moment that our goal is setting the user flag on every active cell):
Using C++11's range-based for loops, this is now entirely equivalent to the following:
[this->begin_active(), this->end())
IteratorRange< cell_iterator > Triangulation< dim, spacedim >::cell_iterators_on_level | ( | const unsigned int | level | ) | const |
Return an iterator range that contains all cells (active or not) that make up the given level of this triangulation. Such a range is useful to initialize range-based for loops as supported by C++11. See the example in the documentation of active_cell_iterators().
[in] | level | A given level in the refinement hierarchy of this triangulation. |
[this->begin(level), this->end(level))
IteratorRange< active_cell_iterator > Triangulation< dim, spacedim >::active_cell_iterators_on_level | ( | const unsigned int | level | ) | const |
Return an iterator range that contains all active cells that make up the given level of this triangulation. Such a range is useful to initialize range-based for loops as supported by C++11. See the example in the documentation of active_cell_iterators().
[in] | level | A given level in the refinement hierarchy of this triangulation. |
[this->begin_active(level), this->end(level))
IteratorRange< active_face_iterator > Triangulation< dim, spacedim >::active_face_iterators | ( | ) | const |
Return an iterator range that contains all active faces that make up this triangulation. This function is the face version of Triangulation::active_cell_iterators(), and allows one to write code like, e.g.,
[this->begin_active_face(), this->end_face())
|
related |
Filter the given range of iterators using a Predicate. This allows to replace:
by:
operator|
instead. The latter is certainly more in the spirit of C++20 range adaptors and results in the following code instead of the one shown above: Definition at line 997 of file filtered_iterator.h.
|
related |
Filter the given range of iterators through an arbitrary number of Predicates. This allows to replace:
by:
operator|
once or multiple times instead. The latter is certainly more in the spirit of C++20 range adaptors and results in the following code instead of the one shown above: Definition at line 1071 of file filtered_iterator.h.
|
related |
Filter the given range of iterators using a predicate. This allows to replace:
by:
Here, the operator|
is to be interpreted in the same way as is done in the range adaptors feature that is part of C++20. It has the same meaning as the |
symbol on the command line: It takes what is on its left as its inputs, and filters and transforms to produce some output. In the example above, it "filters" all of the active cell iterators and removes those that do not satisfy the predicate – that is, it produces a range of iterators that only contains those cells that are both active and locally owned.
|
operator can be applied more than once. This results in code such as the following: Definition at line 1145 of file filtered_iterator.h.