 |
Reference documentation for deal.II version 9.0.0
|
|
Reference documentation for deal.II version 9.0.0
|
#include <deal.II/base/template_constraints.h>
Related Functions | |
(Note that these are not member functions.) | |
| template<typename T , typename U > | |
| ProductType< std::complex< T >, std::complex< U > >::type | operator* (const std::complex< T > &left, const std::complex< U > &right) |
| template<typename T , typename U > | |
| ProductType< std::complex< T >, typename EnableIfScalar< U >::type >::type | operator* (const std::complex< T > &left, const U &right) |
| template<typename T , typename U > | |
| ProductType< typename EnableIfScalar< T >::type, std::complex< U > >::type | operator* (const T &left, const std::complex< U > &right) |
A class with a local typedef that represents the type that results from the product of two variables of type T and U. In other words, we would like to infer the type of the product variable in code like this:
The local typedef of this structure represents the type the variable product would have.
The purpose of this class is principally to represent the type one needs to use to represent the values or gradients of finite element fields at quadrature points. For example, assume you are storing the values \(U_j\) of unknowns in a Vector<float>, then evaluating \(u_h(x_q) = \sum_j U_j \varphi_j(x_q)\) at quadrature points results in values \(u_h(x_q)\) that need to be stored as double variables because the \(U_j\) are float values and the \(\varphi_j(x_q)\) are computed as double values, and the product are then double values. On the other hand, if you store your unknowns \(U_j\) as std::complex<double> values and you try to evaluate \(\nabla u_h(x_q) = \sum_j U_j \nabla\varphi_j(x_q)\) at quadrature points, then the gradients \(\nabla u_h(x_q)\) need to be stored as objects of type Tensor<1,dim,std::complex<double>> because that's what you get when you multiply a complex number by a Tensor<1,dim> (the type used to represent the gradient of shape functions of scalar finite elements).
Likewise, if you are using a vector valued element (with dim components) and the \(U_j\) are stored as double variables, then \(u_h(x_q) = \sum_j U_j \varphi_j(x_q)\) needs to have type Tensor<1,dim> (because the shape functions have type Tensor<1,dim>). Finally, if you store the \(U_j\) as objects of type std::complex<double> and you have a vector valued element, then the gradients \(\nabla u_h(x_q) = \sum_j U_j \nabla\varphi_j(x_q)\) will result in objects of type Tensor<2,dim,std::complex<double> >.
In all of these cases, this type is used to identify which type needs to be used for the result of computing the product of unknowns and the values, gradients, or other properties of shape functions.
Definition at line 26 of file complex_overloads.h.
|
related |
Provide an operator* that operates on mixed complex floating point types. Annoyingly, the standard library does not provide such an operator...
Definition at line 39 of file complex_overloads.h.
|
related |
Provide an operator* for a scalar multiplication of a complex floating point type with a different real floating point type. Annoyingly, the standard library does not provide such an operator...
Definition at line 57 of file complex_overloads.h.
|
related |
Provide an operator* for a scalar multiplication of a real floating point type with a different complex floating point type. Annoyingly, the standard library does not provide such an operator...
Definition at line 75 of file complex_overloads.h.
1.8.14