Reference documentation for deal.II version Git 3c0b904 2015-07-28 14:31:11 -0500
|void||initialize (const unsigned int n_quadrature_points, const FiniteElement< dim, spacedim > &fe, const UpdateFlags flags)|
|std::vector< unsigned int >||shape_function_to_row_table|
Fields filled by the mapping
|std::vector< double >||JxW_values|
|std::vector< DerivativeForm< 1, dim, spacedim > >||jacobians|
|std::vector< DerivativeForm< 2, dim, spacedim > >||jacobian_grads|
|std::vector< DerivativeForm< 1, spacedim, dim > >||inverse_jacobians|
|std::vector< Point< spacedim > >||quadrature_points|
|std::vector< Point< spacedim > >||normal_vectors|
|std::vector< Tensor< 1, spacedim > >||boundary_forms|
|typedef Table< 2, double >||ShapeVector|
|typedef std::vector< std::vector< Tensor< 1, spacedim > > >||GradientVector|
|typedef std::vector< std::vector< Tensor< 2, spacedim > > >||HessianVector|
This class has been extracted from FEValuesBase to encapsulate in one place all of the data, independent of the functions thater later access this data in the public interfaces of the FEValues and related classes. Consequently, this base class is protected in FEValuesBase.
The second reason is because in FEValuesBase::reinit, we first need to call Mapping::fill_fe_values() to compute mapping related data, and later call FiniteElement::fill_fe_values() to compute shape function related data. In the first step, Mapping::fill_fe_values() gets a pointer to its own internal data structure and a pointer to the FEValuesData base object of FEValuesBase, and the mapping then places the computed data into the data fields that pertain to the mapping below. In the second step, the finite element receives a pointer to its own internal object, and to the current object, and from both of these computes the shape function related information and, again, places it into the current FEValuesData object.
More information can be found on the page on The interplay of UpdateFlags, Mapping and FiniteElement in FEValues.
|typedef Table<2,double> FEValuesData< dim, spacedim >::ShapeVector|
Storage type for shape values. Each row in the matrix denotes the values of a single shape function at the different points, columns are for a single point with the different shape functions.
If a shape function has more than one non-zero component (in deal.II diction: it is non-primitive), then we allocate one row per non-zero component, and shift subsequent rows backward. Lookup of the correct row for a shape function is thus simple in case the entire finite element is primitive (i.e. all shape functions are primitive), since then the shape function number equals the row number. Otherwise, use the shape_function_to_row_table array to get at the first row that belongs to this particular shape function, and navigate among all the rows for this shape function using the FiniteElement::get_nonzero_components() function which tells us which components are non-zero and thus have a row in the array presently under discussion.
|typedef std::vector<std::vector<Tensor<1,spacedim> > > FEValuesData< dim, spacedim >::GradientVector|
|typedef std::vector<std::vector<Tensor<2,spacedim> > > FEValuesData< dim, spacedim >::HessianVector|
|void FEValuesData< dim, spacedim >::initialize||(||const unsigned int||n_quadrature_points,|
|const FiniteElement< dim, spacedim > &||fe,|
Initialize all vectors to correct size.
Store an array of weights times the Jacobi determinant at the quadrature points. This function is reset each time reinit() is called. The Jacobi determinant is actually the reciprocal value of the Jacobi matrices stored in this class, see the general documentation of this class for more information.
However, if this object refers to an FEFaceValues or FESubfaceValues object, then the JxW_values correspond to the Jacobian of the transformation of the face, not the cell, i.e. the dimensionality is that of a surface measure, not of a volume measure. In this case, it is computed from the boundary forms, rather than the Jacobian matrix.
|std::vector< DerivativeForm<1,dim,spacedim> > FEValuesData< dim, spacedim >::jacobians|
|std::vector<DerivativeForm<2,dim,spacedim> > FEValuesData< dim, spacedim >::jacobian_grads|
|std::vector<DerivativeForm<1,spacedim,dim> > FEValuesData< dim, spacedim >::inverse_jacobians|
|std::vector<Point<spacedim> > FEValuesData< dim, spacedim >::quadrature_points|
|std::vector<Point<spacedim> > FEValuesData< dim, spacedim >::normal_vectors|
|std::vector<Tensor<1,spacedim> > FEValuesData< dim, spacedim >::boundary_forms|
|std::vector<unsigned int> FEValuesData< dim, spacedim >::shape_function_to_row_table|
When asked for the value (or gradient, or Hessian) of shape function i's c-th vector component, we need to look it up in the shape_values, shape_gradients and shape_hessians arrays. The question is where in this array does the data for shape function i, component c reside. This is what this table answers.
The format of the table is as follows: - It has dofs_per_cell times n_components entries. - The entry that corresponds to shape function i, component c is
i * n_components + c. - The value stored at this position indicates the row in shape_values and the other tables where the corresponding datum is stored for all the quadrature points.
In the general, vector-valued context, the number of components is larger than one, but for a given shape function, not all vector components may be nonzero (e.g., if a shape function is primitive, then exactly one vector component is non-zero, while the others are all zero). For such zero components, shape_values and friends do not have a row. Consequently, for vector components for which shape function i is zero, the entry in the current table is numbers::invalid_unsigned_int.
On the other hand, the table is guaranteed to have at least one valid index for each shape function. In particular, for a primitive finite element, each shape function has exactly one nonzero component and so for each i, there is exactly one valid index within the range